DHCPD is something all network admins should use. It allows you to serve information to clients regarding their network settings/etc, typically meaning that the only client setup needed for networking is leaving the defaults and turning the machine on. It also allows you to reconfigure client machines easily (say move from using 10.0.1.0 to 10.0.2.0, or a new set of DNS servers). In the long run (and short run even) DHCP will save you enormous amounts of work, money and stress. I run it at home with only 8 client machines and have found life to be much easier. DHCPD is maintained by the ISC and is at: http://www.isc.org/dhcp.html.
I also highly recommend you run DHCPD version 2.x (3.x is in testing), it's got a lot of new features, and is easier to setup and work with. The absolute latest version(s) of this tend to be a bit neurotic however, be warned it is beta software. Definitely firewall DHCPD off from the Internet. DHCP traffic should only be on local segments, possibly forwarded to a DHCP server on another segment, but the only DHCP traffic you would see coming over the Internet would be an attack/DOS (they might reserve all your IP's, thus leaving your real clients high and dry). If you are forwarding DHCP traffic over the Internet, DON'T. This is a really bad idea for a variety of reasons (primarily performance / reliability, but security as well).
I recommend the DHCPD server be only a DHCP server, locked up somewhere (if you rely on DHCP for your network and the DHCP server fails your network is in serious trouble), allowed to do it's job quietly. If you need to span subnets (i.e., you have multiple ethernet segments, only one of which has a DHCP server physically connected to it) use a DHCP relay (NT has one built in, the DHCP software for Linux has this capability, etc.). There are also several known problems with NT and DHCP, NT RAS has a rather nasty habit of sucking up IP addresses like crazy (I have seen an NT server grab 64 and keep them indefinitely), because it is trying to reserve IP's for the clients that will be dialing in/etc This may not seem like a real problem but it can (and has) lead to resource starvation (specifically the pool of IP addresses can be exhausted). Either turn NT's RAS off or put it on it's own subnet, the MAC address it sends to the DHCP server is very strange (and spells out RAS in the first few bytes) and is not easy to map out.
DHCPD consists of 2 main executables:
ž dhcpd - the DHCP
ž dhcrelay - a DHCP relay (to relay requests to a central DHCP server since DHCP is based on broadcasts, which typically don't (and shouldn't) span routers/etc.
DHCPD requires 2 libraries:
A config file:
ž /etc/dhcpd.conf - configuration info, location of boot files, etc.
And a few other misc. files:
ž /etc/dhcpd.leases - a list of active leases
ž a startup file, you can modify the one it comes with or roll your own
The simplest way to setup dhcpd chroot'ed is to simply install dhcpd (latest one preferably) and move/edit the necessary files. A good idea is to create a directory (such as /chroot/dhcpd/), preferably on a separate filesystem from /, /usr, etc (symlinks...), and then create a file structure under it for dhcpd. The following is an example, simply replace /chroot/dhcpd/ with your choice. You must of course execute these steps as root for it to work.
# Install bind so we have the appropriate files # rpm -i dhcpd-2.0b1pl0-1.i386.rpm # # Create the directory structure # cd /chroot/dhcpd/ # or wherever mkdir ./etc mkdir ./usr/sbin mkdir ./usr mkdir ./var/dhcpd mkdir ./var mkdir ./lib # # Start populating the files # cp /usr/sbin/dhcpd ./usr/sbin/dhcpd cp /etc/dhcpd.conf ./etc/dhcpd.conf cp /etc/rc.d/init.d/dhcpd ./etc/dhcpd.init cp /etc/rc.d/init.d/functions ./etc/functions # # Now to get the latest libraries, change as appropriate # cp /lib/ld-linux.ld-linux.so.2 ./lib/ cp /lib/libc.so.6 ./lib/ # # And create the necessary symbolic links so that they behave # Remember that dhcpd thinks /chroot/dhcpd/ is /, so use relative links
Then modify or create your startup script.
Once this is done simply remove the original startup file and create a symlink from where it was pointing to the new one, and dhcpd will behave 'normally' (that is it will be automatically started at boot time), while in fact it is separated from your system. You may also wish to remove the 'original' DHCPD files laying about, however this is not necessary.
If you have done the above properly you should have a /chroot/dhcpd/ (or other dir if you specified something different) that contains everything required to run dhcpd.
And a ps -xau should show something like:
USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND root 6872 0.0 1.7 900 532 p0 S 02:32 0:00 ./usr/sbin/dhcpd -d -q root 6873 0.0 0.9 736 288 p0 S 02:32 0:00 tee ./etc/dhcpd.log
DHCPD should definitely be firewalled from external hosts as there is no reason an external host should be querying your DHCP server for IP's/etc, in addition to this making it available to the outside world could result in an attacker starving the DHCP server of addresses assuming you use a dynamic pool(s) of addresses, you could be out of luck for your internal network, and learning about the structure of your internal network. DHCP runs on port 67, udp because the amounts of data involved are small and a fast response is critical.
ipfwadm -I -a accept -P udp -S 10.0.0.0/8 -D 0.0.0.0/0 67 ipfwadm -I -a accept -P udp -S some.trusted.host -D 0.0.0.0/0 67 ipfwadm -I -a deny -P udp -S 0.0.0.0/0 -D 0.0.0.0/0 67
ipchains -A input -p udp -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 67 ipchains -A input -p udp -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 67 ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 67
Written by Kurt Seifried