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 easily be used to modify another process to perform exfiltration or just spawn another thread and inject a whole new dynamic library to them, a common practice to bypass detection on Windows.
Unfortunately, even the website https://ebpf.io/what-is-ebpf doesn't mention this. Interestingly, I was unable to find the words packet filter used together as well or firewall. I might be wrong.
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.
The ebpf site doesn’t mention that because expanding the abbreviation is not helpful for understanding ebpf. The name is representative the past of ebpf, not its present use or future.
I really like eBPF, and I even know what the acronym stands for, but I'm still completely incapable of reading it as anything other than "e band pass filter"
Why does this need nf_queue? Wouldn't it be sufficient to directly filter the connect syscalls using eBPF?
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.
This uses NFQUEUE to get real-time userspace access to the ability to decide which connections to allow. NFQUEUE users must return a verdict on the packet (skb? I don't recall) before the packet continues to flow through the system. Using seccomp you don't get the opportunity to pass that up to a user to decide which action to take. Using other eBPF consumers are similar (since it represents a risk).
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.
There's much more that can be done as well, I really highly recommend taking a look at eBPF!
On Windows, Malwarebytes (now BiniSoft) still maintains a decent free product called Windows Firewall Control that works in a similar way. It augments the existing firewall.
> 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.
This is very cool. Something like this can be a full blown commercial product.
>The control interface is implemented in Python 3 utilizing Qt5
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).
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.
When you say vulnerabilities what do you mean? RCE? Privesc? Software can bypass the firewall?
Also, based on your recent HN comments you seem to have claimed to find vulns in several projects, but to date have provided no proof of such claims, so I'll have to admit I'm a little skeptical.
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.
[+] [-] aptmiguk|5 years ago|reply
It has a GUI interface as well.
[+] [-] dsissitka|5 years ago|reply
> Why OpenSnitch does not intercept application XXX
>
> tl;dr
>
> - because we don't use eBPF.
> - a process is opening connections too fast (nmap for example, firefox sometimes...).
> - the system has a high load and we're unable to find the process in time.
> ...
[+] [-] creamytaco|5 years ago|reply
evilsocket/opensnitch is worse but EBPFSnitch could also be a lot better.
[+] [-] XorNot|5 years ago|reply
[+] [-] arsome|5 years ago|reply
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 easily be used to modify another process to perform exfiltration or just spawn another thread and inject a whole new dynamic library to them, a common practice to bypass detection on Windows.
[+] [-] yjftsjthsd-h|5 years ago|reply
What overhead? `docker run --rm -it -v $PWD/untrustedprogram:/untrustedprogram:ro ubuntu:latest`, done. Use x11docker if needed.
[+] [-] t0astbread|5 years ago|reply
[+] [-] 29athrowaway|5 years ago|reply
With it you can write a security profile containing a rule like:
Networking access is just the start, you can restrict many other stuff, like access to dbus, files, signals, etc.[+] [-] grantseltzer|5 years ago|reply
[+] [-] the8472|5 years ago|reply
[+] [-] pratio|5 years ago|reply
ebpf: extended berkeley packet filter
Unfortunately, even the website https://ebpf.io/what-is-ebpf doesn't mention this. Interestingly, I was unable to find the words packet filter used together as well or firewall. I might be wrong.
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.
[+] [-] dsp|5 years ago|reply
[+] [-] ohazi|5 years ago|reply
[+] [-] Tcc1|5 years ago|reply
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.
[+] [-] rkeene2|5 years ago|reply
[+] [-] egberts|5 years ago|reply
— The said feature is critical to proper DEFAULT-DENY firewall configuration/modeling.
[+] [-] harporoeder|5 years ago|reply
[+] [-] spyc|5 years ago|reply
[+] [-] djeiasbsbo|5 years ago|reply
There's much more that can be done as well, I really highly recommend taking a look at eBPF!
[+] [-] jackinloadup|5 years ago|reply
[+] [-] spyc|5 years ago|reply
[+] [-] EMM_386|5 years ago|reply
https://www.binisoft.org/wfc
[+] [-] squarefoot|5 years ago|reply
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.
[+] [-] sandGorgon|5 years ago|reply
>The control interface is implemented in Python 3 utilizing Qt5
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).
U can see how that could run on a raspberry Pi and be accessible on the network through the browser.
[+] [-] dhaavi|5 years ago|reply
[+] [-] calvinmorrison|5 years ago|reply
[+] [-] throwitaway12|5 years ago|reply
[+] [-] netsec_burn|5 years ago|reply
[+] [-] cmeacham98|5 years ago|reply
Also, based on your recent HN comments you seem to have claimed to find vulns in several projects, but to date have provided no proof of such claims, so I'll have to admit I'm a little skeptical.
[+] [-] 0xbadcafebee|5 years ago|reply
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.
[+] [-] eeZah7Ux|5 years ago|reply
We need holistic solutions where we can control traffic by entity, domain, role, application, not IP address and port.
> There will come a point where the attacker will position themselves to appear exactly like legitimate traffic.
It's been happening for decades: botnet C&C servers use HTTPS and run on public clouds, mimicking legitimate websites.
[+] [-] ghostpepper|5 years ago|reply