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

Re: blocking DHCP requests

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.