On Mon, Oct 04, 2004 at 06:09:56PM +0200, Ed White wrote: > Who's right ?
There's no contradiction that I can see, just inprecision :) You have to distinguish bpf listeners and raw socket readers vs. raw socket writers on input vs. output paths. On the input path you have wire --> nic --> bpf / raw sock reader --> pf --> stack so bpf listener and raw sock readers get packets before they are filtered by pf. If you run a vulnerable bpf listener on the firewall, pf doesn't protect it. Move it to a separate host behind the firewall. On the output path you have stack --> raw sock writer --> pf --> bpf --> nic --> wire So a raw socket writer can't bypass pf. That's why you get nice errors when you try to run nmap with creative options on the firewall through pf's scrub. If anything, you could argue that this is asymmetric ;) On both paths, bpf is outmost near the nic. That's crucial if you use bpf for debugging, like with tcpdump. Ideally, you'd want tcpdump to show what's on the wire (just look at how much confusion is caused by the small violation of that princible by hardware checksumming). You're arguing that we should punish those people that want to use tcpdump for debugging firewalls to make life more convenient for people who carelessly run services on firewalls that they really should move to separate boxes? I think I'm with those people that rather want to run tcpdump on the firewall itself (instead of inserting a sniffer on the wire each time they want to debug) than those that want to run bpf daemons on the firewall itself. Daniel
