search

gustavo-iniguez-goya / opensnitch

OpenSnitch is a GNU/Linux application firewall
GNU General Public License v3.0
394 stars 20 forks source link

Previously working rules now show notifications? (1.0.1-1 -> 1.3.0.rc-2) #134

Open metal450 opened 3 years ago

metal450 commented 3 years ago

Hi again,

Upon upgrading from 1.0.1-1 to 1.3.0.rc-2, I find that I'm getting notifications for connections that were previously handled by rules; here's one as a concrete example:

2021-01-30_18 05 24

As you can see, the notification appeared, despite there being a rule with a matching commandline & url. Presumably the way it interpreted one or the other has changed, & my rules need to be updated accordingly?

Thanks :)

gustavo-iniguez-goya commented 3 years ago

hey @metal450 ! glad to read you again.

Save that rule again: edit it and click on Apply. Some new fields has been added, but we haven't added any way to automigrate old rules. If it still doesn't work paste the .json content of the rule.

Also you can install 1.3.5 version: https://github.com/evilsocket/opensnitch/releases/tag/v1.3.5

metal450 commented 3 years ago

Oh whoa - did u take over the other repo, so I should check there from now on? I was looking at https://github.com/gustavo-iniguez-goya/opensnitch/releases, where the latest is 1.3.0.rc-2

Sure, I'll try that version, re-save all rules & report back if I see it happen again :)

metal450 commented 3 years ago

After updating, I can no longer click 'apply' in any of the rules: it says "There're no nodes connected" in red text at the bottom of the window.

gustavo-iniguez-goya commented 3 years ago

mmh, is the Node combo box empty? at the up left of the window: image

Did you update both the daemon and the GUI? Launch the GUI from a terminal, and see if it outputs any errors. Also check the daemon log.

metal450 commented 3 years ago

Yup, I updated both.

I rebooted the system...& now I see something I've never seen before: the UI doesn't show any rules at all, and Status is flickering back & forth between 'Running' and 'Not running.'

The log shows:

[2021-02-01 18:13:10]  IMP  Got signal: terminated
[2021-02-01 18:13:15]  WAR  queue stuck, closing by timeout
[2021-02-01 18:13:15]  WAR  Queue.destroy(), nfq_close() not closed: -1
[2021-02-01 18:15:04]  IMP  Start writing logs to %!(EXTRA string=/var/log/opensnitchd.log)
[2021-02-01 18:15:43]  IMP  Start writing logs to %!(EXTRA string=/var/log/opensnitchd.log)
[2021-02-01 18:16:14]  IMP  Start writing logs to %!(EXTRA string=/var/log/opensnitchd.log)

...And the last lines just keep repeating.

gustavo-iniguez-goya commented 3 years ago

woah, I haven't seen that error before. Version 1.3.5? Ensure that the default configuration (/etc/opensnitchd/default-config.json) has all these fields:

{
    "Server":
    {
        "Address":"unix:///tmp/osui.sock",
        "LogFile":"/var/log/opensnitchd.log"
    },
    "DefaultAction": "allow",
    "DefaultDuration": "once",
    "InterceptUnknown": false,
    "ProcMonitorMethod": "proc",
    "LogLevel": 2
}

There should also be a system-fw.json in /etc/opensnitchd/ https://github.com/evilsocket/opensnitch/blob/master/daemon/system-fw.json:


{
    "SystemRules": [
        {
            "Rule": {
                "Description": "Allow icmp",
                "Table": "mangle",
                "Chain": "OUTPUT",
                "Parameters": "-p icmp",
                "Target": "ACCEPT",
                "TargetParameters": ""
            }
        }
    ]
}
metal450 commented 3 years ago

Yup, they're there, with those exact contents.

gustavo-iniguez-goya commented 3 years ago

Ok, please, change LogLevel to 0, restart the service/kill the daemon and post the output.

metal450 commented 3 years ago

What's the easiest way to kill/restart the service? I'd always just fully rebooted my PC to be sure.

gustavo-iniguez-goya commented 3 years ago

pkill -15 opensnitchd should stop it. If not, pkill -9 opensnitchd

