BPF-Based Linux Firewall "bpfilter" Shows Impressive Performance Potential

[uid313]

For somebody used to simplewall and GlassWire on Windows and AFWall+ on Android, seeing the available firewalls for Linux surely gets a big disappointment and frustration.

Great that at least somebody tries to fix this with OpenSnitch.
Too bad that the Linux foundation or EFF doesn't want to help out this user friendly firewall project.

I remember back in the days of Linux 2.2 and 2.4 where Linux had iptables which was amazing compared to what was available on Windows 95 and 98. I used to be very impressed with the firewall on Linux.
Canonical created ufw which is a nicer way to interact with iptables, its too bad they don't seem to be maintain ufw anymore.

Then with Windows 7 I think (or maybe it was available in Windows Vista or even earlier?) they had this application firewall that lets you allow/deny access to applications, and that was really amazing, it is another paradigm of firewall, but its very good for the desktop. So yeah it is disappointing that Linux does not have an application firewall.

Now with Flatpak and Snap we're getting some sandboxes with permissions (like Android), which is good, but still most software runs unconfined and are neither Flatpaks or Snaps.

I really wish that the GNOME Project (or even the KDE Project) would make an application firewall, similar to that one in Windows.

[intelfx]

I remember back in the days of Linux 2.2 and 2.4 where Linux had iptables which was amazing compared to what was available on Windows 95 and 98. I used to be very impressed with the firewall on Linux.
Canonical created ufw which is a nicer way to interact with iptables, its too bad they don't seem to be maintain ufw anymore.

Then with Windows 7 I think (or maybe it was available in Windows Vista or even earlier?) they had this application firewall that lets you allow/deny access to applications, and that was really amazing, it is another paradigm of firewall, but its very good for the desktop. So yeah it is disappointing that Linux does not have an application firewall.

Now with Flatpak and Snap we're getting some sandboxes with permissions (like Android), which is good, but still most software runs unconfined and are neither Flatpaks or Snaps.

I really wish that the GNOME Project (or even the KDE Project) would make an application firewall, similar to that one in Windows.

This is a hard problem, needs actual work and innovation (as opposed to writing an umpteenth music app or reshuffling buttons on the toolbars), and nobody pays for it. So, ain't gonna happen.

[Developer12]

No? AFAIR it was invented for more efficient packet sniffing. Not dropping packets from the system, but before copying them to a raw packet buffer in userspace. The packets would still go through the usual channels, just not to that particular socket.

If I recall correctly the original point was to make iptables faster. The kernel gained the ability to compile iptable rules into BPF programs that would then run in-kernel much faster. And then all that other stuff came later.

[Sonadow]

iptables and firewalld are already confusing enough.

[sinepgib]

If I recall correctly the original point was to make iptables faster. The kernel gained the ability to compile iptable rules into BPF programs that would then run in-kernel much faster. And then all that other stuff came later.

It wasn't invented for Linux, so that's unlikely. Plus, Wikipedia backs me up: https://en.wikipedia.org/wiki/Berkeley_Packet_Filter
Done for FreeBSD (that's why it's called Berkeley Packet Filter) and for packet capture.

Regarding compiling to BPF, IIUC bpfilter is all about compiling with the same iptables syntax. You can perfectly make a firewall with current BPF AFAICT, just it wouldn't really be practical.

EDIT: sorry, the part about FreeBSD was me failing to read properly. Still, the foundational paper both proves it's not originally from Linux and it's meant for more efficient packet capture, and all other stuff came later: https://www.tcpdump.org/papers/bpf-usenix93.pdf

[piotr.dobrogost]

Nft performs worse than Iptables?? WTF???

I asked Dmitrii Banshchikov about this and here is his reply:

Basically the reason is that nft's virtual machine requires more
indirect calls than iptables. This gives flexibility but this
flexibility comes by the cost of indirect calls. Post spectrum
epoch needs retpolines for indirect calls and retpolines
introduce even more performance penalties. This means that the
cost of indirect calls is even larger then before.

For a basic rule that matches only by source or/and destination
L3 address iptables doesn't need any indirect calls while nft
does. This means that even for basic matches nft requires
indirect calls. There was a discussion in bpf-next@ mailing list
where Alexei Starovoitov mentioned that for a basic rule nft
needs something like 10 indirect calls. This dramatically kills
performance.

BPF programs generated by bpfilter don't have any indirect calls
except map access and hence the performance is more optimal. And
I'm not even mentioning optimisations that are possible with
bpfilter and aren't possible with iptables of nft due to a more
precise context.

Hopefully this clarifies things a bit.

[q2dg]

I asked Dmitrii Banshchikov about this and here is his reply:

Thanks a lot!

[piotr.dobrogost]

Yeah, what happened here.
I guess I will stick to iptables now that the is realy no point on learning something thatis slowr...

See answer by Dmitrii Banshchikov here

https://www.phoronix.com/forums/forum/software/general-linux-open-source/1280890-bpf-based-linux-firewall-bpfilter-shows-impressive-performance-potential?p=1283544#post1283544

[piotr.dobrogost]

I wouldn't use the slower one cause my rules are most likely to be simple (I wouldn't know yet, I haven't configured one by hand), but wasn't the point of nftables to win on flexibility rather than performance?

Answer given by Dmitrii Banshchikov at https://www.phoronix.com/forums/foru...44#post1283544 seems to agree with you.