On KDE the events window was not restored to previous state when the
window was minimized to the taskbar.
This was fixed by @themighty1 in this PR #315, but there was an
unexpected behaviour on others DE.
As I haven't seen this error in others DE, we apply the original
fix, but only when the DE in use is KDE.
- Fixed typos in the preferences dialog (#465).
- Fixed hiding/showing rules combobox.
- Keep opensnitchd/default-config.json format when saving node's
configuration from the GUI.
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.
- Now the columns names of the details views can be translated (#465).
- Fixed columns size restoring when clicking on the Events tab to view
the details of an item (process, rule or node).
There was an annoying bug that increased the pop-up height a little bit
everytime a new pop-up was displayed.
Hopefully this time it's fixed, while maintaining compatiblitiy on the
mobile (i.e.: displaying the buttons at the bottom and the connection
information at the top of the pop-up).
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.
* Preferences:
- Allow to configure the columns of the Events tab.
- Fixed displaying labels on small screens.
* Rules:
- Added combo to select the type of rules to list (all, permanent,
temporary) when the left panel is hidden.
* Main window:
- Improved tabs widgets positioning.
* Misc:
- Improved code to avoid typos.
- Added option to ignore temporary rules. All or only of duration
"once".
You can still use them when answering a pop-up, but if you check the
option, the rules won't be added to the rules list.
- Fixed wrong behaviour when adding rules to the db/gui.
When changing a rule duration (always->30s, 30s->always), if there
were connections matching that rule, the rule was re-added to the
db/rules list with the old duration, ending up with 2 rules in the
list.
This was caused by how stats are sent to the GUI. When populating the
db with the stats, we were also adding the rules.
Now we don't add the rules when adding the stats. Rules are added to
the db everytime a node connects to the GUI, when answering a pop-up
or whenever the user performs an operation on them.
Performance has increased a little bit due to this.
- Fixed applying configuration to all nodes at once.
- Added help menu to the preferences dialog.
- Removed lists grid.
- A little bit of code reorganization.
- 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.
There's a new way of blocking lists of domains:
https://github.com/evilsocket/opensnitch/wiki/block-lists
However the update of the lists is not implemented yet. You can use
this or other simple script to download and update the lists (in hosts
format).
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
- Fixed refreshing rules list after delete a rule(s).
(There was an annoying delay).
- Added button to delete connections associated with a rule, from the
details view of a rule. (related: #334).
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
There was a race condition that caused several problems when editing or
adding rules.
for rules of type "list", the operand must be "list" as well.
related: #429#425
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.
Sometimes when a new connection is about to be established, we don't get
the PID of the process using the eBPF proc monitor method. But in some
rare situations, the kernel still holds information about the connection
(sock_diag struct basically). We assume that these connections are
initiated from kernel space.
Per some debugging, this doesn't seem to be always the root cause, so
these connections will only be shown if InterceptUnknown config field is
set to true.