metal450 commented 3 years ago 
[2021-02-01 19:13:52]  INF  Process monitor method /proc
[2021-02-01 19:13:52]  DBG  UI service poller started for socket /tmp/osui.sock
[2021-02-01 19:13:52]  INF  Running on netfilter queue #0 ...
[2021-02-01 19:13:53]  DBG  new connection udp6 => 37203:fe80::9e5b:cb0a:9f28:1ec5 -> ff12::8384:21027 uid: %!(EXTRA uint32=1000)
[2021-02-01 19:13:53]  DBG  [0/1] outgoing connection: 37203:fe80::9e5b:cb0a:9f28:1ec5 -> ff12::8384:21027 || netlink response: 37203::: -> :::0 inode: 45646 - loopback: false multicast: false unspecified: true linklocalunicast: false ifaceLocalMulticast: false GlobalUni: false 
[2021-02-01 19:13:53]  DBG  GetSocketInfo() invalid: 37203::: -> :::0
[2021-02-01 19:13:53]  DBG  netlink socket not found, adding entry:  37203:fe80::9e5b:cb0a:9f28:1ec5 -> ff12::8384:21027 || 37203::: -> :::0 inode: 45646 state: close
[2021-02-01 19:13:53]  DBG  new pid lookup took (3440): 24.944067ms
[2021-02-01 19:13:53]  DBG  [0] PID found 3440
[2021-02-01 19:14:23]  IMP  Start writing logs to %!(EXTRA string=/var/log/opensnitchd.log)
[2021-02-01 19:14:23]  INF  Process monitor method /proc
[2021-02-01 19:14:23]  DBG  UI service poller started for socket /tmp/osui.sock
[2021-02-01 19:14:23]  INF  Running on netfilter queue #0 ...
[2021-02-01 19:14:24]  INF  Connected to the UI service on /tmp/osui.sock
[2021-02-01 19:14:24]  INF  Start receiving notifications
[2021-02-01 19:14:31]  DBG  new connection tcp => 48052:127.0.0.1 -> 127.0.0.1:8384 uid: %!(EXTRA uint32=1000)
[2021-02-01 19:14:31]  DBG  [0/1] outgoing connection: 48052:127.0.0.1 -> 127.0.0.1:8384 || netlink response: 48052:127.0.0.1 -> 127.0.0.1:8384 inode: 194962 - loopback: true multicast: false unspecified: false linklocalunicast: false ifaceLocalMulticast: false GlobalUni: false 
[2021-02-01 19:14:31]  DBG  new pid lookup took (3182): 52.481391ms
[2021-02-01 19:14:31]  DBG  [0] PID found 3182
[2021-02-01 19:15:01]  IMP  Start writing logs to %!(EXTRA string=/var/log/opensnitchd.log)
[2021-02-01 19:15:01]  INF  Process monitor method /proc
[2021-02-01 19:15:01]  DBG  UI service poller started for socket /tmp/osui.sock
[2021-02-01 19:15:01]  INF  Running on netfilter queue #0 ...
[2021-02-01 19:15:02]  INF  Connected to the UI service on /tmp/osui.sock
[2021-02-01 19:15:02]  INF  Start receiving notifications
[2021-02-01 19:15:17]  DBG  new connection udp => 36247:127.0.0.1 -> 127.0.0.53:53 uid: %!(EXTRA uint32=1000)
[2021-02-01 19:15:17]  DBG  [0/1] outgoing connection: 36247:127.0.0.1 -> 127.0.0.53:53 || netlink response: 36247:127.0.0.1 -> 127.0.0.53:53 inode: 192999 - loopback: true multicast: false unspecified: false linklocalunicast: false ifaceLocalMulticast: false GlobalUni: false 
[2021-02-01 19:15:17]  DBG  new pid lookup took (9133): 22.756607ms
[2021-02-01 19:15:17]  DBG  [0] PID found 9133
gustavo-iniguez-goya commented 3 years ago

mm, check if there're more than one daemon running: pgrep -a opensnitchd

You can also stop the service to not relaunch it automatically: sudo service opensnitchd stop and launch it from the command line: sudo /usr/bin/opensnitchd -rules-path /etc/opensnitchd/rules/

I'm going to try to reproduce it.

metal450 commented 3 years ago

