Servidor DHCP – Windows Server 2008 y Linux Ubuntu

El DHCP es una extensión del protocolo Bootstrap (BOOTP) desarrollado en 1985 para conectar dispositivos como terminales y estaciones de trabajo sin disco duro con un Bootserver, del cual reciben su sistema operativo. El DHCP se desarrolló como solución para redes de gran envergadura y ordenadores portátiles y por ello complementa a BOOTP, entre otras cosas, por su capacidad para asignar automáticamente direcciones de red reutilizables y por la existencia de posibilidades de configuración adicionales.

Tras unas primeras definiciones del protocolo en 1993 en los RFC 1531 y 1541, su especificación definitiva llegó en 1997 con el RFC 2131. La IANA (Internet Assigned Numbers Authority) provee al protocolo de los puertos UDP67 y 68 (para IPv6, los puertos 546 y 547), también reservados para el protocolo Bootstrap.

La asignación de direcciones con DHCP se basa en un modelo cliente-servidor: el terminal que quiere conectarse solicita la configuración IP a un servidor DHCP que, por su parte, recurre a una base de datos que contiene los parámetros de red asignables. Este servidor, componente de cualquier router ADSL moderno, puede asignar los siguientes parámetros al cliente con ayuda de la información de su base de datos:

• Dirección IP única
• Máscara de subred
• Puerta de enlace estándar
• Servidores DNS
• Configuración proxy por WPAD (Web Proxy Auto-Discovery Protocol)

La asignación automática de direcciones mediante el protocolo de configuración dinámica de host tiene lugar en cuatro pasos consecutivos:

1. 1. El cliente DHCP envía un paquete DHCPDISCOVER a la dirección 255.255.255.255 desde la dirección 0.0.0.0. Con esta denominada difusión amplia o broadcast, el cliente establece contacto con todos los integrantes de la red con el propósito de localizar servidores DHCP disponibles e informar sobre su petición. Si solo hay un servidor, entonces la configuración es extremadamente sencilla.

1. 1. Todos los servidores DHCP que escuchan peticiones en el puerto 67 responden a la solicitud del cliente con un paquete DHCPOFFER, que contiene una dirección IP libre, la dirección MAC del cliente y la máscara de subred, así como la dirección IP y el ID del servidor.

1. 1. El cliente DHCP escoge un paquete y contacta con el servidor correspondiente con DHCPREQUEST. El resto de servidores también reciben este mensaje de forma que quedan informados de la elección. Con esta notificación, el cliente también solicita al servidor una confirmación de los datos que le ha ofrecido. Esta respuesta también sirve para confirmar parámetros asignados con anterioridad.

1. Para finalizar, el servidor confirma los parámetros TCP/IP y los envía de nuevo al cliente, esta vez con el paquete DHCPACK (DHCP acknowledged o «reconocido»). Este paquete contiene otros datos (sobre servidores DNS, SMTP o POP3). El cliente DHCP guarda localmente los datos que ha recibido y se conecta con la red. Si el servidor no contara con ninguna dirección más que ofrecer o durante el proceso la IP fuera asignada a otro cliente, entonces respondería con DHCPNAK (DHCP not acknowledged o «no reconocido»).

La dirección asignada se guarda en la base de datos del servidor junto con la dirección MAC del cliente, con lo cual la configuración se hace permanente, es decir, el dispositivo se conecta a la red siempre con esa dirección que le ha sido asignada automáticamente y que ya no está disponible para ningún otro cliente, lo que significa que los clientes DHCP nuevos no pueden recibir ninguna dirección si ya están todas asignadas, incluso aunque algunas IP ya no se usen activamente. Esto ha llevado a la expansión de las direcciones dinámicas y, en casos especiales, a la asignación manual vía servidor DHCP, que explicamos en los párrafos que siguen.

El problema del agotamiento del rango de direcciones es más bien improbable en el caso de la asignación dinámica. En principio, este procedimiento es ampliamente equiparable con la asignación automática, aunque con una pequeña pero decisiva diferencia: los parámetros de configuración que envía el servidor DHCP no son válidos para un periodo indeterminado de tiempo, sino por un tiempo de “préstamo” definido por el administrador que se conoce como concesión o alquiler de direcciones (lease time). Este indica cuánto tiempo puede acceder un dispositivo a la red con esa dirección. Antes de que se agote (transcurrida la mitad del tiempo), los clientes han de solicitar una prolongación de la concesión enviando una nueva DHCPREQUEST. Si no lo hace, no tiene lugar el DHCP refresh y, en consecuencia, el servidor la libera.

Si en las variantes automática y dinámica los administradores no tienen mucho que hacer, la situación es algo diferente en el caso de la asignación manual, que también se conoce como DHCP estático y en el cual las direcciones IP se asignan “a mano” con ayuda de las direcciones MAC definidas por el servidor DHCP sin limitación temporal.

Debido a sus elevados costes de gestión, que contradice la misma razón de ser del Dynamic Host Configuration Protocol, este tipo de asignación solo se reserva para unos pocos escenarios. Las direcciones IP estáticas son necesarias, por ejemplo, cuando en un ordenador se alojan servicios de servidor que han de estar permanentemente disponibles para los otros integrantes de la red, o en las redirecciones de puerto, en las que la dirección IP no puede variar.

La dirección IP asignada a un cliente tiene que poderse asociar con su nombre de dominio. Es aquí donde entra en juego un servidor DNS, que se ocupa de la resolución de nombres.

Cuando una dirección registrada o el nombre de host se modifican, es necesario actualizar el servidor de nombres de dominio. Para un administrador, así como para el usuario que se conecta a Internet desde su casa, la actualización manual del DNS en el caso de las direcciones IP variables asignadas dinámicamente por un servidor DHCP conllevaría mucho trabajo. El que no tengan que hacerlo es posible gracias al servidor DHCP, que se encarga de hacer llegar la nueva información al DNS tan pronto como se asigna una nueva dirección IP.

El Dynamic Host Configuration Protocol tiene un punto débil y es su capacidad para ser manipulado fácilmente. Como el cliente hace un llamamiento a discreción a todos los servidores DHCP que podrían responder a su petición, a un atacante le sería relativamente sencillo entrar en la red y hacerse pasar por uno de ellos si tuviera acceso a ella. Este denominado servidor DHCP “Rogue” (corrupto) intenta adelantarse con su respuesta al servidor legítimo y si tiene éxito envía parámetros manipulados o inservibles. Si no envía puerta de enlace, asigna una subred a cada cliente o responde a todas las peticiones con la misma dirección IP, este atacante podría iniciar en la red un ataque de denegación de servicio o Denial of Service.

Más dramático, pero factible, sería el intento de colarse en un router utilizando datos falsos sobre la puerta de enlace y el DNS, de modo que se estaría en posición de copiar o desviar el tráfico de datos. Este ataque man in the middle no tiene el propósito, como el primero, de ocasionar una caída de la red, sino de apropiarse de información sensible como datos bancarios, contraseñas o direcciones postales.

Sea cual sea el tipo de ataque, sus artífices necesitan tener acceso directo a la red para abusar del protocolo DHCP, así que no dejes de implementar las medidas de seguridad necesarias que te permitan disfrutar las ventajas de este protocolo de comunicación sin temor a sufrir las consecuencias de una amenaza de este tipo. Para el responsable de una red local es fundamental la protección absoluta ante intentos externos e internos de ataque y la supervisión constante de todos los procesos de red con herramientas como Nagios. En nuestra guía sobre la seguridad WLAN también repasamos las opciones de que dispones para proteger redes inalámbricas.