4 ms·

On Linux there is OpenSnitch that does its job nicely, although I experienced some occasional desktop slowdowns even after training it to open everything for tr

On Linux there is OpenSnitch that does its job nicely, although I experienced some occasional desktop slowdowns even after training it to open everything for trusted programs. https://github.com/evilsocket/opensnitch https://github.com/evilsocket/opensnitch I still recall the old days of Windows when I tried Kerio Personal Firewall and realized how much software already phoned home two decades ago. That was the last wake up call that pushed me into getting rid of closed source software, possibly also hardware, especially when they connect to the internet.

elesiuta 4y ago
The slowdowns are because it still has to hold every connection until it can check which program it is coming from and whether that program is trusted or not, even when the same program creates multiple connections. To get around the slowdowns, I made an alternative program called picosnitch which only monitors connections since I just stop using anything I don't trust or move it to a sandbox. It also uses BPF, has fairly low CPU usage, and some other features for improved reliability and detection of programs.
Abishek_Muthian 4y ago
I second OpenSnitch, I haven't face any shutdowns due to it yet. For those coming from LittleSnitch on macOS might have to look into the finer details of the connection in the Allow/Deny dialog on OS to get the best results.
- squarefoot 4y ago
  Slowdowns, not shutdowns, luckily:) The desktop (XFCE under Debian if that helps) just hung for a while like it was waiting for me to allow some rules, but didn't show the requester to do so, also the timings were random, could have been from 2 seconds to 5 or more.
  - Abishek_Muthian 4y ago
    Oops; Self-reminder to not comment on HN when half sleep. But, I haven't noticed slowdown either; I wonder whether its because I always keep the OS window open?
egberts1 4y ago
Keep in mind, OpenSnitch is Linux-based and none of Linux firewalls can filter incoming packets by process ID like macOS/FreeBSD (Lil'Snitch) can.
- prmoustache 4y ago
  From what I understand opensnitch use ebpf to match where the exiting packets are going. TCP being TCP, it is easy to know where the incoming answer will be delivered to as well.
  - squarefoot 4y ago
    Not sure if this would work also for connectionless protocols such as UDP. That is, if I open a socket and send some datagrams to an external address:port to exfiltrate users data, then close the socket and exit, I don't think it would be able to tell which program did that, unless it detects it live.
    - prmoustache 4y ago
      I believe opensnitch catches them.
- doubled112 4y ago
  I think iptables was supposed to be able to do this, right? https://linux.die.net/man/8/iptables https://linux.die.net/man/8/iptables --pid-owner processid Matches if the packet was created by a process with the given process id. But was disappointed by the note: > NOTE: pid, sid and command matching are broken on SMP
  - yrro 4y ago
    --pid-owner was removed from Linux some time in the 2.4 days IIRC. That's a really outdated version of the man page. The current one is: https://ipset.netfilter.org/iptables-extensions.man.html https://ipset.netfilter.org/iptables-extensions.man.html Probably the closest thing these days is to use the cgroup match extension, together with something that makes sure separate apps are moved to their own cgroup. But that cgroup would be under a separate parent cgroup for each user so it's not ideal. I expect NFQUEUE or some EBPF magic is a better way to do things - you don't want to be constantly adding/removing per-process iptables rules.

elesiuta 4y ago

The slowdowns are because it still has to hold every connection until it can check which program it is coming from and whether that program is trusted or not, even when the same program creates multiple connections. To get around the slowdowns, I made an alternative program called picosnitch which only monitors connections since I just stop using anything I don't trust or move it to a sandbox. It also uses BPF, has fairly low CPU usage, and some other features for improved reliability and detection of programs.

Abishek_Muthian 4y ago

I second OpenSnitch, I haven't face any shutdowns due to it yet. For those coming from LittleSnitch on macOS might have to look into the finer details of the connection in the Allow/Deny dialog on OS to get the best results.

squarefoot 4y ago
Slowdowns, not shutdowns, luckily:) The desktop (XFCE under Debian if that helps) just hung for a while like it was waiting for me to allow some rules, but didn't show the requester to do so, also the timings were random, could have been from 2 seconds to 5 or more.
- Abishek_Muthian 4y ago
  Oops; Self-reminder to not comment on HN when half sleep. But, I haven't noticed slowdown either; I wonder whether its because I always keep the OS window open?

egberts1 4y ago

Keep in mind, OpenSnitch is Linux-based and none of Linux firewalls can filter incoming packets by process ID like macOS/FreeBSD (Lil'Snitch) can.

prmoustache 4y ago
From what I understand opensnitch use ebpf to match where the exiting packets are going. TCP being TCP, it is easy to know where the incoming answer will be delivered to as well.
- squarefoot 4y ago
  Not sure if this would work also for connectionless protocols such as UDP. That is, if I open a socket and send some datagrams to an external address:port to exfiltrate users data, then close the socket and exit, I don't think it would be able to tell which program did that, unless it detects it live.
  - prmoustache 4y ago
    I believe opensnitch catches them.
doubled112 4y ago
I think iptables was supposed to be able to do this, right? https://linux.die.net/man/8/iptables https://linux.die.net/man/8/iptables --pid-owner processid Matches if the packet was created by a process with the given process id. But was disappointed by the note: > NOTE: pid, sid and command matching are broken on SMP
- yrro 4y ago
  --pid-owner was removed from Linux some time in the 2.4 days IIRC. That's a really outdated version of the man page. The current one is: https://ipset.netfilter.org/iptables-extensions.man.html https://ipset.netfilter.org/iptables-extensions.man.html Probably the closest thing these days is to use the cgroup match extension, together with something that makes sure separate apps are moved to their own cgroup. But that cgroup would be under a separate parent cgroup for each user so it's not ideal. I expect NFQUEUE or some EBPF magic is a better way to do things - you don't want to be constantly adding/removing per-process iptables rules.