mm, check if there're more than one daemon running: pgrep -a opensnitchd

Nope....it didn't even show one daemon running...

You can also stop the service to not relaunch it automatically: sudo service opensnitchd stop and launch it from the command line: sudo /usr/bin/opensnitchd -rules-path /etc/opensnitchd/rules/

metal450@Latitude-5490-Kubuntu:~$ sudo /usr/bin/opensnitchd -rules-path /etc/opensnitchd/rules/
[2021-02-01 19:41:29]  IMP  Starting opensnitch-daemon v1.3.5
[2021-02-01 19:41:29]  INF  Loading rules from /etc/opensnitchd/rules ...
OK: libnetfiler_queue supports nfq_get_uid
panic: interface conversion: interface {} is net.IP, not string

goroutine 27 [running]:
github.com/evilsocket/opensnitch/daemon/rule.(*Operator).reCmp(0xc00009c7b8, 0x91f720, 0xc00038eb40, 0xc00038eb40)
        github.com/evilsocket/opensnitch/daemon/rule/operator.go:126 +0x16f
github.com/evilsocket/opensnitch/daemon/rule.(*Operator).Match(0xc00009c7b8, 0xc000596000, 0xc00009a520)
        github.com/evilsocket/opensnitch/daemon/rule/operator.go:178 +0x31a
github.com/evilsocket/opensnitch/daemon/rule.(*Rule).Match(...)
        github.com/evilsocket/opensnitch/daemon/rule/rule.go:65
github.com/evilsocket/opensnitch/daemon/rule.(*Loader).FindFirstMatch(0xc0000aa000, 0xc000596000, 0x0)
        github.com/evilsocket/opensnitch/daemon/rule/loader.go:311 +0x125
main.acceptOrDeny(0xc0002f5f18, 0xc000596000, 0x0)
        github.com/evilsocket/opensnitch/daemon/main.go:215 +0x9e
main.onPacket(0x9ef3e0, 0xc000588000, 0x0, 0xc000586000, 0x4000003e8)
        github.com/evilsocket/opensnitch/daemon/main.go:193 +0x13f
main.worker(0x2)
        github.com/evilsocket/opensnitch/daemon/main.go:131 +0xc9
created by main.setupWorkers
        github.com/evilsocket/opensnitch/daemon/main.go:143 +0xe5
metal450 commented 3 years ago

After restarting per above, pgrep still shows no instances.

gustavo-iniguez-goya commented 3 years ago

Ok!!! that error is fixed but we haven't released a new version yet. I can build packages for you with latest changes if you agree.

metal450 commented 3 years ago

Of course, if that's what will get it up & running again :)

gustavo-iniguez-goya commented 3 years ago

Added, rename the files to .deb and let me know if it solves the error.

python3-opensnitch-ui_1.3.6-1_all.deb.txt opensnitch_1.3.6-1_amd64.deb.txt

metal450 commented 3 years ago

Alright - it's definitely...running now, haha. But after a reboot, I got a million connection prompts for everything - I tried clicking them away for a few minutes, but they just kept coming, so eventually I killed the process so that I could access the internet again & come write this comment. Maybe I need to go in & re-save every existing rule I had or something....?

gustavo-iniguez-goya commented 3 years ago

I'm afraid yes.. the old rules need to be re-saved. Also set LogLevel to 1, and monitor the log for any error.

metal450 commented 3 years ago

K, will get started on that - it will take some time, there are a lot.

Suggestion for future version: add a 'version' number to each rule. Then if any subsequent updates make additions/changes, it would be easy for the software to recognize which were produced with (or haven't been updated since) a previous version, & could automatically update them

metal450 commented 3 years ago

Ok, seems there might still be an issue, tho a different one: with new notifications, clicking 'Allow' doesn't seem to work - it just keeps re-prompting for the same thing. Here's a screenshare: (link removed)

metal450 commented 3 years ago

Sorry! Nevermind, disregard my previous post - looks like it was just because it was 'allow once' vs i.e. allow for 15min or something :)

gustavo-iniguez-goya commented 3 years ago

ok! let me know if you find any other problem.

Going from 1.0.1 to 1.3.6 is a huge jump, there has been many changes. But it should work as expected.

