-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Unfortunately I _am_ (see the rc.conf snippet in the original post).
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.

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.

On Sun, 6 Jan 2002, Christos Zoulas wrote:

>In article <Pine.NEB.4.43.0201051004140.20501-100000@ithilien.draga.com>,
>Jim Wise <jwise@draga.com> wrote:
>
>Don't run dhcpd or rarpd on the external interfaces; use a list of interfaces
>for them to listen.
>
>christos
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>OK, so I'm setting up a replacement border NAT router for the network
>>here.  This machine has a few real outside addresses, and NATs for two
>>internal LANs.  It provides DHCP service on the two internal LANs.
>>
>>As one would expect, I have used ipf(8) to block access to all ports
>>which are inadvertently opened on the outside interface due to daemons
>>listening on INADDR_ANY (see previous post on this subject).  On the tcp
>>side, with the help of ipf's `block ... return-rst' capability, this is
>>completely transparent to a scanning host.  On the udp side, with the
>>help of ipf's `block ... return-icmp-as-dest(port-unr)' this is likewise
>>completely transparent -- with one exception.
>>
>>port 68.  dhcpd(8).
>>
>>The problem is, unlike the other udp ports which dhcpd(8) uses (67,
>>111), dhcpd does _not_ listen on port 68.  It appears that it is using
>>bpf to snatch packets directly from the wire.  As bpf does (and should)
>>get a shot at packets before ipf does its magic, this port is de facto
>>open regardless of ipfilter rules stating otherwise (test this.  no
>>really.  run dhcpd on a host, block all udp packets to port 68, and nmap
>>- -sU scan the host.  you may be surprised).
>>
>>And yes, this occurs even though dhcpd(8) is explicitly _not_ started on
>>the outside interface.
>>
>>To review:
>>
>>Inside interfaces are ray0 and le0 (yes, dhcp is limited to a specific
>>set of hardware addresses on ray0.  that's another discussion).  Outside
>>interface is vr0.
>>
>>from rc.conf:
>>...
>>ipfilter=YES                                    # uses /etc/ipf.conf
>>ipnat=YES                                       # uses /etc/ipnat.conf
>>...
>>dhcpd=YES               dhcpd_flags="-q le0 ray0"
>>...
>>
>>from ipf.conf:
>>...
>>block return-icmp-as-dest(port-unr) in log quick on vr0 from any to any
>>port = 68
>>...
>>
>>from nmap from an outside host:
>>...
>>68/udp     open        bootpc
>>...
>>
>>- --
>>				Jim Wise
>>				jwise@draga.com
>>-----BEGIN PGP SIGNATURE-----
>>Version: GnuPG v1.0.6 (NetBSD)
>>Comment: For info see http://www.gnupg.org
>>
>>iD8DBQE8NxkFN71lEcOYcw4RAl9lAKC8kprXBU0UMep5IV0DG9+/fmWUMgCfa9+M
>>/tuYTiQd74zbYXA4NO7F9hU=
>>=nYcB
>>-----END PGP SIGNATURE-----
>>
>
>

- -- 
				Jim Wise
				jwise@draga.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (NetBSD)
Comment: For info see http://www.gnupg.org

iD8DBQE8N6jkN71lEcOYcw4RAsQKAJ41zdhOt5UjyUlKTT3SwenRmzmMxgCgu5Qo
VZW3EPc+xJLhSFtnXxUm0e0=
=c3VR
-----END PGP SIGNATURE-----