El DHCPD es algo que deberían utilizar todos los administradores de redes. Permite servir información a clientes en cuanto a configuraciones de red/etc, lo cual significa que la única configuración que se necesita implantar en el cliente es aquella por defecto, y encender la máquina. También permite reconfigurar máquinas cliente con facilidad (es decir, pasar de utilizar 10.0.1.0 a 10.0.2.0, o un conjunto nuevo de servidores DNS). A la larga (e incluso a la corta) DHCP ahorra un montón de trabajo, dinero y stress. Yo lo ejecuto en casa con sólo 8 máquinas clientes y he descubierto que la vida es mucho más fácil. DHCPD lo mantiene el ISC, y se encuentra en: http://www.isc.org/dhcp.html
También recomendaría ejecutar la versión 2.x (la versión 3.x está en pruebas), tiene muchas características nuevas, es más fácil de configurar y de trabajar con ella. Sin embargo, la ultimísima versión tiende a ser algo más neurótica, ten en cuenta que es software en fase beta. Definitivamente hay que filtrar el DHCPD de Internet. El tráfico DHCP sólo debería existir en segmentos locales, posiblemente reenviado a un servidor DHCP en otro segmento, pero el único tráfico DHCP que se vería proveniente de Internet sería un ataque/DOS (podrían reservar todas tus IP’s, dejando secos a los auténticos clientes). Si estás reenviando el tráfico DHCP a Internet, NO lo hagas. Es una idea muy mala por multitud de motivos ( primero por rendimiento / consistencia, pero también por seguridad).
Recomiendo que el servidor DHCPD sea exclusivamente servidor de DHCP, bloqueado en alguna parte (si confías en DHCP para tu red y el servidor DHCP se cae, la red tiene un serio problema), permitiéndole hacer su trabajo en silencio. Si se necesita abarcar subredes (p. ej., se tienen múltiples segmentos ethernet, sólo uno de los cuales tiene un servidor DHCP físicamente conectado) utiliza un transmisor DHCP (NT viene con uno, el software DHCP de Linux tiene esta característica, etc.). También existen problemas conocidos con NT y DHCP, NT RAS tiene la mala costumbre de consumir direcciones IP como un loco (he visto a un servidor NT coger 64 y quedárselas indefinidamente), debido a que está intentando reservar IP’s para los clientes a que vayan a hacer un dial in. Esto no tiene porqué ser problema, pero puede (y lo ha hecho) conducir al agotamiento de recursos (en concreto, la cola de direcciones IP se puede terminar). O bien se apaga el RAS del NT o se le coloca en su propia subred, la dirección MAC que envía al servidor DHCP es muy extraña (y deletrea RAS en los primeros bytes) y no es fácil de mapear.
Haciendo Chroot al DHCPD
El DHCPD consiste en 2 ejecutables principales:
- dhcpd – el DHCP
- dhcrelay – un transmisor DHCP (para transmitir peticiones a un servidor DHCP central, puesto que el DHCP está basado en broadcasts, las cuales por lo general no se extienden (o no deberían) a routers.
DHCPD requiere 2 librerías:
- /lib/ld-linux.so.2
- /lib/libc.so.6
Un fichero de configuración:
- /etc/dhcpd.conf – información de configuración, situación de los ficheros de arranque, etc.
Y varios otros ficheros:
- /etc/dhcpd.leases – una lista de las conexiones activas
- un fichero de inicio, se puede modificar el que viene o hacerte el tuyo propio
La forma más sencilla de configurar el dhcpd con chroot es sencillamente instalar el dhcpd (preferiblemente la última versión) y mover/editar los ficheros necesarios. Una buena idea es crear un directorio (como /chroot/dhcpd/), preferiblemente en un sistema de ficheros separado de /,/usr, etc (enlaces simbólicos…), y después crear una estructura de ficheros por debajo para dhcpd. Lo siguiente es un ejemplo, simplemente reemplaza /chroot/dhcpd/ por tu elección. Por supuesto que es necesario ejecutar estos pasos como root para que funcione.
# Se instala bind para tener los ficheros apropiados
#
rpm –i dhcpd-2.0b1p10-1.i386.rpm
#
# Se crea la estructura de directorios
#
cd /chroot/dhcpd/ # o dondequiera que esté
mkdir ./etc
mkdir ./usr/sbin
mkdir ./usr
mkdir ./var/dhcpd
mkdir ./var
mkdir ./lib
#
# Se empiezan a llenar los ficheros
#
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
#
# Para conseguir las últimas librerías, cambiar lo oportuno
#
cp /lib/ld-linux.ld-linux.so.2 ./lib/
cp /lib/libc.so.6 ./lib/
#
# Y se crean los enlaces simbólicos necesarios para que funcione
# Recuerda que el dhcpd piensa que /chroot/dhcpd/ es /, de modo
# que utiliza enlaces relativos
Después modifica o crea tu script de inicio.
Una vez que se ha hecho esto, simplemente hay que borrar el fichero de inicio original y crear un enlace simbólico desde donde apuntaba al nuevo, y el dhcpd se portará con "normalidad" (es decir, se iniciará automáticamente al arrancar), mientras que en realidad se encuentra separado de tu sistema. Quizás también quieras eliminar los ficheros DHCPD originales que anden por ahí, aunque no es necesario.
Si se ha hecho lo anterior correctamente, deberías tener un /chroot/dhcpd/ (u otro directorio si se especifica algo diferente) que contenga todo lo requerido para ejecutar dhcpd. Un ps –xau debería mostrar algo así:
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
Definitivamente DHCPD debería de filtrarse con el cortafuegos de hosts externos, pues no hay ninguna razón para que un host externo lance una petición a tu servidor DHCP en busca de IP’s, además, tenerlo disponible al mundo exterior podría dar como resultado que el atacante consumiera los recursos de direcciones del servidor DHCP, suponiendo que se utilicen colas dinámicas de direcciones, se le podría acabar la suerte a tu red interna, y aprender acerca de la estructura de tu red interna. El DHCP se ejecuta en el puerto 67, con udp, porque las cantidades de datos involucradas son pequeñas, y la rapidez en la respuesta es crítica.
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 un.host.fiable –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
o
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 un.host.fiable –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
