- Delete lists of domains if the rule about to change is of type Lists.
- Monitor the lists of domains, and reload them if they're modified.
- Delete rules from disk when the Duration changes from
Always (saved on disk) to !Always (temporary).
- After the above operation a fsnotify Remove event is fired. Don't
delete the rule from memory if it's temporary.
- Rules are only compiled if they're enabled, avoiding unnecessary
allocations.
Any rule changed on disk caused reloading of all rules, usually
up to three times. This caused some problems.
- Don't compile Operators if the rule is disabled.
- Empty lists of domains if the user disables the rule.
- Delete rule from disk if the duration is not Always anymore.
There're some situations where we need to delete loaded lists:
- When an enabled rule of type Lists is disabled (after changed on
disk, or when configured from the GUI).
- When an enabled rule of type List with an Operator of type Lists is
disabled.
Initial support to filter connections using lists of domains.
The lists must be in hosts format:
- 0.0.0.0 www.domain.com
- 127.0.0.1 www.domain.com
From the rules editor, create a new rule, and select
[x] To this lists of domains
Select a directory with files in hosts format, select [x] Priority rule,
select [x] Deny and click on Apply.
An example of a list in hosts format:
https://www.github.developerdan.com/hosts/lists/ads-and-tracking-extended.txt
Note: you can also add a list of domains to allow, not only domains to
block.
TODOs:
- support for URLs besides directories (local lists).
- support for scheduled updates of the above URLs.
related #298
Sometimes when querying the kernel for a given connection, the inode of
the connection is 0, i.e.: invalid (or not yet valid).
In these cases we search for the connection in /proc/net/. It turns out
that some connections are found in netstat but the inode is still 0, and
we were accepting them erronously.
As a result, when looking for the inode under /proc we didn't find it,
so an "Unknown process" dialog was shown to the user.
Discarding this type of connections avoids unknown process dialogs when
using Epiphany in particular. It retries to establish the connection
several times, and finally we're able to find the PID of the process.
When testing this patch under a heavy load of 300 new connections per second running for 12 hours, I saw a few timeouts.
This means that there are legitimate cases when sending the packet to the channel will not go through
no matter how long we wait.
However, compared to the old behavior, the amount of dropped packets decreased by a factor of 100x.
The value of timeout is chosen to be 1 millisecond, because it feels reasonable that if after so long the packet did
not go through, it is not due to a congested channel but due to some other error which will not go away even if we wait longer.
Every rule has an entry point besides a constructor, which configures
all it needs to match connections, based on user defined criteria (ip,
regexp, etc).
This only needs to be done the first time we load a rule, because the
fields of a rule are static. However for rules of type "lists" we were
iniatializing each rule of this type once per connection that it
matched.
rename, remove unused targets
trigger targets only when relevant files actually are changed
git:
do not track files which are generated during make
github actions fix to not rely on a pre-built ui.pb.go
* maintain a cache of struct Process for currently active PIDs
decreases PID lookup time from ~100usec to ~5usec
* Update activepids.go
remove import "os"
Co-authored-by: themighty1 <you@example.com>
Mullvad VPN uses an nfmark on packets when establishing a connection with their VPN servers.
If we don't preserve the nfmark, the connection will never be established.
- ui, ruleseditor: added missing operator when using a regular
expression on the DstIP/Net field.
- daemon, rules: ensure that regular expressions are of type string
before evaluating them.
reported here: #333
We had an OUTPUT rule to drop marked packets. Packets are marked with a
mark when a user defined rule denies a connection.
The thing is that we only intercept NEW connections, and when we deny a
connnection using NF_DROP, the packets doesn't flow to the next iptables
rule or chain. So it'd be rare to see a packet on the OUTPUT chain marked
with the DropMark.
Besides, nfq_set_verdict2() doesn't seem to place the mark on the
packets (libnetfilter-queue 1.0.5).
This OUTPUT rule had 0 hits on different systems and users.
* unittest: test live reloading of rules
* data files for the previous commit
* tests: move files under /testdata; give better names to rules
Co-authored-by: themighty1 <themighty1>
Use the timestamp instead of the event object when iterating over the last events. ~15x speed increase.
Increase event buffer to 100. On my machine I routinely hit the ceiling of 50 events under some multitasking workloads. Small buffer results in connection attempts not being logged.
Fix Makefile to rebuild when ui.proto changes
- Rules are checked in alphabetical order.
- Deny and Priority rules must take precedence.
- If a rule matches and it's Allow-NoPriority, then return the rule.
- Otherwise we'll return nil.
- Fixed 100% CPU spike when pausing interception from the GUI
gustavo-iniguez-goya/opensnitch/issues/104
- Fixed monitoring fw rules after re-enabling interception.
- Fixed cleaning up interception and system rules.
Now you can filter by destination network, for example:
- 127.0.0.1/8
- 192.168.1.0/24
This will ease to solve the request #89 .
Some common network ranges have also been added so you can select them
from a combo box. More info #73.
Added process.id operator operand for future use, in order to filter by
PID.
We were checking several times if a packet was IPv6.
Additionally we were itereating over all the layers of the packet, when
in reality we're only interested in network layer and transport layer.
This change brings down packets parsing from ~200µs to ~2µs.
