> dhcpd uses INADDR_ANY (and uses bpf on all interfaces), and then
> doesn't respond on the interfaces it's not configured to serve.

> This means a.) that without ipf, dhcpd is seen by an outside port
> scanner as listening on all interfaces, specified or not, and b.)
> that even with ipf, dhcpd is seen by an outside portscanner on udp
> port 68.

There's something I don't get here.

You have ipf return a port unreachable.  dhcpd picks up the packet with
bpf, which sniffs a copy before ipf gets a chance to block it - but
dhcpd doesn't respond (because it's configured to ignore that
interface).  So the portscanner sends a packet and sees a nothing but
port unreachable come back.  How does this differ from any random port
that has nothing listening, or which is blocked?  Presumably my
description of what happens is inaccurate in some respect; where does
it go wrong?

> It also means that were there (and I don't know of any) a buffer
> overflow or other security problem in dhcpd's internal udp handling,
> ipf could _not_ be used to protect the machine from outside
> exploitation.

This is a more serious problem.  For such cases, there should be a way
to have ipf block before bpf, or alternatively a way to configure a
given bpf instance to sniff before or after ipf's filters get their
crack at the packet.  (My guess would be the former is easier to do.)

Alternatively, you can just look at it as one of the loses inherent in
trying to make one box do everything.

It's also a bug in dhcpd, I'd say, if it detectably alters the
machine's behavior on an interface it's supposedly configured to
ignore.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B