Allow to cypher channel communications with certificates.
There are 3 authentication types: simple, tls-simple and tls-mutual.
- 'simple' wont't cypher communications.
- 'tls-simple' uses a server key and certificate for the server, and a
common CA certificate or the server certificate to authenticate all
nodes.
- 'tls-mutual' uses a server key and certificate for the server, and a
client key and certificate per node.
There are 2 options to verify how gRPC validates credentials:
- SkipVerify: https://pkg.go.dev/crypto/tls#Config
- ClientAuthType: https://pkg.go.dev/crypto/tls#ClientAuthType
Example configuration:
"Server": {
"Address": "127.0.0.1:12345",
"Authentication": {
"Type": "tls-simple",
"TLSOptions": {
"CACert": "/etc/opensnitchd/auth/ca-cert.pem",
"ServerCert": "/etc/opensnitchd/auth/server-cert.pem",
"ClientCert": "/etc/opensnitchd/auth/client-cert.pem",
"ClientKey": "/etc/opensnitchd/auth/client-key.pem",
"SkipVerify": false,
"ClientAuthType": "req-and-verify-cert"
}
}
}
More info: https://github.com/evilsocket/opensnitch/wiki/Nodes
- Previously we only supported multiple ICMP types on the same rule
by adding multiple keys:
Key: type
Value: echo-request
Key: type
Value: echo-reply
Now it's possible to specify them using ',':
Key: type
Value: echo-request,echo-reply
- Validate ICMP types before adding them.
- fsnotify notifies 2 WRITE events sometimes (known bug), which leads to
read 0 bytes one of the times.
As now we send these errors to the GUI, on some systems we were
displaying an error reading the config, which was not really the case.
- Only parse the config before writing it to disk, instead of call the
load() method.
Now you can add rules to allow multiple protocols.
For example you can add a rule to allow dport/sport for both TCP
and UDP.
There're two options to allow a port:
Statement {
Name: tcp
Values:
Key: dport
Value: 1234
}
Statement {
Name: meta
Values:
Key: l4proto
Value: tcp,udp
Key: dport
Value: 1234
}
Closes#951.
The DNS rule to intercept DNS responses must always be at the top of
the (input-filter) rules, otherwise we won't receive DNS resolutions.
Adding, removing or changing system fw rules was removing the rule from 1st
position.
Another approach to this problem could be to remove&&add only the dns rule,
instead of disable-enable interception+rules monitor.
- Allow to filter connections by source IP/Network.
(it also may be useful filter by source port)
- Removed AlwaysOnTop Hint from rules editor dialog.
Closes#922
- Log packet mark, which may help debugging VPN connections for example.
- Log the nfqueue number when we fail to setup the queue.
* Suggest to restart the computer on one particular case (#912).
Up until now we intercepted query and DNS answers using these methods:
- Intercepting DNS queries to port 53.
- Intercepting DNS answers from port 53
- Intercepting glibc DNS functions.
Unfortunately there are scenarios where these methods are not enough:
- When using DNSSEC, DoT, DoH, etc.
- When resolvers return DNS answers from cache
- When resolvers don't use glibc functions to resolve domains.
- When applications use D-BUS to query for domain names instead of
using UDP/TCP (VPNs, flatpaks, electron based apps, etc.).
With this new DNS monitor now we're able to intercept DNS answers when
systemd-resolved is used to resolve domains.
This includes queries from flatpaks and others containerized
applications, as well as cyphered DNS queries.
Closes#874
When using proc monitor method + interceptUnknown, allow to ask the user
about connections not associated with a process. Usually they're safe to
discard, but on some special cases it helps not disrupt some services.
Block of code to find connections via netstat moved to procmon/
