Fortificación de un Servicio DNS

Entorno base. Elementos base del servicio a nivel de sistemas y comunicaciones.

  • Sistema operativo:
  • Software de Bind
  • Topología de Red
  1. Medidas en relación a la seguridad de los datos
  • Parametrizaciones
  • Información de registros de zona
  1. Protección de los mensajes en operaciones DNS
  • Queries. Consultas/Respuestas
  • Transferencias de Zona
  • Notificaciones
  • Actualizaciones Dinámicas Ataque de Amplificación: se pretende desbordar la capacidad de respuesta de un servidor haciéndole llegar una gran cantidad de datos DNS.

-Sistema Operativo

Debe estar parcheado, actualizado y desactivado los servicios innecesarios.

-Configuración del Software

  • Control y seguimiento del software: actualizado y al corriente de posibles vulnerabilidades. (Política de revisión de software)
  • Ocultar la versión: deshabilitar directivas que puedan mostrar la información sobre la versión del software en ejecución.
  • Ejecutar el software DNS con un usuario no privilegiado: no debe ejecutarse nunca como root o usuario privilegiado del sistema.
  • Crear el entrono restringido chroot: crear la estructura de directorios donde se confinará el servicio.
  • Asignación de permisos: verificar la correcta asignación de permisos sobre los sistemas de ficheros y su contenido, evitando accesos no autorizados a configuraciones o ficheros de datos.
  • Configuración de ficheros de log: Configurar la recolección de logs a través de las directivas de logging en el fichero de configuración named.conf. Además, activar el envío a servidores remotos en la configuración de logs del sistema (por ejemplo rsyslog.conf).
  • Arranque del servicio en el entorno restringido

TOPOLOGÍA DE RED

Una buena implementación de DNS debe separar siempre los servidores según su rol. Servidores autoritativos y cache recursivos serán dos componentes funcionales claramente diferenciados que requieren ser tratados de forma independiente en el diseño de la arquitectura de red.

Generalmente, las organizaciones necesitan una infraestructura DNS con dos objetivos: (1) que permita a su red interna acceder a internet, y (2) ofrecer resolución a redes externas de sus recursos públicos.

Para dotar de mayor seguridad a la infraestructura, es necesaria una segmentación de los servidores según su rol e importancia y establecer así distintas capas de exposición. La ventaja de esta implantación es la seguridad y resiliencia ante ataques. La desventaja, el costo y mayor complejidad de administración.

Segregación de roles servidor DNS. Autoritativo y Caché

roles_dns

Diseño de la arquitectura de red

A la hora del diseño de la arquitectura de red en un servicio DNS hay que contemplar claramente una separación de funciones dependiendo de la información que suministre el servidor autoritativo, con el objeto de separar la información pública de la privada.

Servidor Autoritativo Público. Responderá a solicitudes DNS desde una red externa, ofreciendo los registros públicos del dominio de la organización. Puede situarse en una red pública aislada para mayor seguridad, pero generalmente se sitúa en la red DMZ, es decir, el segmento de red que es frontera entre la red interna e internet.

Servidor Autoritativo Privado. Responderá a únicamente a solicitudes procedente de la misma red interna. Situado en la red interna.

Servidor Máster Autoritativo “Oculto” (Hidden Máster o Sealth): es un servidor DNS oculto primario que no aparece en los registros NS de zona, aunque es máster de la misma. El servidor oculto se sitúa en la red interna tras un firewall y no puede ser alcanzado desde redes externas de internet y tampoco se usa para servir información. Su única función es la de mantener las zonas y transferir zonas a los servidores secundarios.

Implementación de Servidores caché recursivos.

En la DMZ se situarán los servidores dedicados recursivos. Estos serán los únicos servidores que puedan realizar recursión para solicitudes procedentes de resolvers de la red interna y así garantizar la resolución de cualquier recurso de internet a la misma. Jamás deben permitir consultas recursivas procedentes del exterior. Estos servidores no deben usarse como resolvers directamente sino que deben ser accedidos a través de un forwarder.

Los servidores recursivos internos generalmente se configurarán como redirigir (forwarder) las consultas que no conocen hacia los servidores recursivos de la DMZ (como un proxy DNS). Por ejemplo, cuando un servidor recursivo interno no conoce la resolución de un domino externo de internet, dirigirá la consulta al servidor recursivo localizado en la DMZ el cual se encargará de hacer la recursión y devolver la respuesta al servidor interno.

