Slow ?

[squalou]

Hi, with opensnitch up and running, I clearly noticed less responsive network operations. Seems 'logical' since there's somehting in between ... but I'm surprised its that much noticeable.

For instance, I'm running Arch, issuing 'yaourt -Syu' to synchronise packages databases:

• without opensnitch : 1,7s
• with opensnicth : 24s

Same thing when mounting smb shares etc.

I'm running this on a powerfull laptop (last year xps13 with core i7 and 16g ram) on a gigabyte fiber network. Also, opensnitchd is not consuming lot of cpu, rarely more than 1%, so .. I don't know.

Is this something to be expected or is there possily something wrong / something I can do ?

thanks

[evilsocket]

Considering this project is not 1.0.0 yet, yes, it is expected :) It'd be great if you could run the daemon with the -cpu-profile some-file-name.here and -mem-profile some-other-file-name.here arguments, stop it after a while you're noticing such slowdowns and upload the files here, thanks :)

[squalou]

I'm pleased to help if I can,

here are the files, after a few minutes and some slow operations (like above : smb mount, package db sync)

cpu-and-mem-profiles.zip

[Nadrieril]

Would it make sense to add ACCEPT/DROP rules to iptables whenever opensnitch marks a process+destination as allowed/denied ? That should solve the speed problem since only connections from new processes or to new destinations would need to go through opensnitch, and iptables filtering is super fast.

[squalou]

maybe a good idea, provided opensnitch cleans up iptables rules when it's closed or killed, or restarted... which is probably not that easy to manage. I'd hate having to manually deal with iptables rules the day I want to stop opensitch for whatever reason, or if it fails starting.

[Nadrieril]

I would set up a chain so that you only need to remove that chain in order to remove all the opensnitch-added rules. If you think it's a good idea and once I have managed to compile opensnitch, I may try to write a PR for that

[evilsocket]

What rule would you use to block a specific app instead of a specific destination?

[Nadrieril]

The owner iptable match seems to be able to do that: https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#OWNERMATCH

[evilsocket]

I don't know iptables enough, do you think it can cover all of these cases ?

[Nadrieril]

I am sure it can do all of those, except process.cmd, process.path and process.env. process.env is definitely not an option; and I think --cmd-owner should work for either process.path or process.cmd but I'm not sure which.

[Nadrieril]

Looking at the iptables source, it appears that --cmd-owner has stopped working in 2004, so we can't have process.path or process.cmd I'm afraid :(

[evilsocket]

thing is, there's already something -similar- to that implemented, basically here i mark packets that a DENY rule matched and here I tell iptables to just DROP such packets ... but I keep getting those connections events anyway, I guess this NFQUEUE mark thingy is per-packet and not per-connection ... or there's a bug somewhere ... or I got it completely wrong ... need more time to debug :P

[Nadrieril]

When setting up complex firewalling/routing, I usually have a rule that says -m state --state RELATED,ESTABLISHED -j ACCEPT. This makes it so that when you accept a packet from a new connection, all further packets from the same connection get allowed as well. Maybe that would do what you need ? (cf. https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#STATEMATCH)

[Nadrieril]

Also I'd be curious to know how often your DROP rule gets activated, because I would have thought that denying the packet in the queue would be enough for it to be dropped (but I'm no iptables expert).

[evilsocket]

@Nadrieril would you be able to send a PR with this additional rule?

[Nadrieril]

I'm sorry, I've never gotten to using opensnitch on my system so I don't have time to contribute to it. I might try setting it up again in a few months but I'm not even sure.

[endorama]

Hello, I'm currently using opensnitch on a daily basis, and the performance penalty is really taxing.

I would gladly contribute, but need a bit more information: if I got this right, the rule -m state --state RELATED,ESTABLISHED -j ACCEPT should be added to the OUTPUT chain, adding a new function to daemon/firewall/rules.go file, correct?

Then this function should be run before firewall.QueueConnection in main.go#L261.

If this is it I should be able to provide a PR for the end of the week.

BTW: this software is great, so nice work!

[gustavo-iniguez-goya]

This should be fixed with latest packages.