> 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.
back
1 comments
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.