Redundancia y alta disponibilidad.

Para reducir la posibilidad de una pérdida del servicio se proveerá de redundancia geográfica y de red a los servidores autoritativos. Esto supone que estarán en subredes independientes tras routers distintos y físicamente en lugares distintos. Adicionalmente, se puede disponer de un servidor DNS master autoritativo oculto (hidden master), y sólo serán visibles masters secundarios como servidores de nombres. Estos tomarán todas sus zonas desde el servidor máster oculto a través de transferencias de zona o actualizaciones dinámicas.

implementacion_infraestructura_dns

MONITORIZACIÓN INTERNA

En un sistema de cierta importancia y/o criticidad es muy recomendable contar con un sistema de monitorización para detectar posibles ataques o eventos que sucedan en la red interna. Con ese fin, se recomienda implementar mecanismos de detección de intrusión (IPS/IDS), monitorización de accesos, concentradores de logs/eventos o SIEM (Security Information and Event Management) etc.

RESUMEN DE MEDIDAS EN EL ENTORNO BASE DEL SERVICIO DNS (Cheklists de medidas de seguridad en el entorno del servidor DNS)

Sistema Operativo

  • Parcheado del SO
  • Deshabilitar Servicios innecesarios

Software DNS

  • Software actualizado y parcheado
  • Ocultar información de versionado
  • Ejecutar como usuario no privilegiado
  • Aislar el entorno del software (chroot)
  • Configuración logging

Topología de Red

  • Separar Roles en distintos servidores. Autoritativos y Cachés
  • Redundancia geográfica y de red de servidores autoritativos
  • En caso de uso de split DNS, configurar mínimo vista externa e interna
  • Si se usa un servidor master oculto (interno), restringir las transferencias a servidores internos

Monitorización

  • Contemplar la implementación de sistemas de prevención/detección de intrusiones

MEDIDAS DE SEGURIDAD EN LAS TRANSACCIONES

Seguridad en consultas y respuestas DNS: Las amenazas principales que afectan a las queries DNS son las relacionadas con el spoofing, las cuales se pueden materializar en ataques de DNS cache poisoning, denegaciones de servicio así como ataques de amplificación DNS. Adicionalmente y sacando provecho de la debilidad propia del protocolo DNS, es posible la manipulación de respuestas capturadas en un entorno local a través de sniffing de tráfico de red.

  • Limitar recursión. Segmentación red/vistas
  • Defensa con el IP Spoofing. Filtrado de tráfico
  • Mejoras en los servicios autoritativos. Response Rate Limiting: Es fundamental comprobar que los servidores autoritativos rechazan siempre consultas recursivas y sólo ofrecen resolución para los registros de su dominio.

Seguridad en transacciones de transferencias de zona: Las amenazas principales que afectan a las queries DNS son las relacionadas con el spoofing, las cuales se pueden materializar en ataques de DNS cache poisoning, denegaciones de servicio así como ataques de amplificación DNS. Adicionalmente y sacando provecho de la debilidad propia del protocolo DNS, es posible la manipulación de respuestas capturadas en un entorno local a través de sniffing de tráfico de red.

  • Uso de ACLs y filtrado IP
  • TSIG (Transaction SIGnature)

SEGURIDAD EN NOTIFICACIONES: Las amenazas de spoofing sobre transacciones de notificación (las que envía el servidor autoritativo a los esclavos cuando se ha producido un cambio en las zonas), son las mismas que para una transferencia de zona. No obstante, el impacto es menor en cuanto la transacción en sí no lleva información sensible. El efecto que en un servidor esclavo podrían causar notificaciones espurias sería la de conseguir que solicitase una transferencia de zona y, en caso extremo, ser víctima de una denegación de servicio si el volumen de notificaciones es muy alto.

  • ACLs y filtrado IP
  • Uso de TSIG en notificaciones.

SEGURIDAD EN ACTUALIZACIONES DINÁMICAS: Estas transacciones son generalmente utilizadas en entornos que requieren una actualización de las zonas con bastante frecuencia y volumen, lo que dificulta la administración manual de los ficheros de zona. Al tratarse de una tarea administrativa que directamente incide en el contenido de las zonas, es una transacción que es necesario proteger de manipulaciones malintencionadas.

  • TSIG para actualizaciones dinámicas
  • Seguridad del canal de comunicación.

MEDIDAS DE SEGURIDAD EN LA PROTECCIÓN DE DATOS

