There are two issues when connecting to the GUI via TCP on localhost:
- Sometimes when the daemon is launched with the GUI already running, the
notifications channel is not established.
* Give 10 seconds to connect, if it timeouts, disconnect everything
and try to reconnect again.
- After some time the notifications channel is closed from the server
side (i.e., the GUI), and it is not restablished.
* Forcefully disconnect everything, and let it reconnect again.
Both issues should be investigated further to find the root problem.
Rules of type lists [domains, IPs, network ranges] are reloaded
whenever a file containing the data changes.
One could expect to update these files once or twice a day, but
by updating the files continuously it was possible to cause a leak,
leading to a crash.
Under certain conditions, when we dumped inodes via netlink, we were
linking network connections to wrong applications.
- To improve this situation:
1) Use netfilter's UID by default:
Sometimes the UID reported via netlink was different than the one
reported by libnetfilter. libnetfilter UID is always correct.
If you had a rule that filtered by UID, this problem could cause to
prompt you again to allow the connection.
2) Use the netlink entry that matches exactly the properties of an
outgoing connection:
There're some in-kernel sockets that doesn't match 1:1 outgoing
connections (daemon/netlink/socket.go#L22).
In order to identify the applications that initiate these network
connections we use a workaround. But under certain conditions
(source port reuse), we were associating connections to wrong
applications.
So in order to avoid this problem, if there's a 1:1 match use that
netlink entry. If not, fallback to the workaround.
- misc: added more logs to better debug these issues.
* Allow to intercept some kernel connections
Some connections are initiated from kernel space, like WireGuard
VPNs (#454), NFS or SMB connections (#502) and ip tunnels (#500).
Note: This feature is complete for x86_64, WIP for aarch64, and not supported for armhf and i386
https://github.com/evilsocket/opensnitch/pull/513#issuecomment-924400824
More information regarding this change: #493
- Added lists of IPs and network ranges. One per line. Blank lines or
lines that start with # are ignored.
- Added lists of domains with regular expressions. One per line.
Blank lines or lines that start with # are ignored.
Until now you could use regular expressions with the fields
"To this host" or "To this IP", to match multiple domains or IPs.
But if you wanted to use more than 2-3 domains or IPs it was not really
user friendly.
Hopefully we'll be a little more versatile to cover use cases like #461
and #485.
When blocking a connection via libnetfilter-queue using NF_DROP the
connection is discarded. If the blocked connection is a DNS query, the app
that initiated it will wait until it times out, which is ~30s.
This behaviour can for example cause slowdowns loading web pages: #481
This change adds the option to reject connections by killing the socket
that initiated them.
Denying:
$ time telnet 1.1.1.1 22
Trying 1.1.1.1...
telnet: Unable to connect to remote host: Connection timed out
real 2m10,039s
Rejecting:
$ time telnet 1.1.1.1 22
Trying 1.1.1.1...
telnet: Unable to connect to remote host: Software caused connection abort
real 0m0,005s
- Fixed reloading process monitor method if the configuration changes on
disk. This can occur in two situations: 1) if it's changed from the
UI, 2) if the user changes it manually.
- Ensure that we don't crash if there's an error changing the
method and ebpf is active.
- When changing monitor method to ebpf and it fails to start, stop it
anyway. It helps cleaning up kprobes and avoiding the error
"cannot write...: file exists".
When the daemon connects to the GUI, use the default action
configured on the GUI to apply a verdict on new connections.
We were using daemon's default action, so if it was Allow but the user
had configured Deny on the GUI it was allowing connections, causing some
confusion (#489)
TODO: apply this action not only on connecting to the GUI, but also when
saving the configuration from the GUI.
- The firewall rules defined in /etc/opensnitchd/system-fw.json take
precedence over the interception rules, but we were inserting the
interception rules before the system's ones. With this change #455
should be fixed.
- On the other hand, the DefaultAction was not being applied correctly
in all cases. As of today the DefaultAction is applied in 2 scenarios:
* When the daemon is connected to the GUI and the user doesn't answer
a pop-up.
* When the daemon is not connected to the GUI.
However as we don't parse all network protocols, even if the GUI is
connected we may end up parsing a connection and don't know what to do
with it. In this case the DefaultAction was always Deny.
Now in the above scenario, i.e.: when the GUI is connected but we
can't parse a connection, we'll apply the DefaultAction configured by
the user.
Remove \r\n\t\s from the end of each line of a blocklist.
If the entries of a list had these characters caused to not match
connections and not apply the rule.
closes#429
Previous behaviour:
1) Before version 1.0.0b the daemon kept a list of processes that had
established connections. The list was displayed on the GUI as is, so
the maximum number of connections displayed were 100 (hardcoded).
2) When the intercepted connections reached 100, the last entry of the
list was removed, and a new one was inserted on the top.
After v1.0.0 we started saving connections to a DB on the GUI side, to
get rid of the hardcoded connections limit. However, the point 2) was
still present that caused some problems:
- When the backlog was full we kept inserting and deleting connections
from it continuously, one by one.
- If there was a connections burst we could end up missing some
connections.
New behaviour:
- The statisics are deleted from the daemon everytime we send them to
the GUI, because we don't need them on the daemon anymore.
- If the GUI is not connected, the connections will be added to the
backlog as in the point 2).
- When the backlog reaches the limit, it'll keep deleting the last
one in order to insert a new one.
- The number of connections to keep on the backlog is configurable.
- If the statistics configuration is missing, default values will be
150 (maxEvents) and 25 (maxStats).
Notes:
If the GUI is saving the data to memory (default), there won't be
any noticeable side effect.
If the GUI is configured to save the connections to a DB on disk, and
the daemon sends all the backlog at once, the GUI may experience a
delay and a high CPU spike. This can occur on connecting to the daemon
(because the backlog will be full), or when an app sends too many
connections per second (like nmap).
Before this change, we tried to determine what firewall to use based on
the version of iptables (if -V legacy -> nftables, otherwise iptables).
This caused problems (#455), and as there's no support yet for nftables
system firewall rules, it can't be configured to workaround these
errors.
Now the default firewall to use will be iptables.
If it's not available (installed), can't be used or the configuration
option is empty/missing, we'll use nftables.
One of the steps of PIDs discovering is knowing what's the socket inode
of a connection. The first try is to dump the active connections in the
kernel, using NETLINK_SOCK_DIAG via netlink.
Sometimes when a source port was reused, the kernel could return multiple
entries with the same source port, leading us to associate connections with
the wrong application.
This change fixes this problem, while allowing us to discover other
apps.
More information:
https://github.com/evilsocket/opensnitch/issues/387#issuecomment-888663121
Note: this problem shouldn't occur using the procs monitor method eBPF.
- Fixed multiple race conditions when using the cache of PIDs.
- Improved the chances to hit the cache of inodes, which helps to keep
down the times to get the PID of a connection to <= 30us.
These caches are mainly used when not using "ebpf" proc monitor method.
Prior to v1.4.x versions, when a pop-up asked the user to allow or deny
a connection, the rest of the network traffic was dropped until an
action was taken.
We fixed it, but when a pop-up was asking to allow or deny a new connection,
we let it passing by if the daemon's DefaultAction option was set to
allow, even if the user hadn't taken an action on it yet.
It also caused some confusion if the users had configured the pop-up's
DefaultAction to deny, they were expecting to not allow the connection
until they had decided what to do.
Now the previous behaviour has been restored, having these usage
scenarios:
- If the GUI is connected + daemon DefaultAction set to allow or deny.
Result:
1. Prompt the user to allow or deny the new connection.
2. Deny the new connection until the user takes an action on it.
3. Allow the rest of traffic, allowing known connections, and
denying new ones until the active pop-up is closed and we can
prompt the user again.
- GUI disconnected.
Result:
1. Apply daemon's DefaultAction from the configuration file
default-config.json.
closes: #392
Some times, processes that establish connections to localhost are only
found in /proc/net/* files. So if we fail to get the PID of a
connection, fallback to legacy method to find it.
Added basic nftables support, which adds the needed rules to intercept
outgoing network traffic and DNS responses. System rules will be added
soon.
What netfilter subsystem to use is determined based on the following:
- nftables: if the _iptables_ binary is not present in the system, or
if the iptables version (iptables -V) is
"iptables vX.Y.Z (nf_tables)".
- iptables: in the rest of the cases.
When the Duration of a rule changed (from 1h to 5m, from 5m to until
restart, etc), the timer of the old rule was fired, causing deleting the
rule from the list.
This erroneous behaviour could be one of the reasons of #429
When enabling the eBPF monitor method we dump the active connections,
but in some cases there're no active connections, and because of this
we're failing enabling this monitor method.
If there're no connections established, netlink returns 0 entries. It's
not clear if it's an indication of error in some cases or the expected
result.
Either way:
- fail only if we're unable to load the eBPF module.
- dump TCP IPv6 connections only if IPv6 is enabled in the syste,-
It'd probably be a good idea to write a module and encapsulate all the
functionality of the fields in funcs(), to lock them properly
(get/set maps, etc).
TODO: replace monitorLocalAddress() by
netlink.AddrSubscribeWithoptions(), to receive addresses' events
asynchronously.
