|
|
Atención: 21 al 25 de mayo, Curso Global de Servidores con CentOS 6.
Atención: 23 al 27 de abril, Curso SUSE Linux Enterprise Desktop Administration. Atención: 21 y 28 de abril, 5 y 12 de mayo, Taller de programación de Python. Atención: Disponible ALDOS 1.4.3. Nuestro sistema operativo para escritorio. Cómo configurar un servidor de nombres de dominio (DNS), parte I.
Autor: Joel Barrios Dueñas
Correo electrónico: darkshram en gmail punto com Sitio de Red: http://www.alcancelibre.org/ Jabber ID: darkshram@jabber.org Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.1
Introducción.Es imprescindible primero estudiar, y comprender, los conceptos descritos en el documento titulado «Introducción al protocolo DNS.» Acerca de Bind (Berkeley Internet Name Domain).BIND (acrónimo de Berkeley Internet Name Domain) es una implementación del protocolo DNS y provee una implementación libre de los principales componentes del Sistema de Nombres de Dominio, los cuales incluyen:
El Servidor DNS BIND utilizado de manera amplia en Internet (99% de los servidores DNS) proporcionando una robusta y estable solución. Equipamiento lógico necesario.
Instalación a través de yum.Si se utiliza CentOS 6, o Red Hat™ Enterprise Linux 6, se puede instalar Bind 9.7 utilizando lo siguiente:
Si se utiliza CentOS 5, o Red Hat™ Enterprise Linux 5, se puede instalar Bind 9.3.6 utilizando lo siguiente:
Si se utiliza CentOS 5, o Red Hat™ Enterprise Linux 5, puede instalar, de manera opcional, Bind 9.7, el cual incluye soporte para DNSSEC, utilizando lo siguiente:
En los sistemas operativos mencionados, el paquete bind-chroot, de la versión 9.7, requiere generar la firma digital del servidor, y mover manualmente los componentes del paquete bind, hacia las rutas correspondientes dentro /var/named/chroot, y generar los enlaces simbólicos necesarios. Ejecute lo siguiente:
Procedimientos.SELinux y el servicio named.A mediados de 2008, Common Vulnerabilities and Exposures List, y US-CERT, reportaron que el investigador Dan Kaminsky descubrió que varias implementaciones de DNS (BIND 8 y 9 antes de 9.5.0-P1, 9.4.2-P1, y 9.3.5-P1; Microsoft DNS en todas las versiones de Windows 2000 SP4, XP SP2, y SP3, así como Server 2003 SP1, y SP2). La vulnerabilidad permite a atacantes remotos falsificar tráfico DNS a través de ciertas técnicas de contaminación de cache contra servidores de resolución recursiva (es decir cuando se usa la opción allow-recursion abierta a todo el mundo, como ocurre en los servidores DNS públicos), y se relaciona a insuficiente aleatoriedad de las ID de transacción, y de los puertos de origen. Es decir, vulnerabilidad de entropía de insuficiencia de zócalos (sockets) de DNS (conocido como DNS Insufficient Socket Entropy Vulnerability). En otras palabras, un atacante puede contaminar el cache de un servidor DNS y hacer que los clientes se conecten hacia direcciones falsas. Es importante aclarar que esta es realmente una vulnerabilidad del protocolo DNS. SELinux protege casi por completo al servicio named contra la vulnerabilidad anteriormente descrita. Es por tal motivo que es importante utilizar SELinux. A fin de que SELinux permita al servicio named trabajar con permisos de escritura para zonas maestras, es decir un esquema de servidor maestro con servidores esclavos, o bien como servidor DNS dinámico, utilice el siguiente mandato:
Lo anterior aplica para CentOS 5 y 6, y Red Hat Enterprise Linux 5 y 6.
Cualquier archivo de zona que se vaya a utilizar a través del servicio named, debe contar con los contextos de SELinux de usuario de sistema (system_u), rol de objeto (object_r) y tipo zona del servicio named (named_zone_t). En el siguiente ejemplo se utiliza el mandato chcon para cambiar los contextos del archivo denominado mi-dominio.zone, con el fin de definir los contextos de SELinux que requiere éste:
Lo anterior solamente es necesario si el archivo mi-dominio.zone fue creado fuera del directorio /var/named/chroot/var/named/data/, y fue movido hacia este último.
Preparativos.Idealmente se deben definir primero los siguiente datos:
Es importante tener bien en claro que los puntos 2, 3, y 4, involucran datos que deben existir previamente, y estar plenamente resueltos por otro servidor DNS; Lo anterior quiere decir que jamás se deben utilizar datos que sean parte, o dependan, del mismo dominio que se pretende resolver. De igual modo, el servidor donde se implementará el DNS deberá contar con un nombre FQDN, y que esté previa, y plenamente, resuelto en otro DNS. Como regla general, se generará una zona de reenvío por cada dominio sobre el cual se tenga autoridad plena y absoluta y se generará una zona de resolución inversa por cada red sobre la cual se tenga plena y absoluta autoridad. Es decir, si se es el propietario del dominio «cualquiercosa.com», se deberá generar el archivo de zona correspondiente, con el fin de resolver dicho dominio. Por cada red con direcciones IP privadas, sobre la cual se tenga control, y absoluta autoridad, se deberá generar un archivo de zona de resolución inversa a fin de resolver inversamente las direcciones IP de dicha zona. Regularmente la resolución inversa de las direcciones IP públicas es responsabilidad de los proveedores de servicio ya que son estos quienes tienen la autoridad plena y absoluta sobre dichas direcciones IP. Todos los archivos de zona deben pertenecer al usuario «named» a fin de que el servicio named pueda acceder a estos o bien modificar éstos en el caso de tratarse de zonas esclavas. Configuración mínima para el archivo /etc/named.conf en CentOS 6, y Red Hat™ Enterprise Linux 6.Edite el archivo /etc/named.conf:
La configuración mínima de este archivo, y la cual permitirá utilizar el servicio para todo tipo de uso, es la siguiente:
Lo anterior define como opciones que el directorio predeterminado será /var/named (ruta relativa a /var/named/chroot), define un archivo donde se almacena la información del caché en /var/named/data/cache_dump.db; un archivo de estadísticas en /var/named/data/named_stats.txt, un archivo de estadísticas específicas en lo concerniente al uso de la memoria en /var/named/data/named_mem_stats.txt; consultas recursivas permitidas solamente a 127.0.0.1 y 192.168.1.0/24, se definen como ejemplos de servidores DNS para reenviar consultas a 8.8.8.8 y 8.8.4.4, que corresponden a los servidores DNS públicos de Google, los cuales puede reemplazar por los servidores DNS del proveedor de acceso a Internet utilizado); se define que la primera opción al realizar una consulta será reenviar a los DNS que se acaban de definir; se incluyen los archivos de configuración /etc/named.rfc1912.zones, que corresponde a las zonas del RFC 1912, y la firma digital única que se generó automáticamente tras instalar el paquete bind; Se define que los controles se realizan solamente desde 127.0.0.1, hacia 127.0.0.1, utilizando la firma digital única; Se define que se utilizará DNSSEC, utilizando la firma digital localizada en el archivo /etc/named.iscdlv.key. Puede descargar un archivo plantilla, con todo lo anterior, desde AlcanceLibre.org, ejecutando lo siguiente:
Tome en consideración que los cambios en CentOS 6 y Red Hat™ Enterprise Linux 6 respecto de CentOS 5 y Red Hat™ Enterprise Linux 5, consisten en que se utiliza rndc-key en lugar de rndckey en la configuración de la firma digital, se añaden las líneas correspondientes a la configuración de DNSSEC, se añade configuración para el registro en bitácora y la zona de los servidores raíz va separada del archivo named.rfc1912.zones. CentOS 5 y Red Hat™ Enterprise Linux 5 puede utilizar exactamente la misma configuración instalando los paquetes bind97, bind97-chroot, bind97-libs y bind97-utils (desaparece el paquete caching-nameserver, cuyo contenido se integró al paquete bind97). Conviene asegurarse que el archivo /etc/named.conf tenga los contextos correspondientes para SELinux a fin de evitar potenciales problemas de seguridad.
Creación de los archivos de zona.Los siguientes corresponderían a los contenidos para los archivos de zona requeridos para la red local y por el NIC con el que se haya registrado el dominio. Cabe señalar que en las zonas de reenvío siempre se especifica al menos un registro SOA y un registro NS. De manera opcional, y en caso de que exista un servicio de correo electrónico, añada al menos un registro MX (Mail Exchanger o intercambiador de correo). Solamente necesitará sustituir nombres y direcciones IP, y quizá añadir nuevos registros para complementar su red local. Configuración mínima para /var/named/chroot/etc/named.conf en CentOS 5 y Red Hat™ Enterprise Linux 5.La configuración mínima del archivo /var/named/chroot/etc/named.conf, y que permitirá utilizar el servicio para todo tipo de uso, es la siguiente:
Lo anterior define como opciones que el directorio predeterminado será /var/named (ruta relativa a /var/named/chroot), define un archivo donde se almacena la información del caché en /var/named/data/cache_dump.db; un archivo de estadísticas en /var/named/data/named_stats.txt, un archivo de estadísticas específicas en lo concerniente al uso de la memoria en /var/named/data/named_mem_stats.txt; consultas recursivas permitidas solamente a 127.0.0.1, y 192.168.1.0/24; se definen como ejemplos de servidores DNS para reenviar consultas a 8.8.8.8, y 8.8.4.4, que corresponden a servidores DNS públicos de Google, los cuales puede reemplazar por los servidores DNS del proveedor de acceso a Internet utilizado; se define que la primera opción al realizar una consulta será reenviar a los DNS que se acaban de definir; se incluyen los archivos de configuración /etc/named.rfc1912.zones, que corresponde a las zonas del RFC 1912, y la firma digital única que se generó automáticamente tras instalar el paquete bind; Se define también que los controles se realizan solamente desde 127.0.0.1, hacia 127.0.0.1, utilizando la firma digital única. Conviene asegurarse que el archivo /var/named/chroot/etc/named.conf tenga los contextos correspondientes para SELinux a fin de evitar potenciales problemas de seguridad.
Ejemplo de Zona de reenvío red local /var/named/chroot/var/named/data/red-local.zone.
Zona de resolución inversa red local /var/named/chroot/var/named/data/1.168.192.in-addr.arpa.zone
Zona de reenvío del dominio /var/named/chroot/var/named/data/dominio.com.zoneSuponiendo que hipotéticamente se es la autoridad para el dominio «dominio.com», se puede crear una Zona de Reenvío con un contenido similar al siguiente:
Zona de resolución inversa del dominio /var/named/chroot/var/named/data/1.161.201.in-addr.arpa.zoneSuponiendo que hipotéticamente se es la autoridad para el segmento de red 201.161.1.0/24 (regularmente lo debe de hacer el proveedor de servicio de acceso hacia Internet), se puede crear una Zona de Resolución Inversa con un contenido similar al siguiente:
Cada vez que haga algún cambio en algún archivo de zona, deberá cambiar el número de serie a fin de que tomen efecto los cambios de inmediato cuando se reinicie el servicio named, ya que de otro modo tendría que reiniciar el equipo, algo poco conveniente. Las zonas de resolución inversa que involucran direcciones IP públicas son responsabilidad de los ISP (proveedores de servicio de acceso hacia Internet). Crear una zona de resolución inversa sin ser la autoridad de dicha zona tiene efecto sólo para quien use el servidor DNS recién configurado como único DNS. Configuración de parámetros en el archivo /etc/named.conf
Continúa en Cómo configurar un servidor de nombres de dominio (DNS), parte II. |
Comentarios Recientes