El registro SOA de una zona establece los parámetros globales para la misma. Para optimizar la latencia y distribución de los registros de zona y sus actualizaciones, los parámetros que afectan al registro SOA deben ser escogidos cuidadosamente para regular la comunicación entre los servidores primarios y secundarios.

Los valores recomendados son:

  • Serial (numero): Este valor en el campo RDATA del registro SOA se usa para indicar cambios de zona. Debe ser incrementado siempre que se realice cualquier modificación en los datos de zona.
  • Refresh (segundos): Comunica a servidores secundarios cuántos segundos se debe esperar entre transferencias de zona. Si se trata de zonas actualizadas frecuentemente, se recomienda un periodo de 20 minutos a 2 horas. En caso de ser infrecuentes las actualizaciones, se aconseja fijar el intervalo entre 2 y 12 horas. En caso de uso de DNSSEC, el valor siempre será menor que el periodo de validez del registro firmado de zona RRSIG21
  • Retry (segundos): Es el tiempo que un servidor secundario debe esperar para reintentar una transferencia de zona que ha fallado previamente. Debe ser una fracción del Refresh Value especificado, siendo una estimación valores entre 5 minutos y 1 hora. . Si el servidor primario envía un mensaje NOTIFY, la transferencia en los secundarios se hará de inmediato, sin esperar a que se consuma el Refresh Value.
  • Expire: Tiempo durante el cual un servidor secundario debe considerar válidos los registros de la zona si no se ha podido realizar un refresco de la misma. Se debe fijar a un múltiplo del valor Refresh, preferiblemente entre 2 y 4 semanas.
  • TTL Mínimo: Valor en segundos que un servidor secundario debe guardar en caché un resultado negativo (NXDOMAIN) de un registro. Dependiendo de la frecuencia de actualizaciones de una zona, se recomienda fijar entre 30 minutos (zonas dinámicas) a 5 días para zonas estáticas o de infrecuente actualización. Un valor de 5 minutos se puede adoptar como valor umbral mínimo.

RESTRINGIR INFORMACIÓN PROPORCIONADA POR TIPOS DE REGISTROS

Entre los tipos de registros DNS existentes, los más habituales para mostrar información están: registros TXT, que almacenan un texto destinado a dar información a personas y aplicaciones sobre redes, hosts, servicios, u otro tipo de información genérica. Los registros HINFO, recogen información sobre el host que alberga el servicio DNS y los registros LOC, sobre la localización geográfica del servidor. El administrador del sistema debe asegurarse de que estos registros no ofrecen información sensible que pueda ser aprovechada por un atacante para reconocer características del entorno o cualquier otro dato que le pueda revelar posibles vectores de ataque.

Vocabulario y Abreviaturas

Red DMZ: o red perimetral es una red local que se ubica entre la red interna de una organización y una red externa, generalmente en Internet.

Forwarder: es que un servidor DNS actué a modo de proxy DNS y reenvié todas las peticiones que reciba a otros servidores DNS.

Chroot: es comunmente usado como medida de seguridad. Si alguna vez has usado un servidor de ftp anonimo, has estado en una jaula chroot. El servidor Ftp se enjaula a si mismo dentro de un directorio especial para los usuarios anonimos. El demonio bind encargado del DNS (Domain Name System) suele ser enjaulado tambien. Tambien se sugiere enjaular los shell remotos telnet y ssh dentro del correspondiente directorio home del usuario, de forma que solo puedan actualizar su página web.

ACLs: Una lista de control de acceso o ACL (del inglés, access control list) es un concepto de seguridad informática usado para fomentar la separación de privilegios. Es una forma de determinar los permisos de acceso apropiados a un determinado objeto, dependiendo de ciertos aspectos del proceso que hace el pedido.

TSIG: transferencia de seguras de zonas. Es un método para firmar las transacciones y mensajes de DNS mediante el uso de claves simétricas (secretas) compartidas. Esto incluye los mensajes de consulta recursiva, notificación o consultas dig, aunque TSIG suele utilizarse sobre todo para proteger la transferencia de zonas de un dominio entre un servidor de DNS primario y su(s) secundario(s). TSIG opera con cifrado simétrico, es decir, los servidores implicados en la transacción comparten una misma clave. Esto nos permitirá restringir quién puede transferir las zonas DNS entre servidores. Es el caso que aplicaremos en este documento.

Fuentes:

  • Wikipedia
  • Inteco
Etiquetado con:

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.