Hacker News Reader

Comment by rubyn00bie | Hacker News Reader

I think the whole point of LittleSnitch/OpenSnitch is the GUI. I feel like this is sort of a descendant of (or rather inspired by) a piece of software from long ago called "ZoneAlarm" for Windows. I mention this because I primarily used it before I could code or knew about the "system"; which, also happened to be when I was pirating a lot of software (high school). You should be able to accomplish most all of this, and more, from the command line already. `netstat` alone would probably get you most of the way there.

View on HN

ZoneAlarm, now there is something I haven't thought about in nearly two decades!!! (since HS or early uni)

Netstat sort of fills this niche, but not without a lot of manual toil on behalf of the operator. In general, Linux and the apps in the ecosystem are much more well-behaved with regard to "wtf is this traffic" compared to macOS or Windows.

Trust is great and all but visibility is better. Linux is still dicey to correlate traffic with a particular app, especially if the connection is/was shortlived.

> Linux is still dicey to correlate traffic with a particular app, especially if the connection is/was shortlived.

This is has become a lot easier and more reliable to do now with BPF [0].

I also used the same approach to create a somewhat user-friendly TUI and web dashboard for it [1]. It is also able to hash the executable (even if it was shortlived).

[0] https://www.gcardone.net/2020-07-31-per-process-bandwidth-mo...

[1] https://github.com/elesiuta/picosnitch

ebpf used in this way is typically nonblocking. it drops data instead of blocking. for a firewall, that’s potentially bad.

can ebpf operate in a blocking manner while making drop/allow decisions on packets WITH reliable access to the callers pid and argv?

> for a firewall, that’s potentially bad

I wasn't talking about using it as a firewall, just a connection/bandwidth monitor that correlates traffic with a particular app.

bandwidth monitor use case seems like a perfect fit, and the occasional missed packet wouldn’t be an issue.

picosnitch looks really cool! i’ve rss subscribed to its github commits.

Thanks! Also I used lost_cb [0] to detect if a packet or connection (with security_socket_connect) was missed between the BPF and Python parts, but is it possible for the BPF program to miss either entirely without triggering that callback?

If so (without a kernel vulnerability which should be a given) I'd like to have it mentioned under the limitations section for picosnitch so others can be aware as well.

[0] https://github.com/iovisor/bcc/blob/master/docs/reference_gu...

i don’t think so. i think exactly what you’ve documented is the case. if the callback can’t keep up with the data before the ringbuffer overflows, data is lost. in that case, the solution is to increase the size of the ringbuffer, giving the callback a larger window to keep up with incoming data bursts.

in the end there are only two ways to handle this: drop data or block. for a bandwidth monitor, i’d choose drop. for a firewall, i’d choose block.

i use bpftrace to monitor docker filesystem access in a similar way[1]. i also increase the ringbuffer size until i stop seeing lost data.

1. https://github.com/nathants/docker-trace#files

Very cool! I also found it recently submitted to HN: https://news.ycombinator.com/item?id=31160863

I think OpenSnitch just uses eBPF to capture metadata about the new connection, the "hold for user confirmation" does not happen inside eBPF. The eBPF does not need to block waiting for user input.

https://github.com/evilsocket/opensnitch/blob/4ce8b0e57cfb25... https://github.com/evilsocket/opensnitch/blob/d9e0c59158ddf6...

by the time a user prompt is displayed, all metadata has been joined to the packet, and libnetfilterqueue is waiting for a decision.

my understanding of what is happening is as follows:

- 1: libnetfilterqueue gets a packet.

- 2: lookup packet via ebpf to get pid and argv.

- 3: lookup rule, on miss prompt user to allow/deny.

- 4: libnetfilterqueue allows/denies the packet.

the tricky part is step 2. afaik there are 3 possibilities:

- ebpf already knows about about this packet, return pid and argv.

- ebpf will know about this packet shortly, wait, then return pid and argv.

- ebpf dropped the data because of ringbuffer overflow, wait, then give up.

My understanding: ebpf runs at connect(2) time, stores metadata in a map; later, an NFQUEUE userspace helper fetches the metadata from the map.

this is correct. it's the datarace between these components, and the possibility of ebpf dropping data because of a slow userspace callback, that makes this flaky.

Agree on the GUI however opensnitch does seem to assume a single user with a single X server, I have not been able to figure out a way last time I tried to get it to work with say 2 X servers and a VNC session or two running concurrently (meaning I couldn’t figure out a way to get connection alerts anywhere but in one of them, as also described here https://github.com/evilsocket/opensnitch/issues/388 )

Little snitch does not have this issues and you can have multiple users logged in with fast user switching and all can operate their notifications no problem.

You can use lsof in Linux to show connexions:

lsof -i -n -P | grep "\\-\>" | awk '{a[\$1"_p"\$2]++;}END{ for (it in a){print it,a[it]}}' | sort -nr -k2,2

This project uses conky to display the current connexions:

https://github.com/viviparous/plonky/blob/main/plonky.pl

that awk expression fails here (v5.1)

Ah yes, it doesn't require the escapes that I pasted above.

awk '{a[$1"_p"$2]++;}END{ for(it in a){print it,a[it]}}'

unfortunately malicious lkms and userland rootkits can hide processes/connections from lsof/netstat

https://github.com/gianlucaborello/libprocesshider

Reply on news.ycombinator.com