Nfqueue bypass option skips the enqueue of packets to userspace
if no application is listening to the queue.
https://wiki.nftables.org/wiki-nftables/index.php/Queueing_to_userspace
If this flag is not specified, and for example the daemon dies
unexpectedly, all the outbound traffic will be blocked.
Up until now we've been using this flag by default not to block network
traffic if the daemon dies or is killed for some reason. But some users
want to use precisely this behaviour (#884, #1183, #1201).
Now you can configure it, to block connections if the daemon
unexpectedly dies.
The option is on by default in the configuration (QueueBypass: true).
If this item is not present in the daemon config file, then it'll be
false.
- Added new configuration field to allow configure fw interception
number queue (default to 0):
"FwOptions": {
"QueueNum": 0
}
(we still need to reconfigure nfqueue queues in order for this to
take effect).
- If the fw configuration path is not supplied, default to
/etc/opensnitchd/system-fw.json
By default load the system fw config file from
/etc/opensnitchd/system-fw.json.
There're these options to specify the file to load:
- via cli option with -fw-config-file
- writing it in the default-config.json file:
"FwOptions": { "ConfigPath": "..." }
If both options are empty, then the default one is used.
FIXME:
When the cli option is used to load the fw configuration, and the main
preferences are saved, the fw is reloaded but the path to the fw config
is lost.
- Allow to configure system firewall configuration file path:
* via cli (-fw-config-file).
* via global configuration file.
- Allow to configure fw rules check interval.
The system fw config file contains regular iptables/nftables rules.
Previously it was hardcoded to /etc/opensnitchd/system-fw.json
The interval to check if the interception rules were added was also
hardcoded to 10 seconds. Now it's possible to configure it.
A value of "0s" disables the interval, while "" defaults to 10 seconds.
- 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.
This is part of latest commit ced9a24933
- When reusing a chain, configure the new policy.
- Don't backup existing rules when reloading the configuration.
- Configuration of system firewall rules from the GUI is not supported for
iptables. Up until now only a warning was displayed, encouring to change
fw type manually.
Now if configured fw type is iptables (default-config.json, Firewall:),
and the user opens the fw dialog, we'll ask the user to change it from
the GUI.
- Add fw rules before connecting to the GUI. Otherwise we send to the
GUI an invalid fw state.
* Allow to configure firewall rules from the GUI (WIP)
New features:
- Configure and list system firewall rules from the GUI (nftables).
- Configure chains' policies.
- Add simple rules to allow incoming ports.
- Add simple rules to exclude apps (ports) from being intercepted.
This feature is only available for nftables. iptables is still supported,
you can add rules to the configuration file and they'll be loaded, but
you can't configure them from the GUI.
More information: #592
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.
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.
- 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.
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
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.
We must intercept RELATED packets, not only for intercept protocols like
ftp-data, but also to handle connection errors (ICMP errors), like the
ones originated when dis/connecting from a wifi network.
In some scenarios (#47) may be useful to have a set of rules handled from
OpenSnitch, although you can accomplish it with other software (ufw,...).
This rules will sit just above default intercetion, so if you want to
allow or deny something, just place it here.
These priority rules are defined in /etc/opensnitchd/fw.json, with the
following format (example):
{
"PriorityRules": {
"out": {
"allow": [
],
"deny": [
"-m conntrack --ctstate INVALID",
"-p tcp ! --syn -m conntrack --ctstate NEW"
]
}
}
}
The structure must exist even if you haven't defined any rule, for
example:
{
"PriorityRules": {
"out": {
"allow": [
],
"deny": [
]
}
}
}
(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).
Sometimes the INPUT rule for to queue DNS responses was not deleted.
The code has also been reorganized.
And a minor tweak to make an if{} more idiomatic.
