interception rules changed

[gustavo-iniguez-goya]

Interception rules have been changed to address a problem with TCP connections (e090833).
This change may have some side effects, so if you experience any problem, something that has stopped working after this change, please report it so we can fix it or revert this change.

Since the very beginning, we have intercepted outbound connections that looked like responses instead of new outbound connections: 443:1.1.1.1 -> 192.168.1.123:12345

Due to this, we added some mechanisms to solve this problem, because we couldn't obtain the process that originated the connection:

1. opensnitch/daemon/procmon/ebpf/find.go

   Lines 26 to 27 in e090833

   	// FIXME: systemd-resolved sometimes makes a TCP Fast Open connection to a DNS server (8.8.8.8 on my machine)
   	// and we get a packet here with **source** (not detination!!!) IP 8.8.8.8

2. [x] Debug invalid connections option.

It turns out that using ct state NEW to intercept TCP outbound connections causes undesired effects:
We intercept packets that not only have the SYN flag set, but also ACK, ACK+PSH or SYN+ACK. Mainly response packets.

In these cases the IPs are not in the expected order: 443:1.1.1.1 -> 192.168.1.123:12345 which causes 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

For example:

[2023-07-23 15:14:01.196827]  new outbound packet: &{BaseLayer:{Contents:[200 68 35 240 118 44 46 149 184 251 188 153 128 16 0 64 66 137 0 0 1 1 8 10 251 253 242 163 251 253 234 163] Payload:[]}
SrcPort:51268 DstPort:9200(wap-wsp) Seq:1982606997 Ack:3103505561 DataOffset:8

FIN:false SYN:false RST:false PSH:false *ACK:true* URG:false ECE:false CWR:false NS:false Window:64 Checksum:17033 Urgent:0

sPort:[200 68] dPort:[35 240] 
Options:[TCPOption(NOP:) TCPOption(NOP:) TCPOption(Timestamps:4227723939/4227721891 0xfbfdf2a3fbfdeaa3)] Padding:[] opts:[{OptionType:1 OptionLength:1 OptionData:[]} {OptionType:1 OptionLength:1 OptionData:[]} {OptionType:8 OptionLength:10 OptionData:[251 253 242 163 251 253 234 163]} {OptionType:0 OptionLength:0 OptionData:[]}] tcpipchecksum:{pseudoheader:<nil>}}
[2023-07-23 15:14:01.196964]  WAR  NOT SYN! tcp: 51268 -> 9200
[2023-07-23 15:14:01.196986]  WAR  NOT SYN!: 9200:172.17.0.1 ->(tcp)-> 172.17.0.1:51268
[2023-07-23 15:14:01.197015]  DBG  new connection tcp => 9200:172.17.0.1 -> 172.17.0.1 ():51268 uid: 1000, mark: 0

Sometimes, very rarely, we even intercepted TCP FIN packets as new outbound connections.

Intercepting packets with only the SYN flag set seems to resolve this problem, at the cost of intercepting packets a little bit slower for some already established connections. But on the other hand, we don't display pop-ups with "erroneus" information (response packets as if they were new outbound connections).

This problem was particularly annoying with containerized connections.

For TCP outbound connections we're only interested in new connections for now, i.e., those with only the SYN flag set.
For the rest of connections, we can keep using ct state new unless probe otherwise, because it determines the state of the connections and handles many protocols (without it, we wouldn't intercept ICMP for example).

https://elixir.bootlin.com/linux/v5.10.19/source/net/netfilter/nf_conntrack_core.c#L1688
https://thermalcircle.de/doku.php?id=blog:linux:connection_tracking_3_state_and_examples#pointer_and_ctinfo

[akronym0]

please report it so we can fix it or revert this change.

Sure, is there a link to build I could test?

[gustavo-iniguez-goya]

thank you @akronym0 !

I've published a new release with latest changes: https://github.com/evilsocket/opensnitch/releases/tag/v1.6.1

Just after starting the daemon, depending on the connections of the system, I used to have connections in reverse order:
apps trying to establish outbound connections to ports like 45678, etc. when in reality they were responses (as explained above).

Now there shouldn't be this type of connections (at least for TCP), and the rest should behave as always.

[akronym0]

Great. I installed it and will test :-)

But I noticed one issue during the installation. I had to decide between "my" system-fw.json/default-config.json and the updated versions of those rules. I just reset to the updated version ("installed the package maintainer's version"). But in future this type of conflict probably deserves a note in the release notes. Is it save to keep the current config/json files? Or is it recommended to update/reset? Or could there be a better way to migrate settings?

[gustavo-iniguez-goya]

mmh, you're right. As a user I've never really known how to handle these changes. Many many times they don't come with a visual warning explaining if they're important or not (as far as I can tell), and you have to diff both versions.

On v1.6.0rc3 I added notes to the NEWS file, which displays a message to the user if apt-listchanges is installed.
Noted 📝 for next releases! I'll also update the Release page.