Live data from Hacker News

EBPFSnitch: An eBPF based Linux Application Firewall

github.com

31–40 of 71 posts

Re: EBPFSnitch: An eBPF based Linux Application Firewall

#31
post #26

Earlier quoted context omitted.

I don’t see a single parameter of the process ID.

Well yes you don't get it with a parameter you get it with this helper function while in those contexts `bpf_get_current_pid_tgid`. Edit to provide link: https://elixir.bootlin.com/linux/v4.6/source/samples/bpf/bpf...

Using same bootlin search engine using your link, function nor variable not found.

Furthermore, the process ID is not yet identified at early inbound stage of EBPD. We would be talking about being past the pre-inbound stage, post-table-lookup stage, and specifically just during the input-to-user land stage.

Re: EBPFSnitch: An eBPF based Linux Application Firewall

#32

I get the point of it, but I think it's a distraction from the solutions we really need. The whole idea of app firewalls is "do/don't let an arbitrary network communication happen unless I know about it". The problem is, what if what you allow still involves an attacker? Say you allow some network connection from application A to site Z using protocols B,C. And say that you even inspect the connection using DLP. Ther…

What would you propose instead?

Re: EBPFSnitch: An eBPF based Linux Application Firewall

#33
post #13
post #3

Earlier quoted context omitted.

Be careful with that one, this isn't as capable as the HIDS solutions available on Windows - it's not going to do things like detect exfiltration using other executables or modification of other files on your system. For example, if you allowed curl or Firefox, another executable can simply call one of them and send/receive whatever data they need to. It also can't do things like filter ptrace calls which could easil…

How does Windows prevent this type of bypass? It seems extremely hard to prevent in an unsandboxed environment.

I'm not sure what they are talking about, but windows comes with a built-in sandbox now. Adds a little bit of overhead, but besides that works very well.

Re: EBPFSnitch: An eBPF based Linux Application Firewall

#34

If you're interested in this, you may be interested in this as well: https://github.com/evilsocket/opensnitch It has a GUI interface as well.

They're both pretty bad for something so simple. Tons of dependencies, complexity that shouldn't be there and perplexing code. evilsocket/opensnitch is worse but EBPFSnitch could also be a lot better.

If they're both "pretty bad for something so simple"... then it seems like a classic example of a problem that you could just release a solution for; then there would be a non-sucky solution available!

Unless it's actually not that simple?

You could at least make constructive criticism instead of just dismissively saying that all solutions suck. ("Tons of dependencies", "complexity", and "perplexing" are not actionable criticisms... they're highly subjective opinions.)

Re: EBPFSnitch: An eBPF based Linux Application Firewall

#35

If you're interested in this, you may be interested in this as well: https://github.com/evilsocket/opensnitch It has a GUI interface as well.

They're both pretty bad for something so simple. Tons of dependencies, complexity that shouldn't be there and perplexing code. evilsocket/opensnitch is worse but EBPFSnitch could also be a lot better.

evilsocket/OpenSnitch is one of the cleaner code bases I have seen, especially for the functionality it implements. What other complexity are you alluding to?

Re: EBPFSnitch: An eBPF based Linux Application Firewall

#37

I get the point of it, but I think it's a distraction from the solutions we really need. The whole idea of app firewalls is "do/don't let an arbitrary network communication happen unless I know about it". The problem is, what if what you allow still involves an attacker? Say you allow some network connection from application A to site Z using protocols B,C. And say that you even inspect the connection using DLP. Ther…

What would you propose instead?

I'd start by making all network protocols stacked flat with metadata about their being joined together, rather than loosely embedded in one another like matryoshka dolls. This can be done using existing protocols by demarcating each stack layer in an existing stream and adding metadata to link the parts together as they are composed. The end result is that the entire network path is preserved and available for inspection at any point along the network path. By using the metadata, each layer can remain private, but also be directly accessed by any network node that has the proper authorization to view it. This solves service routing issues, middleware issues, application-service integration issues, and end to end security issues.

Wrt our current conversation, you could have a network filter which only allows network communications whose packets at a particular layer are authenticated by a particular identity provider, authorized by a particular service provider, encrypted by a particular standard, and pass only a particular set of data using a particular data standard.

But looking further, you could have much bigger impacts. For example, right now we have to use NAT for IPv4 because there's no way for a private network to route directly to public networks and vice versa. But with this new scheme, the route tables, host addresses, the DNS, TCP protocol, service address (the address of the service should not require numbering at all, it should just pass a URI and boxes along the way should translate how to route to it based on that local network's definitions), and the various data payloads and formats, all would be delivered to every hop along the way up to the app server. The server reply would be carried back the same way just by reversing the order of the path. And so you could actually route messages between multiple sets of public and private networks, and those networks would allow the traffic or not based on the authn+z protocols and policies at each segment.

(Particularly, the application on the user's device would be prompted by the OS whether to accept the packets, similar to how the application firewall works. Except it could actually verify that each data payload was not just signed by a key on a random load balancer, but that it's actually been passed by an application with a valid OAuth session (but not OAuth since much better protocols would be used))

None of this assumes backwards compatibility (again, it's a revolution, not an incremental change). But there are some hacks that could be used to implement some of these features with existing protocols, to make transition easier. However, it's been shown time and again that all we really need to implement breaking changes in internet infrastructure is for a sufficiently large company to force it.

Re: EBPFSnitch: An eBPF based Linux Application Firewall

#39
post #27
post #19

Earlier quoted context omitted.

This isn't upvoted enough. I use that trick verbatim to just wrap a container's execution environment around my $PWD. It's useful way beyond just isolating a program.

I've used `alias shit='docker run --rm -it --entrypoint /bin/sh -v $PWD:/workdir -w /workdir'` for a long time. This way, whenever I need, I can just run `shit alpine` or `shit ubuntu` or whatever.

I have the same as dri (docker run interactive) and dri_cwd so current directory only mounts intentionally (with dri_cwd)

Re: EBPFSnitch: An eBPF based Linux Application Firewall

#40
post #12

Reminds me of good old Kerio Personal Firewall on Windows back in the 90s. If the UI gets some more love, I see ebpfsnitch take off like a rocket :)

> Reminds me of good old Kerio Personal Firewall on Windows back in the 90s.

That was my first thought as well. Back then Kerio Personal Firewall was a godsend, and seeing live how much software (which on windows was 99.9% closed) was attempting to phone home behind the user, became an eye opener to many of us.

Post reply on HN