When we start to intercept connections, we flush out the conntrack
table, to force already established connections reconnect again so we
can intercept them, and let the user choose if allow or deny them.
Since we no longer use conntrack states to intercept TCP connections, we
now close existing connections, leaving to the applications reestablish
them again.
Local connections are excluded, because it may cause problems with some
local servers.
Both options interfere with the established connections, so you may
experience ocasional network interruptions when enabling the
interception for the first time.
Discussion: #995
For the eBPF monitoring method, we listed and stored local addresses
every second, so that we could later check if the source IP of an
outbound connection was local or not, because sometimes we received
outbound connections like:
443:1.1.1.1 -> 192.168.1.123:12345
This could have been alread solved on this change e090833, so maybe
we no longer need this code.
- Now we subscribe to local addresses events, to receive add/remove
events asynchronously, without having to list local addrs
every second, alliviating CPU usage.
- Fixed creating context object to cancel subroutines. It was not
working properly when switching between proc monitor methods.
Using "ct state NEW" to intercept packets causes some undesired effects:
We intercept packets that not only have the SYN flag set, like ACK,
ACK+PSH or SYN+ACK. Mainly response packets.
This means that the IPs are not always in the expected order:
443:1.1.1.1 -> 192.168.1.123:12345
which causes sometimes not to obtain the process of the connection,
because the connection in the system appears as
12345:192.168.1.123 -> 1.1.1.1:443
Intercepting packets with *only* the SYN flag set seems to resolve
this problem.
When answering a pop-up we generate the rule name based on the
properties of the connection.
When sending the rule to the daemon, the daemon verifies that the name
is unique and save it. If it's not, it generates a unique name.
However, if you responded to a pop-up and later modified any property of
the rule without changing the name, if the same connection tried to be
established again, you were prompted to allow/deny it, generating the
same name for the rule.
This could cause some confusion, because when sending the new rule to
the daemon the rule name was regenerated to be unique, but on the GUI
it was not updated, and even more, the old-personalized rule was
replaced with the new one.
When creating rules filtering by UID, there're 3 possible "modes":
- simple: 0, 1000, etc.
- user: root (0), opensnitch (1000)
- regexp: ^(0|1000)$
regexp was not being used correctly.
- Allow to use SSL certificates to secure unix sockets communications.
- Allow to use abstract users sockets for server and nodes.
Go gRPC doesn't seem to understand unix sockets addresses that start
with "unix-abstract:", and python gRPC doesn't seem to understand
"unix:@" addresses.
Therefore, on the server (python gRPC) we use the format "unix:@" to
specify the address where the server will listen on, and rewrite it to
"unix-abstract:" before starting the server.
Note about certs and abstract unix sockets:
When creating the SSL certificates, you'll have to specify the
address of the unix socket as the Common Name of the certificates:
Address: "unix:@my-abstract-socket"
Common Name: @my-abstract-socket
- Send errors to the server (GUI) if there's any error when reloading
the system fw rules (far from being perfect/optimal, needs a
rewrite).
- Don't load the configuration after saving it, let the watcher reload
it on write change to avoid double reload/duplicated errors.
- Allow to receive and display errors when deleting app rules.
- Fixed error displaying notifications on the main window.
- Improvements to receive notifications on the fw dialog.
When selecting a user from the dropdown list, it should set the uid of
the user in the text line. But sometimes, the format "user (uid)" was
set (instead of just "uid").
