Al tiempo que se convertía en piedra angular de casi cualquier aplicación en red, el sistema de nombres de dominio (DNS) ha ido ganando complejidad, tanto en su parte teórica como en sus implementaciones. Por ello conviene revisar la arquitectura DNS y tomar precauciones para evitar ser objeto de las múltiples amenazas que acechan en la Red.
Vint Cerf, padre de Internet, vaticinaba recientemente tres predicciones para el futuro de la Web: el mejor uso de las transmisiones IP para, entre otros, enviar actualizaciones de software y sistemas operativos; la creciente demanda de seguridad en los sistemas operativos; y el fortalecimiento de DNS (Domain Name System). “Hoy en día no hay manera de asegurar si los datos proceden de un sitio real o de un flujo desviado”, asegura Cerf.
Y es que los errores a la hora de crear una arquitectura DNS son bastante frecuentes, a tenor de la amplia variedad de ataques sufridos últimamente en Internet. Un reciente estudio realizado por The Measurement Factory para Infoblox, firma de soluciones basadas en identidad, asegura que más de la mitad de los servidores de nombres de Internet están mal configurados, dejando las redes abiertas a ataques y causando graves daños tanto a empresas como a otros usuarios de Internet. El informe está basado en una muestra que incluye el 5% del espacio de direcciones IPv4: alrededor de 80 millones de dispositivos.
Falta de Seguridad
El fallo más común en estas arquitecturas se produce, según la consultora, cuando los servidores DNS reenvían peticiones procedentes de sistemas fuera de su propia red. Salvo un pequeño número de servidores de nombres autorizados en Internet, la mayoría son “recursivos”, entendiendo por ello que residen en una LAN o en la red de un ISP y remiten solicitudes de sus propios usuarios a los servidores autorizados. Cuando estos servidores se abren a otros usuarios de fuera de su red, favorecen los ataques de “pharming”, cuyo principal efecto es el redireccionamiento del usuario a una página Web falsa y en apariencia idéntica a la solicitada, a menudo con el fin de obtener datos privados del usuario.
Otra de las consecuencias de esta práctica es la saturación de las redes; los atacantes envían múltiples peticiones DNS fraudulentas, aparentemente de un único usuario, a muchos de estos servidores recursivos abiertos, que le devuelven una respuesta con mayor peso, sobrecargando la red y el equipo cliente. Así, cientos de PC envían una petición de 64 bytes y los servidores le responderán con 4 KB por cada petición, generando una gran cantidad de tráfico hacia el usuario.
El informe de The Measurament Factory también señala que había 9 millones de servidores DNS conectados a Internet en 2006, un 20% más que en el año anterior, y un total de 20 millones de servidores DNS en todo el mundo. De los equipos externos, el 29% admite transferencia de zonas para peticiones arbitrarias, permitiendo la duplicación de todo un segmento de los datos DNS de una organización de un servidor DNS a otro, abriéndolos así a ataques de denegación de servicio (DoS). La forma de resolver esta cuestión sería ejecutar una extensión segura de DNS, llamada DNSSEC, que aplica criptografía asimétrica para permitir a los administradores firmar zonas de forma digital. Sin embargo, esta práctica no termina de calar: sólo uno de cada 100.000 la ejecuta, según Infoblox.
No obstante, una muestra de que las empresas comienzan a tomar conciencia de la necesidad de aplicar medidas de seguridad es el mayor uso de BIND 9, la versión más reciente y segura del software de servidores de dominios basada en código abierto. En 2005, un 58% de los equipos DNS ya la utilizaba y en 2006 se detectó que esta versión se había instalado ya en el 61% de los servidores de nombres. Por contrapartida, ha disminuido la presencia de BIND 8 en un 30%, al pasar del 20% de los servidores DNS en 2005 al 14% en 2006. También se ha reducido a la mitad el número de estos servidores basados en Microsoft.
Buen uso del DNS
Los efectos que los ataques a los servidores de nombres de dominios causan en las organizaciones pueden ser brutales: todas las funciones relacionadas con Internet fallarán, incluidos correo electrónico, acceso Web, comercio electrónico y extranet.
Para Liu (vicepresidente de arquitectura de Infoblox y coautor de los libros “DNS and BIND”, “DNS and BIND Cookbook” y “DNS on Windows Server 2003”), la criticidad de los sistemas DNS ha aumentado en los últimos años al haberse vinculado estos sistemas a aplicaciones como autenticación del correo electrónico. “Además del uso del sistema para aplicaciones como Active Directory, estándares como XPF permiten almacenar información en el DNS para indicar a los servidores de correo qué direcciones IP tienen permiso para enviar email, o utilizar mecanismos como DKIM, una fusión de las tecnologías DomanKeys de Yahoo e Identified Internet Mail de Cisco, que autentica mensajes de email. Si alguien recibe un mensaje mío de firma DKIM, puede estar seguro de que yo soy el emisor”.
Dado que todas estas tecnologías descansan sobre técnicas del servidor de nombres de dominio, Liu sugiere que “todas las empresas deberían evaluar sus sistemas DNS y tomar las medidas para hacer esta arquitectura fiable y segura”. Para ello, y basándose en su dilatada experiencia en el mundo de los dominos –Liu gestionó durante cinco años hp.com, uno de los mayores dominios corporativos del mundo–, el vicepresidente de Infoblox propone una serie de mejores prácticas para evitar las vulnerabilidades del DNS, así como los problemas de configuración. Una de ellas es la desactivación de la recursión en los servidores de nombres autorizados externos para evitar ataques DoS y en los forwarders, así como la limitación de la recursión tanto como sea posible, si no se pueden separar los servidores de nombres autorizados y los forwarders.
También es aconsejable ocultar el servidor de nombres maestro primario para que no aparezca en el registro de servidores de nombres, y la utilización de appliances seguros y reforzados que permitan fáciles actualizaciones, en vez de sistemas basados en software operativo y servidores de propósito general. Igualmente, conviene monitorizar los servidores de nombres para comprobar no sólo que están operativos, sino también que están autorizados para acceder a las zonas que les han sido asignadas. Asimismo, se puede monitorizar las operaciones del servidor de nombres recopilando datos syslog en un único servidor de registros anfitrión y utilizando herramientas que avisen cuando un servidor registra un mensaje significativo.
Otra buena práctica será filtrar el tráfico hacia y desde sus servidores de nombres externos, así como configurar los clientes DNS (resolvers) con un servidor de nombres de backup, de modo que si falla el primero, las operaciones pasarán al segundo.
Por último, es aconsejable probar las configuraciones y datos de zona modificados antes de ponerlos en producción para descubrir errores inadvertidos. Después de modificar los datos de zona, se puede utilizar named-checskzone, una herramienta de validación de archivos de zona incluida en BIND 9 para chequear errores de sintaxis. Si no se dispone de esta capacidad, hay que configurar un nuevo proceso de nombres para descargar y probar el archivo de datos de zona. También es posible utilizar named-checkconf para comprobar los archivos de configuración o un nuevo proceso de nombres a fin de revisar los archivos named.conf de errores.
Fuente: IDG.es
No hay comentarios:
Publicar un comentario