understanding rule syntax, regex

[atomGit]

i created a rule to allow a command to connect to the following:

host: (.*\.)?archlinux\.org
ip: 127.0.0.1

after creating it, i got an unexpected pop-up which i thought should've been covered by the above rule:

host: openpgpkey.archlinux.org

[gustavo-iniguez-goya]

hey @atomGit ,

the regexp looks fine. Did you take a look at the logs? Since you created a rule for IP + host, if it's resolving openpgpkey.archlinux.org to something else it'll prompt you to allow/deny it.

Set the LogLevel to DEBUG and execute in a terminal: ~ $ tail -f /var/log/opensnitchd.log | grep archlinux.org to see if it's trying to connect to a different IP than 127.0.0.1

[atomGit]

if i enable debug i see that there's an IP that isn't included in my existing rule - using example IPs here, in the log i see...

new connection tcp => 48100:10.0.11.111 -> 1.1.1.1

and when i allow the connection, the newly created rule includes only 1.1.1.1 for the destination ... which should be matched by my existing rule...

host: ^(example\.com|example\.org)
IP: ^(1\.1\.1\.1|2\.2\.2\.2)$
(or IP: 1\.1\.1\.1|2\.2\.2\.2)

so something seems very wrong here - i thought there may be a cascading effect due to a problem with a RegEx in another rule, but i checked all of them and found no issues

debug log (again, i changed the IPs)

[2024-05-19 12:54:34]  DBG  (3) EBPF-DNS: Tracking Resolved Message: 1.1.1.1 -> 1.1.1.1
[2024-05-19 12:54:34]  DBG  new connection tcp => 48100:10.0.11.111 -> 1.1.1.1 ():44022 uid: 1000, mark: 0
[2024-05-19 12:54:34]  DBG  [ebpf conn] not in cache, but in execEvents: tcp4810010.0.11.1111.1.1.144022, 4375 -> /usr/bin/ssh
[2024-05-19 12:54:34]  DBG  [ebpf conn] adding item to cache: tcp4810010.0.11.1111.1.1.144022
[2024-05-19 12:54:37]  DBG  Operator compiled: list is '[{"type": "simple", "operand": "dest.ip", "data": "1.1.1.1"}, {"type": "simple", "operand": "process.path", "data": "/usr/bin/ssh"}]'
[2024-05-19 12:54:37]  DBG  Operator compiled: dest.ip is '1.1.1.1'
[2024-05-19 12:54:37]  IMP  Saved new rule: allow if list is '[{"type": "simple", "operand": "dest.ip", "data": "1.1.1.1"}, {"type": "simple", "operand": "process.path", "data": "/usr/bin/ssh"}]'
[2024-05-19 12:54:37]  DBG  ✔ /usr/bin/ssh -> 48100:10.0.11.111 => 1.1.1.1:44022, mark: 0 (allow-always-list-usr-bin-ssh-1-1-1-1)
[2024-05-19 12:54:37]  IMP  Ruleset changed due to allow-always-list-usr-bin-ssh-1-1-1-1.json, reloading ...
[2024-05-19 12:54:37]  DBG  Operator compiled: list is '[{"type": "simple", "operand": "dest.ip", "data": "1.1.1.1"}, {"type": "simple", "operand": "process.path", "data": "/usr/bin/ssh"}]'
[2024-05-19 12:54:37]  DBG  Operator compiled: dest.ip is '1.1.1.1'
[2024-05-19 12:54:37]  DBG  Loaded rule from /etc/opensnitchd/rules/allow-always-list-usr-bin-ssh-1-1-1-1.json: allow-always-list-usr-bin-ssh-1-1-1-1: if(list is '[{"type": "simple", "operand": "dest.ip", "data": "1.1.1.1"}, {"type": "simple", "operand": "process.path", "data": "/usr/bin/ssh"}]'){ allow always }

[atomGit]

also wonder if this might be the problem...

eBPF compatibility

[gustavo-iniguez-goya]

No, I don't think it'll be related to ebpf. ebpf affects mainly to processes and connections, but this seems to be another problem.
The process is being discovered correctly (DBG ✔ /usr/bin/ssh), so this should not be the problem.

Anyway, with the description of the issue I can't figure out what might be happening.
I think it'll be easier to debug it if you test the rule with curl or telnet. For example, given the following rule:

{
    "created": "2024-05-20 21:55:24",
    "name": "xxx",
    "enabled": true,
    "action": "allow",
    "duration": "always",
    "operator": {
        "type": "list",
        "operand": "list",
        "list": [
            {
                "type": "regexp",
                "operand": "dest.host",
                "data": "(.*\\.)?archlinux\\.org"
            },
            {
                "type": "regexp",
                "operand": "dest.ip",
                "data": "^(213\\.133\\.111\\.6)$"
            }
        ]
    }
}

I can connect using telnet to the domain (note: I have a rule to allow DNS queries to/from my stub resolver + IP to DNS nameservers)

~ $ telnet openpgpkey.archlinux.org 80
Trying 213.133.111.6...
Connected to openpgpkey.archlinux.org.
Escape character is '^]'.

could you try it with telnet and see if it prompts you to allow/deny it? in such case, take a look at the popup and see if it's a DNS request or the telnet connection .

[atomGit]

telnet openpgpkey.archlinux.org 80 results in 1 prompt for port 53 and the UI log shows 2 connections, ports 53 and 80

$ telnet openpgpkey.archlinux.org 80
Trying 2a01:4f8:222:174c::2...
Connected to openpgpkey.archlinux.org.
Escape character is '^]'.
Connection closed by foreign host.

2024-05-20 16:53:23.573312,unix:/local,1,1000,udp,53,127.0.0.1,openpgpkey.archlinux.org,/usr/bin/telnet,telnet openpgpkey.archlinux.org 80,/home/atom

2024-05-20 16:53:25.184056,unix:/local,1,1000,tcp6,80,2a01:4f8:222:174c::2,openpgpkey.archlinux.org,/usr/bin/telnet,telnet openpgpkey.archlinux.org 80,/home/atom

you bought up DNS and this reminded me that i have a local dns proxy running - dnscrypt-proxy - however, i'm also resolving through a VPN tunnel (i leave dnscrypt running anyway in case the VPN drops or i disable it and, most of the time, the VPN DNS wins the battle)

that said, the above has been true for a long time and some of these multi-host/IP rules in opensnitch have worked fine, until recently

so what has changed? nothing that i know of that would affect opensnitch, but there were2 (major) updates: there was some rather large change by the VPN, but i'm not sure what it was ... secondly, with the release of KDE Plasma 6, there was a massive number of OS updates, both KDE and non-KDE related since the non-KDE stuff was held back until the Plasma 6 release

[gustavo-iniguez-goya]

aha, I think that's the expected behaviour.

Firstly telnet tries to resolve the domain openpgpkey.archlinux.org by opening a connection to -> ip 127.0.0.1 -> port 53. There's no rule to allow this connection (*.archlinux.org+127.0.0.1 instead of *.archlinux.org+213.133.111.6), so you're prompted to allow/deny it.

Then, once the domain is resolved, it tries to connect to openpgpkey.archlinux.org -> ip 213.133.111.6 -> port 80.
The rule created for this connection matches as expected.

The rule I mentioned earlier only logs connections to port 80 for me, probably because I already have other rules for DNS.

Anyway adding VPNs and dnscrypt-proxy to the equation complicates the debugging a little bit. It'd be better to test this without VPNs and without DoH, etc., because probably you'll have a lot of netfilter rules for the VPN, routing policies, etc.

I'll test it on a fresh VM with no rules, to see if there's any difference.