Live data from Hacker News

EBPFSnitch: An eBPF based Linux Application Firewall

github.com

11–20 of 71 posts

Re: EBPFSnitch: An eBPF based Linux Application Firewall

#11
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. There will come a point where the attacker will position themselves to appear exactly like legitimate traffic.

Ultimately, all firewalls are just a very poor hack around a complex problem. The best solution to the problem is to ensure the connection is genuine and that the data being passed is genuine, and you can't do that with an arbitrary monitoring program. You need strong end to end authentication, authorization, and integrity, and sometimes also privacy. But we don't have the tools to do that right now because the protocols were designed for a different time.

Take DLP for example. Almost every major company in the world is starting to implement traffic inspection, because how the hell else are you going to ensure security of your IP with 10,000 employees using TLS 1.3? The inspection you force on the users is its own security hole, to say nothing of software bugs. And you can't even just lock down the network to only protocols that use OAuth or something. None of our security solutions are holistic.

We need a revolution in network security that takes each part of a network communication and its individual security needs into account, not just what we imagine is end-to-end (but never actually is). We can't rely solely on a facile "privacy or nothing" approach to internet security that the TLS mafia has been pushing. We need more flexible methods that allow us to fine-tune security at each level of the protocol stack, across multiple organizations and use cases. Nothing like that exists currently for the web.

Re: EBPFSnitch: An eBPF based Linux Application Firewall

#13
post #3
post #2

This looks spectacular! Finally! This is functionality I've desperately wanted on Linux desktop. Link that up with with some of the SELinux on-demand tools and you have a plausible way to run untrusted binaries without the overhead of completely containerizing them up front.

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.

Re: EBPFSnitch: An eBPF based Linux Application Firewall

#14
post #6
post #2

This looks spectacular! Finally! This is functionality I've desperately wanted on Linux desktop. Link that up with with some of the SELinux on-demand tools and you have a plausible way to run untrusted binaries without the overhead of completely containerizing them up front.

firejail?

I don't see any port-based firewalling options in the firejail documentation from a quick look. So I'm not sure if firejail helps the same use case as EBPFSnitch.

Re: EBPFSnitch: An eBPF based Linux Application Firewall

#15
post #8

only problem is that you can’t get the process ID for inbound packets like FreeBSD can, for that still remains Linux’s weakest feature. — The said feature is critical to proper DEFAULT-DENY firewall configuration/modeling.

Could you elaborate why that's critical to have?

Re: EBPFSnitch: An eBPF based Linux Application Firewall

#17
post #2

This looks spectacular! Finally! This is functionality I've desperately wanted on Linux desktop. Link that up with with some of the SELinux on-demand tools and you have a plausible way to run untrusted binaries without the overhead of completely containerizing them up front.

I think AppArmor would be a better use-case for that.

With it you can write a security profile containing a rule like:

   network tcp src 192.168.1.1:80 dst 170.1.1.0:80
Networking access is just the start, you can restrict many other stuff, like access to dbus, files, signals, etc.

Re: EBPFSnitch: An eBPF based Linux Application Firewall

#18
post #14
post #6

Earlier quoted context omitted.

firejail?

I don't see any port-based firewalling options in the firejail documentation from a quick look. So I'm not sure if firejail helps the same use case as EBPFSnitch.

It can isolate applications into separate network namespace (i.e. no access to host services) with or without internet access and also load separate netfilter rules. No convenience arguments for port filtering though.

Re: EBPFSnitch: An eBPF based Linux Application Firewall

#19
post #2

This looks spectacular! Finally! This is functionality I've desperately wanted on Linux desktop. Link that up with with some of the SELinux on-demand tools and you have a plausible way to run untrusted binaries without the overhead of completely containerizing them up front.

without the overhead of completely containerizing them up front. What overhead? `docker run --rm -it -v $PWD/untrustedprogram:/untrustedprogram:ro ubuntu:latest`, done. Use x11docker if needed.

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.

Re: EBPFSnitch: An eBPF based Linux Application Firewall

#20

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.

Post reply on HN