metal450 commented 3 years ago

Will do, thanks!

Since the issue of this thread seems resolved, I'll go ahead & close :)

gustavo-iniguez-goya commented 3 years ago

By the way, I noticed that you filter some tracking domains. There's a branch (not published yet) that adds a new type of rules, which loads lists of domains to block (like the ones used in uBlock, pi-hole, etc): https://github.com/evilsocket/opensnitch/issues/298#issuecomment-748388911

Do you think it would be useful? I haven't got many feedback from the community. It would only apply the action on connections.

metal450 commented 3 years ago

Personally, I don't think I'd - I just do them on a per-application basis as-needed.

metal450 commented 3 years ago

Ok, it looks like I'm actually still getting some notifications for things that I think should still be blocked - see screenshot below. I 100% definitely 're-applied' this rule since the update, yet it notified me for the same binary:

2021-02-02 14 12 18

metal450 commented 3 years ago

I figured it out again. The notification was showing /usr/lib/snapd/snapd, but when I viewed the resulting rule it created, it was actually /snap/core/10583/usr/lib/snapd/snapd - and blocking /snap/core/.*/usr/lib/snapd/snapd prevented the pop-ups. So it looks like it's just an issue of the popup showing not the whole path (i.e. it was missing /snap/core/10583), whereas when I click 'Deny' then see the rule it actually makes, the full path was there.

gustavo-iniguez-goya commented 3 years ago

mm, interesting. What system are you using? I'll try to reproduce it.

metal450 commented 3 years ago

Kubuntu 20.04

gustavo-iniguez-goya commented 3 years ago

@metal450 , I've reproduced this issue. The thing is that /usr/lib/snapd/snapd exists in the system (dpkg -S snapd), but when you install any snap package, it also downloads the snapd daemon to /snap/snapd/<PID>/usr/lib/snapd/snapd

I think that the pop-ups are correct in both cases, one for /usr/lib/snapd/snapd and another one for /snap/snapd/.*

I don't fully understand how it works. In my kubuntu the dameon that is running is /usr/lib/snapd/snapd and before installing any snap packages (/snap/ directory was empty) that was the one that opened connections. After installing one snap package, /usr/lib/snapd/snapd is still running, but the one which opens connections is /snap/snapd/<PID>/usr/lib/snapd/snapd. Probably it's in its own sandbox, container, namespace or whatever.

I'll review why the path label is not displayed in one line (in contrast to gnome, cinnamon, etc..)

gustavo-iniguez-goya commented 3 years ago

a regexp to match connections for both cases could be: ^(/snap/snapd/[0-9]+)usr/lib/snapd/snapd

metal450 commented 3 years ago

Sure - personally I'm fine with how it is, now that I know it's working (I just have two separate rules, one for the 'main' daemon & one with a wildcard per above). Just thought I'd mention it s it might be confusing to others, as it seems to be reporting one path in the notification, & creating a rule based on that, but then it keeps coming up because the rule doesn't apply to where the connections were "really" coming from. In any case, I'm happy with where I'm at :)

metal450 commented 3 years ago

Nice, even more concise :)

gustavo-iniguez-goya commented 3 years ago

yep, I understand the confusion. This also occurs with kdeinit and its plugins smb.so, http.so, etc... I've read some comments wondering if it was a bug.

gustavo-iniguez-goya commented 3 years ago

I've realized that there's an error when saving/loading the default duration of the popups. That's why by default the duration is (always?) "once".

These files fix that problem (open the UI->preferences and configure it as you want again) : config.py.txt -> /usr/lib/python3/dist-packages/opensnitch/config.py preferences.py.txt -> /usr/lib/python3/dist-packages/opensnitch/dialogs/preferences.py prompt.py.txt -> /usr/lib/python3/dist-packages/opensnitch/dialogs/prompt.py

Regarding the path label, copy this file to /usr/lib/python3/dist-packages/opensnitch/res/prompt.ui prompt.ui.txt

I'd thank you if you could test these files and confirm that at least it doesn't break anything.

metal450 commented 3 years ago

I replaced the files & rebooted, no obvious issue out of the gate. I'll report back if I do later observe something broken.