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

metal450 · 2021-01-31T02:08:41Z

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:

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 · 2021-01-31T23:31:29Z

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 · 2021-02-01T07:44:07Z

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 · 2021-02-01T07:49:54Z

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 · 2021-02-01T17:26:41Z

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

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 · 2021-02-01T18:20:03Z

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:

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

...And the last lines just keep repeating.

gustavo-iniguez-goya · 2021-02-01T18:40:13Z

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 · 2021-02-01T18:42:33Z

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

gustavo-iniguez-goya · 2021-02-01T19:06:47Z

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

metal450 · 2021-02-01T19:07:49Z

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

gustavo-iniguez-goya · 2021-02-01T19:12:45Z

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

metal450 · 2021-02-01T19:16:37Z

�[2m[2021-02-01 19:13:52]�[0m �[97m�[42m INF �[0m Process monitor method /proc
�[2m[2021-02-01 19:13:52]�[0m �[2m�[30m�[100m DBG �[0m UI service poller started for socket /tmp/osui.sock
�[2m[2021-02-01 19:13:52]�[0m �[97m�[42m INF �[0m Running on netfilter queue #0 ...
�[2m[2021-02-01 19:13:53]�[0m �[2m�[30m�[100m DBG �[0m new connection udp6 => 37203:fe80::9e5b:cb0a:9f28:1ec5 -> ff12::8384:21027 uid: %!(EXTRA uint32=1000)
�[2m[2021-02-01 19:13:53]�[0m �[2m�[30m�[100m DBG �[0m [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 
�[2m[2021-02-01 19:13:53]�[0m �[2m�[30m�[100m DBG �[0m GetSocketInfo() invalid: 37203::: -> :::0
�[2m[2021-02-01 19:13:53]�[0m �[2m�[30m�[100m DBG �[0m netlink socket not found, adding entry:  37203:fe80::9e5b:cb0a:9f28:1ec5 -> ff12::8384:21027 || 37203::: -> :::0 inode: 45646 state: close
�[2m[2021-02-01 19:13:53]�[0m �[2m�[30m�[100m DBG �[0m new pid lookup took (3440): 24.944067ms
�[2m[2021-02-01 19:13:53]�[0m �[2m�[30m�[100m DBG �[0m [0] PID found 3440
�[2m[2021-02-01 19:14:23]�[0m �[97m�[104m IMP �[0m Start writing logs to %!(EXTRA string=/var/log/opensnitchd.log)
�[2m[2021-02-01 19:14:23]�[0m �[97m�[42m INF �[0m Process monitor method /proc
�[2m[2021-02-01 19:14:23]�[0m �[2m�[30m�[100m DBG �[0m UI service poller started for socket /tmp/osui.sock
�[2m[2021-02-01 19:14:23]�[0m �[97m�[42m INF �[0m Running on netfilter queue #0 ...
�[2m[2021-02-01 19:14:24]�[0m �[97m�[42m INF �[0m Connected to the UI service on /tmp/osui.sock
�[2m[2021-02-01 19:14:24]�[0m �[97m�[42m INF �[0m Start receiving notifications
�[2m[2021-02-01 19:14:31]�[0m �[2m�[30m�[100m DBG �[0m new connection tcp => 48052:127.0.0.1 -> 127.0.0.1:8384 uid: %!(EXTRA uint32=1000)
�[2m[2021-02-01 19:14:31]�[0m �[2m�[30m�[100m DBG �[0m [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 
�[2m[2021-02-01 19:14:31]�[0m �[2m�[30m�[100m DBG �[0m new pid lookup took (3182): 52.481391ms
�[2m[2021-02-01 19:14:31]�[0m �[2m�[30m�[100m DBG �[0m [0] PID found 3182
�[2m[2021-02-01 19:15:01]�[0m �[97m�[104m IMP �[0m Start writing logs to %!(EXTRA string=/var/log/opensnitchd.log)
�[2m[2021-02-01 19:15:01]�[0m �[97m�[42m INF �[0m Process monitor method /proc
�[2m[2021-02-01 19:15:01]�[0m �[2m�[30m�[100m DBG �[0m UI service poller started for socket /tmp/osui.sock
�[2m[2021-02-01 19:15:01]�[0m �[97m�[42m INF �[0m Running on netfilter queue #0 ...
�[2m[2021-02-01 19:15:02]�[0m �[97m�[42m INF �[0m Connected to the UI service on /tmp/osui.sock
�[2m[2021-02-01 19:15:02]�[0m �[97m�[42m INF �[0m Start receiving notifications
�[2m[2021-02-01 19:15:17]�[0m �[2m�[30m�[100m DBG �[0m new connection udp => 36247:127.0.0.1 -> 127.0.0.53:53 uid: %!(EXTRA uint32=1000)
�[2m[2021-02-01 19:15:17]�[0m �[2m�[30m�[100m DBG �[0m [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 
�[2m[2021-02-01 19:15:17]�[0m �[2m�[30m�[100m DBG �[0m new pid lookup took (9133): 22.756607ms
�[2m[2021-02-01 19:15:17]�[0m �[2m�[30m�[100m DBG �[0m [0] PID found 9133

gustavo-iniguez-goya · 2021-02-01T19:33:10Z

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 · 2021-02-01T19:42:23Z

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 · 2021-02-01T19:43:33Z

After restarting per above, pgrep still shows no instances.

gustavo-iniguez-goya · 2021-02-01T19:51:09Z

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 · 2021-02-01T20:01:15Z

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

gustavo-iniguez-goya · 2021-02-01T20:32:45Z

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 · 2021-02-01T20:42:53Z

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 · 2021-02-01T20:46:54Z

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 · 2021-02-01T20:50:40Z

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 · 2021-02-01T21:00:46Z

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 · 2021-02-01T21:01:51Z

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 · 2021-02-01T21:03:44Z

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 · 2021-02-01T21:06:11Z

Will do, thanks!

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

gustavo-iniguez-goya · 2021-02-01T21:16:37Z

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):
evilsocket#298 (comment)

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 · 2021-02-01T21:18:53Z

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

metal450 · 2021-02-02T22:14:11Z

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:

metal450 · 2021-02-02T22:34:07Z

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 · 2021-02-02T23:13:02Z

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

metal450 · 2021-02-02T23:27:18Z

Kubuntu 20.04

gustavo-iniguez-goya · 2021-02-03T22:40:33Z

@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 · 2021-02-03T22:45:12Z

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

metal450 · 2021-02-03T22:45:25Z

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 · 2021-02-03T22:45:33Z

Nice, even more concise :)

gustavo-iniguez-goya · 2021-02-03T22:51:51Z

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 · 2021-02-04T22:55:22Z

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 · 2021-02-04T23:47:36Z

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

metal450 closed this as completed Feb 1, 2021

metal450 reopened this Feb 2, 2021

gustavo-iniguez-goya mentioned this issue Feb 6, 2021

How to setup for WireGuard? #61

Closed

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

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

Comments

metal450 commented Jan 31, 2021

gustavo-iniguez-goya commented Jan 31, 2021

metal450 commented Feb 1, 2021

metal450 commented Feb 1, 2021

gustavo-iniguez-goya commented Feb 1, 2021

metal450 commented Feb 1, 2021

gustavo-iniguez-goya commented Feb 1, 2021

metal450 commented Feb 1, 2021

gustavo-iniguez-goya commented Feb 1, 2021

metal450 commented Feb 1, 2021

gustavo-iniguez-goya commented Feb 1, 2021

metal450 commented Feb 1, 2021

gustavo-iniguez-goya commented Feb 1, 2021

metal450 commented Feb 1, 2021

metal450 commented Feb 1, 2021

gustavo-iniguez-goya commented Feb 1, 2021

metal450 commented Feb 1, 2021

gustavo-iniguez-goya commented Feb 1, 2021

metal450 commented Feb 1, 2021

gustavo-iniguez-goya commented Feb 1, 2021

metal450 commented Feb 1, 2021

metal450 commented Feb 1, 2021 • edited

metal450 commented Feb 1, 2021

gustavo-iniguez-goya commented Feb 1, 2021

metal450 commented Feb 1, 2021

gustavo-iniguez-goya commented Feb 1, 2021

metal450 commented Feb 1, 2021

metal450 commented Feb 2, 2021

metal450 commented Feb 2, 2021

gustavo-iniguez-goya commented Feb 2, 2021

metal450 commented Feb 2, 2021

gustavo-iniguez-goya commented Feb 3, 2021

gustavo-iniguez-goya commented Feb 3, 2021

metal450 commented Feb 3, 2021

metal450 commented Feb 3, 2021

gustavo-iniguez-goya commented Feb 3, 2021

gustavo-iniguez-goya commented Feb 4, 2021

metal450 commented Feb 4, 2021

metal450 commented Feb 1, 2021 •

edited