Ahh, I see what you guys are talking about now. I should really read the whole thread before replying. Very interesting stuff.
A --- Daniel Hartmeier <[EMAIL PROTECTED]> wrote: > 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 > Find local movie times and trailers on Yahoo! Movies. http://au.movies.yahoo.com
