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.
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.
- removed unused import time.
- allow to pause/start interception from tray contextual menu.
- improved case when the daemon is in paused state, and the GUI is
launched.
There's more work yet to do to improve the states when there're several
nodes connected.
closes#398
* Use ebpf program to find PID of new connections.
before running the branch you have to compile ebpf_prog/opensnitch.c
opensnitch.c is an eBPF program. Compilation requires getting kernel source.
cd opensnitch
wget https://github.com/torvalds/linux/archive/v5.8.tar.gz
tar -xf v5.8.tar.gz
patch linux-5.8/tools/lib/bpf/bpf_helpers.h < ebpf_prog/file.patch
cp ebpf_prog/opensnitch.c ebpf_prog/Makefile linux-5.8/samples/bpf
cd linux-5.8 && yes "" | make oldconfig && make prepare && make headers_install # (1 min)
cd samples/bpf && make
objdump -h opensnitch.o #you should see many section, number 1 should be called kprobe/tcp_v4_connect
llvm-strip -g opensnitch.o #remove debug info
sudo cp opensnitch.o /etc/opensnitchd
cd ../../../daemon
--opensnitchd expects to find opensnitch.o in /etc/opensnitchd/
--start opensnitchd with:
opensnitchd -rules-path /etc/opensnitchd/rules -process-monitor-method ebpf
Co-authored-by: themighty1 <you@example.com>
Co-authored-by: Gustavo Iñiguez Goia <gooffy1@gmail.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.
Added option to let the users define iptables rules.
The system rules are added in the file /etc/opensnitchd/system-fw.json
with this format:
```
{
"SystemRules": [
{
"Rule": {
"Description": "Allow pptp VPN",
"Table": "mangle",
"Chain": "OUTPUT",
"Parameters": "-p gre",
"Target": "ACCEPT",
"TargetParameters": ""
}
}
]
}
```
On the mangle table, OUTPUT chain, these rules are added before
the NFQUEUE interception rule, so any rule you add there bypasses the
interception. Useful to allow traffic you don't want to intercept.
This feature solves in some way the issue some users have connecting to
VPNs when the Default Action configured in the daemon is Deny.
For example:
- OpenVPN when keepalive is configured and ICMP is used.
- PPTP because the GRE routing protocol is blocked.
- probably others like IPSEC.
(regarding WireGuard, as far as I can tell it works just fine, see #61).
closes#47
The server address and log file were hardcoded into the
opensnitchd.service file, making it almost impossible to change.
Soon we'll be able to change it from the UI.
Some systems has the IPV6 protocol disabled, so we failed starting up
with the error "Address family not supported by protocol" (#52).
Now we don't exist even if we can't insert the needed rules, we'll just
log the error.
When the daemon is stopped, we need to close opened netfilter recurses.
Otherwise we can fall into a situation where we leave NFQUEUE queues
opened, which causes opensnitch to not run anymore until system restart
or a manual intervention, because there's a NFQUEUE queue already created
with the same ID.
This is what was happening as a collateral effect of #41.
Denied connections were logged with Warning level.
However if you had a rule that denied a particular noisy connection, it
generated too much logs that didn't add value.
In the future it would be nice to log as warning, denied connections
that do not have a rule created by a user.
Discussion: https://github.com/gustavo-iniguez-goya/opensnitch/issues/10#issuecomment-615854975
(1/2)
We start receiving notifications from the UI, which allow us to change
configurations and perform actions on the daemon.
The concept of Node has also been introduced, which identifies every
daemon (client) connected to the UI (server).
These options has been added:
- Enable/Disable firewall interception (for all nodes)
- Change daemons (clients) configuration. globally or per node.
- Change prompt dialog options.
We have fixed some bugs along the way:
- Close audit client connection gracefully.
- Exclude our own connections from being intercepted.
- Better handling of client connection status with the UI.
We probably has also introduced some other bugs (not listed here).
Added ProcMonitorMethod, which can be "proc", "ftrace" or "audit".
Parameters passed by command line take prevalence over default
configuration.
breaking changes: config options changed from xx_yy to XxYy.
Config example:
{
"DefaultAction": "allow",
"DefaultDuration": "once",
"InterceptUnknown": true,
"ProcMonitorMethod": "audit"
}
Use auditd events to keep a list of PIDs which open sockets, reading
them from the audisp af_unix plugin.
- Install auditd and audisp-plugins
- Enable the af_unix plugin (/etc/audisp-plugin/af_unix, active = yes)
- Start opensnitch with -process-monitor-method audit.
If the choosen method is audit but it's not active or not installed,
it'll fallback to /proc anyway.
If it's properly configured, a debug trace will be written to the logs:
"PID found via audit events ..."
Until now OpenSnitch used ftrace(debugfs) to search for running
processes (PIDs) and obtain the process path.
On some systems, this filesystem is not mounted or available, so we have
to rely on /proc.
After several weeks of use, I think that it's faster and more accurate
the 2nd method, search pids/cmdlines in /proc. So we offer the user to
choose which one to use.
If for some reason a Regex type rule can not be parsed, opensnitchd
panics and exit. We drop regex.MustCompile() in favor of
regex.Compile(), and in case of failure we just drop the packet.
In either case, the daemon should not panic but it should not received
an invalid rule either, specially from the UI.
Closes#4
Added 30s, 5m, 15m, 30m and 1h timeout options to deny or allow
connections.
It helps to avoid repetitive new connection dialogs, while at the same
time it allows you to deny/allow a connection for a short period of time,
and apply the default for the rest.
