Hacker News new | past | comments | ask | show | jobs | submit login

And if you're using FreeBSD with a fast NIC, look into the pfilctl command and use a "head" input hook into your NIC driver's ethernet input handling routine. Doing this allows the firewall input checks to happen early, before the packet has been received into the network stack, while its still in DMA-mapped, driver-owned buffers. If the firewall decides a packet is to be dropped, the NIC can recycle the buffer with minimal overhead (skips DMA-unmap, buffer free, ethernet input into the IP stack, and the replacement buffer alloc, DMA map).

This allows for very fast dropping of DOS flood attacks. I've tested this using ipfw up to screening and dropping several 10s of millions of packets on 2014 era Xeons with minimal impact to traffic serving. I wrote a paper about this for a conf. that was cancelled due to COVID. I really need to re-submit it someplace.

This works for Mellanox, Chelsio, and NICs that use iflib (ix, ixl, igb, bnxt, and more that I'm forgetting).




> This allows for very fast dropping of DOS flood attacks.

OpenBSD has something very close to that w/ bpf(4) BIOCGFILDROP filter "drop".

https://man.openbsd.org/bpf#BIOCGFILDROP

https://man.openbsd.org/tcpdump#B

https://marc.info/?l=openbsd-tech&m=155228135415650&w=2


I think that's pretty different. It's less processing, but still copies packet off nic.


I'm picturing that scene a few episodes into the soul art anime - I barely remember it but the main character was so overpowered, he was standing there absorbing a full barrage from a much lower ranked opponent flooding him with punches and kicks; the main character's health regenerated so quickly that the attack didn't have effects.

In 2014 I was working on a hardware appliance for a company that has something to do with packet capture, and I found an intel driver that implemented a ring buffer on a 1 gigabit Ethernet adapter that allowed me to capture line rate without dropping a single packet over the course of hours; prior to this the adapter was barely able to capture 90% of the packets. I remember marveling at the design that must have gone into it, and here too to your description of this performance improvement.

I miss that stuff. Thanks for sharing,


This is awesome to see [as a mostly-Linux person] - people have managed to impress the sentiment on me that the BSDs are well-suited for networking.

I never quite 'got it' - this helps. Are you aware of similar tweaks in Linux land, by chance?

I consider myself reasonably well-experienced as a systems administrator... but can't quite recall stumbling across anything quite like this.


IMO Linux is significantly better than the *BSDs at this particular use case.

Check out https://blog.cloudflare.com/l4drop-xdp-ebpf-based-ddos-mitig...

and:

https://github.com/xdp-project/xdp-tools


But don’t have to cobble together a bunch of arcane iptables commands and then combine bpf and other userland tools … when one can just use the clean syntax of PF especially for home use that’s a clear win.


I've used both extensively and I find eBPF+iptables (and sometimes nft) significantly more flexible and easier to use in the real world (not just simple examples) than PF. shrug


Do you have a sample or blogpost of how your setup looks? I’m keen to see how folks are using eBPF in the personal firewall space


> But don’t have to cobble together a bunch of arcane iptables commands

If you did manage to figure out the iptables commands you now have to change them over to nftables. :)


No, iptables is a perfectly functional nftables frontend


Not having to manage two rulesets -- one for IPv4 and one for IPv6 -- is pretty well a killer feature in my mind.


nftables is now almost 10 years old! It's time to forget the bad experiences with iptables.


I have -- I let the OpenBSD firewalls take care of it :P

Seriously though it's something I need to get familiar with, I do still have plenty of Linux boxes that face the public Internet and are currently dependent on iptables/ip6tables rulesets. The problem is I'm currently masking that pain with Ansible.


Linux certainly offers much better functionality overall but the tooling for this is a poorly documented and inconsistent nightmare.


There is definite lack of a declarative tool that glues it all.

Typical hardware switches and routers just have one (sometimes expanded by includes/macros but still) config syntax to control every part of networking stack.

So you can configure interface and set its vlans all in one place instead of creating a dozen of ethX.Y devices then crerating a bunch of brY bridges and then attaching the interfaces to them

In linux instead you'd be using iproute2 set of tools to configure interfaces and static routing, iptables for IP ACLs, ebtables for ethernet ACLs (or now nftables I guess), without any tool to apply/revert changes at once

Many tried doing that but IMO haven't seen anything good.

Many also try to "simplify" iptables and all it ends up is me being annoyed coz I know which iptables commands I need to run but I need to translate it back into "higher" level config syntax. One exception being ferm ( http://ferm.foo-projects.org/ ), because it keeps iptables-like keywords just expands on that, but it is iptables only and kinda superseded by nftables syntax anyway.


iptables/ebtables is deprecated even in RHEL. While people are free to continue not to transition to nftables complaining about problems with iptables after a decade of its replacement is a bit silly.


I would trade firewalld for pf in an instant.



Thank you, I've heard of {e,}BPF but not so much applications - thank you again!

Makes sense why I haven't seen it, came out around the time I joined $CurrentEmployer, and we're stuck a couple decades behind.


Would love to watch that talk (so please re-submit it somewhere!), but in lieu of that, is the paper available anywhere?


This sounds nice for a specific case when you are not dealing with bandwidth based DOS.


I had no idea! This is really cool. Have you by chance a blog about it?




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: