If you're interested in this, you may be interested in this as well: <a href="https://github.com/evilsocket/opensnitch" rel="nofollow">https://github.com/evilsocket/opensnitch</a><p>It has a GUI interface as well.
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.
For those who're unaware.<p>ebpf: extended berkeley packet filter<p>Unfortunately, even the website <a href="https://ebpf.io/what-is-ebpf" rel="nofollow">https://ebpf.io/what-is-ebpf</a> doesn't mention this. Interestingly, I was unable to find the words packet filter used together as well or firewall. I might be wrong.<p>I know that if you know what it is you'd know but trying to explain that to my partner here just glancing at my screen wasn't easy.
Why does this need nf_queue? Wouldn't it be sufficient to directly filter the connect syscalls using eBPF?<p>Dropping packets using netfilter makes many applications wait for a timeout. I prefer reject to filter unwanted outbound connections so that applications don't wait.
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.<p>— The said feature is critical to proper DEFAULT-DENY firewall configuration/modeling.
When I tested out eBPF a couple weeks ago I immediately had LittleSnitch in mind! Great to see that someone had the same idea and also the time to make it happen.<p>There's much more that can be done as well, I really highly recommend taking a look at eBPF!
This is awesome. I can't wait to dig into it. I was contemplating creating creating the same thing roughly. Maybe I can now leverage this instead :-)
This is very cool. Something like this can be a full blown commercial product.<p>><i>The control interface is implemented in Python 3 utilizing Qt5</i><p>I would recommend moving away from this and instead run the controls using a web interface. A small django/flask/fastapi app (maybe even running through docker).<p>U can see how that could run on a raspberry Pi and be accessible on the network through the browser.
Hey, security guy here that has worked on something like this for about 2 years. This is cool but has some vulnerabilities upon a brief 10min code review. I'll see if I can circle back in about 2 weeks and make a list of what vulnerabilities EBPFSnitch has.
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.<p>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.<p>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.<p>We need a revolution in network security that takes each <i>part</i> 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.