[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: blocking DHCP requests

Ahh, I see what you guys are talking about now. I should really read
the whole thread before replying. Very interesting stuff.
 --- 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.