Berkeley Packet Filter is een manier om pakketten uit de datastroom te vissen voor inspectie. Dus bijvoorbeeld een tcpdump query wordt vertaald naar een BPF en dat gebruikt de kernel dan om het werkelijke filteren te doen. Maar ook bijvoorbeeld dhcp maakt gebruik van BPF om alleen de dhcp-gerelateerde pakketten afgeleverd te krijgen, en niet alle broadcast.

Het is dus niet hetzelfde soort als packet filter als iptables, PF, IPFW, en zo verder.

Ik denk dat "grote bedrijven die Linux draaien maken gebruik van BPF" een beetje een rare statement is. BPF is een subsystem wat je toelaat om wat code uit te voeren op verschillende punten in de kernel om netwerk pakketjes te filteren, aan te passen, toe te voegen, en/of te matchen. tcpdump, ngrep, en anderen gebruiken dat al behoorlijk lang.

BPF kan inderdaad ook voor firewalling gebruikt worden net zoals het hele oude ipchains (nu iptables, daarna nftables) wat ook systemen zijn waarmee je kan firewallen.

Een voordeel van BPF is dat het theoretisch sneller is. Je BPF rules worden naar machine code specifiek voor die rules gecompileerd met een mogelijke JIT (deze staat standaard uit). Dit laat het toe om BPF regels in meerdere talen te schrijven en zorgt ervoor dat je BPF firewall meteen code voor de pakketjes heeft in plaats van dat het eerst door een ander programma moet welke de regels matcht. Theoretisch sneller en theoretisch kunnen we die code vervolgens naar de netwerk kaart verplaatsen wat weer resources scheelt op de CPU.

Voor het gebruik ervan? BPF is 'slecht' gedocumenteerd zoals je zelf al zegt. Je moet wat beter weten waarmee je bezig bent omdat het gebruik van BPF in de community pas sinds kort op gang aan het komen is. Dat komt dan weer voornamelijk doordat iptables/nftables relatief slecht zijn als je rules erg veranderlijk zijn. Ook is NAT/redirecten met iptables/nftables relatief langzaam waar een userspace programma in BPF zelf zijn packet rules kan opgeven voor pakketjes wat het wil ontvangen.

Die combinatie van features en de opkomst van containers (welke vaak veel veranderende virtuele netwerken hebben) zorgen ervoor dat BPF een beetje populariteit aan het winnen is.

Ik denk niet dat als je niet specifiek tegen de limitaties van iptables/nftables aan loopt op dit vlak dat nu het moment is om alles om te schrijven naar BPF. Liever wachten totdat er wat meer tooling en documentatie beschikbaar is!

BPF heeft geavanceerdere mogelijkheden en is met de doel gebouwd om simpeler en sneller te wezen dan iptables/nftables. BPF is volgens mij ook niet opensource.

Het is een ala Unix security dat naar Linux gebracht wordt wat potentieel kan leiden tot een betere en simpelere defence.

Als je https://lwn.net/Articles/747551/ leest is de conclusie 'gooi je iptables/nftables nog maar even niet weg' .

De basis is een kernel module waarmee je kleine programma's (geschreven voor een virtual machine) op bepaalde punten in de kernel processing kunt toevoegen.
https://lwn.net/Articles/740157/

Het maakt het ook (veel)makkelijker/sneller om een packet verder door userland code te laten bewerken.

Met dit soort mogelijkheden kun je natuurlijk óók een firewall bouwen - maar zo te lezen zijn de modules en utilities om 'gewoon' filter regels nog erg in ontwikkeling .

De cloudflare blog geeft een aantal toepassingen waar zij het voor gebruiken.
Als je hun soort uitdagingen hebt is het een uistekende (en noodzakelijke) tool.

https://blog.cloudflare.com/introducing-ebpf_exporter/
https://blog.cloudflare.com/how-to-drop-10-million-packets/

Als je poortje 22 van je DMZ thuis server dicht wilt zetten voegt het niets toe.

Je kan gewoon IPtables en BPF gewoon naast elkaar draaien zorg alleen ervoor dat je geen dubbele instellingen invoert om resources niet te wasten.