Cómo configurar un servidor de nombres de dominio (DNS), parte II.

Transcripción

1 1 de 9 18/09/ :41 a.m. Ingresar Registrarse Enviar Nota Twitter Google+ Descargas Servicios Portada Foros Manuales Servicios Cursos Linux Buscar al 19 de octubre, Curso Global de Servidores con CentOS 6. Disponible ALDOS Nuestro sistema operativo para escritorio. Sondeo Cómo configurar un servidor de nombres de dominio (DNS), parte II. Si ya probaste GNOME 3... Te gustó GNOME 3? Si No Este sondeo tiene 5 preguntas más. Iniciar Sondeo Resultados Más sondeos 15,959 votos 9 comentarios Autor: Joel Barrios Dueñas Correo electrónico: darkshram en gmail punto com Sitio de Red: Jabber ID: darkshram@jabber.org Creative Commons Reconocimiento-NoComercial-CompartirIgual Joel Barrios Dueñas. Usted es libre de copiar, distribuir y comunicar públicamente la obra y hacer obras derivadas bajo las condiciones siguientes: a) Debe reconocer y citar al autor original. b) No puede utilizar esta obra para fines comerciales (incluyendo su publicación, a través de cualquier medio, por entidades con fines de lucro). c) Si altera o transforma esta obra, o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta. Al reutilizar o distribuir la obra, tiene que dejar bien claro los términos de la licencia de esta obra. Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular de los derechos de autor. Los derechos derivados de usos legítimos u otras limitaciones no se ven afectados por lo anterior. Licencia completa en castellano. La información contenida en este documento y los derivados de éste se proporcionan tal cual son y los autores no asumirán responsabilidad alguna si el usuario, o lector, hace mal uso de éstos. Continuación de Cómo configurar un servidor de nombres de dominio (DNS), parte I. Seguridad adicional en DNS para uso público. Quienes hayan utilizado en recientes fechas los servicios de DNS Report, habrán notado que el diagnóstico en línea devuelve ahora un error que, en resumen, indica que el servidor puede ser susceptible de sufrir/participar en un ataque DDoS (Distributed Denail of Service o denegación de servicio distribuido). Un DDoS (Distributed Denial of Service) es una ampliación del ataque DoS, se efectúa con la instalación de varios agentes remotos en muchas computadoras que pueden estar localizadas en diferentes puntos del mundo. El atacante consigue coordinar esos agentes para así, de forma masiva, amplificar el volumen del saturación de información (flood), pudiendo darse casos de un ataque de cientos o millares de computadoras dirigido a una máquina o red objetivo. Esta técnica se ha revelado como una de las más eficaces y sencillas a la hora de colapsar servidores, la tecnología distribuida ha ido haciendo más sofisticada hasta el punto de otorgar poder de causar daños serios a personas con escaso conocimiento técnico. La falla reportada por la herramienta en línea de DNS Report, para un servidor DNS que permite consultas recursivas, indicará algo como lo siguiente: «ERROR: One or more of your nameservers reports that it is an open DNS server. This usually means that anyone in the world can query it for domains it is not authoritative for (it is possible that the DNS server advertises that it does recursive lookups when it does not, but that shouldn't happen). This can cause an excessive load on your DNS server. Alos, it is strongly discouraged to have a DNS server be both authoritative for your domain and be recursive (even if it is not open), due to the potential for cache poisoning (with no recursion, there is no cache, and it is impossible to poison it). Alos, the bad guys could use your DNS server as part of an attack, by forging their IP address» Significa que el servidor DNS puede permitir a cualquiera realizar consultas recursivas. Si se trata de un DNS que se desea pueda ser consultado por cualquiera, como puede ser el caso del DNS de un ISP, esto es normal y esperado. Si se trata de un servidor que sólo debe consultar la red local, o bien que se utiliza para propagar dominios alojados de manera local, si es conveniente tomar medidas al respecto. Solución al problema es modificar el archivo named.conf, donde se añade en la sección de vista local (view "local") la opción y una o más líneas que definan a la red o las redes que tendrán permitido realizar todo tipo de consultas. directory "/var/named"; forwarders { ;

2 2 de 9 18/09/ :41 a.m. inet allow { ; } keys { "rndc-key"; Lo anterior hace que sólo se puedan realizar consultas recursivas en el DNS desde /8, /8, /12 y /16, ya sea para un nombre de dominio alojado de manera local y otros dominios resueltos en otros servidores (ejemplo: etc). El resto del mundo sólo podrá realizar consultas sobre los dominios alojados de manera local y que estén configurado para permitirlo. En la siguiente configuración de ejemplo, se pretende lograr lo siguiente: Red Local: cualquier tipo de consulta hacia dominios externos y locales (es decir, alcancelibre.org, además de midominio.com). Resto del mundo: sólo puede hacer consultas para la zona de midominio.com De este modo se impide que haya consultas recursivas y con esto impedir la posibilidad de sufrir/participar de un ataque DDoS. directory "/var/named"; forwarders { ; inet allow { ; } keys { "rndc-key"; view "publico" { any; recursion no; zone "midominio.com" { file "data/midominio.com.zone"; allow-update { none; allow-transfer { ; ;

3 3 de 9 18/09/ :41 a.m. zone "miredlocal" { file "data/miredlocal.zone"; allow-update { none; allow-transfer { ; Un DDoS (Distributed Denial of Service) es una ampliación del ataque DoS, se efectúa con la instalación de varios agentes remotos en muchas computadoras que pueden estar localizadas en diferentes puntos del mundo. El atacante consigue coordinar esos agentes para así, de forma masiva, amplificar el volumen del saturación de información (flood), pudiendo darse casos de un ataque de cientos o millares de computadoras dirigido a una máquina o red objetivo. Esta técnica se ha revelado como una de las más eficaces y sencillas a la hora de colapsar servidores, la tecnología distribuida ha ido haciendo más sofisticada hasta el punto de otorgar poder de causar daños serios a personas con escaso conocimiento técnico. La falla reportada por la herramienta en línea de DNS Report, para un servidor DNS que permite consultas recursivas, indicará algo como lo siguiente: «ERROR: One or more of your nameservers reports that it is an open DNS server. This usually means that anyone in the world can query it for domains it is not authoritative for (it is possible that the DNS server advertises that it does recursive lookups when it does not, but that shouldn't happen). This can cause an excessive load on your DNS server. Alos, it is strongly discouraged to have a DNS server be both authoritative for your domain and be recursive (even if it is not open), due to the potential for cache poisoning (with no recursion, there is no cache, and it is impossible to poison it). Alos, the bad guys could use your DNS server as part of an attack, by forging their IP address» Significa que el servidor DNS puede permitir a cualquiera realizar consultas recursivas. Si se trata de un DNS que se desea pueda ser consultado por cualquiera, como puede ser el caso del DNS de un ISP, esto es normal y esperado. Si se trata de un servidor que sólo debe consultar la red local, o bien que se utiliza para propagar dominios alojados de manera local, si es conveniente tomar medidas al respecto. Solución al problema es modificar el archivo named.conf, donde se añade en la sección de vista local (view "local") la opción y una o más líneas que definan la red o las redes que tendrán permitido realizar todo tipo de consultas. directory "/var/named"; forwarders { ; inet allow { ; } keys { "rndc-key"; Lo anterior hace que sólo se puedan realizar todo tipo de consultas en el DNS desde /8, /8, /12 y /16, ya sea para un nombre de dominio alojado de manera local y otros dominios resueltos en otros servidores (ejemplo: etc). El resto del mundo sólo podrá realizar consultas sobre los dominios alojados de maneja local y que estén configurado para permitirlo. En la siguiente configuración de ejemplo, se pretende lograr lo siguiente:

4 4 de 9 18/09/ :41 a.m. Red Local: cualquier tipo de consulta hacia dominios externos y locales (es decir, alcancelibre.org, además de midominio.com). Resto del mundo: sólo puede hacer consultas para la zona de midominio.com De este modo se impide que haya consultas recursivas y con esto impedir la posibilidad de sufrir/participar de un ataque DDoS. directory "/var/named"; forwarders { ; inet allow { ; } keys { "rndc-key"; view "publico" { any; recursion no; zone "midominio.com" { file "data/midominio.com.zone"; allow-update { none; allow-transfer { ; ; ; zone "miredlocal" { file "data/miredlocal.zone"; allow-update { none; allow-transfer { ; Seguridad adicional en DNS para uso exclusivo en red local. Si se va a tratar de un servidor de nombres de dominio para uso exclusivo en red local, y se quieren evitar problemas de seguridad de diferente índole, puede utilizarse el parámetro allow-query, el cual servirá para especificar que sólo ciertas direcciones podrán realizar consultas al servidor de nombres de dominio. Se pueden especificar directamente direcciones IP, redes completas o listas de control de acceso que deberán definirse antes de cualquier otra cosa en el archivo /etc/named.conf. Archivo /etc/named.conf directory "/var/named/"; forwarders { ; ;

5 5 de 9 18/09/ :41 a.m. inet allow { ; } keys { "rndc-key"; zone "red-local" { file "data/red-local.zone"; allow-update { none; zone " in-addr.arpa" { file "data/ in-addr.arpa.zone"; allow-update { none; Las zonas esclavas. Las zonas esclavas se refieren a aquellas hospedadas en servidores de nombres de dominio secundarios y que hacen las funciones de redundar las zonas maestras en los servidores de nombres de dominio primarios. El contenido del archivo de zona es el mismo que en servidor primario. La diferencia está en la sección de texto utilizada en named.conf, donde las zonas se definen como esclavas y definen los servidores donde está hospedada la zona maestra. Archivo named.conf Servidor DNS secundario. view "publico" { any; recursion no; zone "dominio.com" { file "dominio.com.zone"; masters { ; zone "red-local" { file "data/red-local.zone"; masters { ; zone " in-addr.arpa" { file "data/ in-addr.arpa.zone"; masters { ; Adicionalmente, si desea incrementar seguridad y desea especificar en el Servidor DNS Primario que servidores tendrán permitido ser servidores de nombres de dominio secundario, es decir, hacer transferencias, puede utilizar el parámetro allowtransfer del siguiente modo: Archivo named.conf Servidor DNS Primario. view "publico" { any; recursion no;

6 6 de 9 18/09/ :41 a.m. zone "dominio.com" { file "dominio.com.zone"; allow-update { none; allow-transfer { ; ; zone "red-local" { file "data/red-local.zone"; allow-update { none; allow-transfer { ; ; zone " in-addr.arpa" { file "data/ in-addr.arpa.zone"; allow-update { none; allow-transfer { ; ; Seguridad adicional para transferencias de zona. Cuando se gestionan dominios a través de redes públicas, es importante considerar que si se tienen esquemas de servidores maestros y esclavos, siempre será más conveniente utilizar una clave cifrada en lugar de una dirección IP, debido a que esta última puede ser falsificada bajo ciertas circunstancias. Comúnmente se definen las direcciones IP desde las cuales se permitirá transferencias de zonas, utilizando una configuración en el archivo /var/named/chroot/etc/named.conf como la ejemplificada a continuación, donde los servidores esclavos corresponden a los servidores con direcciones IP y : zone "mi-dominio.org" { file "data/mi-dominio.org.zone"; allow-update { none; }: allow-transfer { ; ; Lo anterior permite la transferencia de zona para los servidores con direcciones IP y , los cuales utilizan la siguiente configuración en el archivo /var/named/chroot/etc/named.conf, ejemplificada a continuación, donde el servidor primario (zonas maestras) corresponde al servidor con dirección IP : zone "mi-dominio.org" { file "data/mi-dominio.org.zone"; masters { ; El inconveniente del esquema anterior es que es fácil falsificar las direcciones IP. A fin de evitar que esto ocurra, el método recomendado será utilizar una clave cifrada que será validada en lugar de la dirección IP. La llave se crea con el mandato dnsseckeygen, especificando un algoritmo, que puede ser RSAMD5 o RSA, DSA, DH (Diffie Hellman) o HMAC-MD5, el tamaño de la llave en octetos (bits), el tipo de la llave, que puede ser ZONE, HOST, ENTITY o USER y el nombre específico para la clave cifrada. DSA y RSA se utilizan para DNS Seguro (DNSSEC), en tanto que HMAC-MD5 se utiliza para TSIG (Transfer SIGnature o transferencia de firma). Lo más común es utilizar TSIG. En el siguiente ejemplo, se generará en el directorio de trabajo actual la clave mi-dominio.org, utilizando /dev/random como fuente de datos aleatorios, un algoritmo HMAC-MD5 tipo HOST de 128 octetos (bits): dnssec-keygen -r /dev/random -a HMAC-MD5 -b 128 -n HOST mi-dominio.org Lo anterior devuelve una salida similar a la siguiente: Kmi-dominio.org

7 7 de 9 18/09/ :41 a.m. Al mismo tiempo se generaran dos archivos en el directorio /var/named/chroot/var/named/, que corresponderían a Kmi-dominio.org key y Kmi-dominio.org private. Kmi-dominio.org key deberá tener un contenido como el siguiente, el cual corresponde al registro que se añade dentro del archivo de zona: mi-dominio.org. IN KEY NPuNuxvZAjtd3mriuygT8Q== Kmi-dominio.org private deberá tener un contenido como el siguiente: Private-key-format: v1.2 Algorithm: 157 (HMAC_MD5) Key: NPuNuxvZAjtd3mriuygT8Q== En ambos casos, NPuNuxvZAjtd3mriuygT8Q== corresponde a la clave cifrada. Ambos deben tener la misma clave. Los dos archivos sólo deben tener atributos de lectura para el usuario named. chmod 400 Kmi-dominio.org * chown named.named Kmi-dominio.org * A fin de poder ser utilizados, ambos archivos deben ser movidos hacia el directorio /var/named/chroot/var/named/data/. mv Kmi-dominio.org * /var/named/chroot/var/named/data/ A continuación, restaure los atributos predeterminados para estos archivos utilizando el mandato restorecon, del siguiente modo: restorecon -R /var/named/chroot/var/named/data/ En el servidor primario (zonas maestras), se añade la siguiente configuración en el archivo /var/named/chroot/etc/named.conf: key mi-dominio.org { algorithm HMAC-MD5; secret "NPuNuxvZAjtd3mriuygT8Q=="; zone "mi-dominio.org" { file "data/mi-dominio.org.zone"; allow-update { none; allow-transfer { key mi-dominio.org; Los servidores esclavos utilizarían la siguiente configuración en el archivo /var/named/chroot/etc/named.conf, en donde se define la clave y que ésta será utilizada para realizar conexiones hacia el servidor primario (zonas maestras) ( , en el ejemplo): key mi-dominio.org { algorithm HMAC-MD5; secret "NPuNuxvZAjtd3mriuygT8Q=="; server { keys { mi-dominio.org; zone "mi-dominio.org" { masters { ; Comprobaciones. Tanto en el servidor primario (zonas maestras) como en los servidores esclavos, utilice el mandato tail para ver la salida del archivo /var/log/messages, pero sólo aquello que contenga la cadena de caracteres named: tail -f /var/log/messages grep named Al reiniciar el servicio named en servidor primario (zonas maestras), se debe mostrar una salida similar a la siguiente cuando un servidor esclavo realiza una transferencia: Sep 10 01:57:40 servidor named[6042]: listening on IPv4 interface eth0, #53 Sep 10 01:57:40 servidor named[6042]: command channel listening on #953 Sep 10 01:57:40 servidor named[6042]: zone 0.in-addr.arpa/IN: loaded serial 42 Sep 10 01:57:40 servidor named[6042]: zone in-addr.arpa/IN: loaded serial Sep 10 01:57:40 servidor named[6042]: zone 255.in-addr.arpa/IN: loaded serial 42 Sep 10 01:57:40 servidor named[6042]: zone ip6.arpa/IN: loaded serial Sep 10 01:57:40 servidor named[6042]: zone localdomain/in: loaded serial 42 Sep 10 01:57:40 servidor named[6042]: zone localhost/in: loaded serial 42 Sep 10 01:57:40 servidor named[6042]: zone mi-dominio.org/in: loaded serial Sep 10 01:57:40 servidor named: Iniciación de named succeeded

8 8 de 9 18/09/ :41 a.m. Sep 10 01:57:40 servidor named[6042]: running Sep 10 01:57:40 servidor named[6042]: zone mi-dominio.org/in: sending notifies (serial ) Sep 10 01:59:49 servidor named[6042]: client #32817: transfer of 'mi-dominio.org/in': AXFR started Al reiniciar el servicio named en los servidores esclavos, se debe mostrar una salida similar a la siguiente: Sep 10 01:58:15 servidor named[5080]: listening on IPv4 interface eth0, #53 Sep 10 01:58:15 servidor named[5080]: command channel listening on #953 Sep 10 01:58:15 servidor named[5080]: zone 0.in-addr.arpa/IN: loaded serial 42 Sep 10 01:58:15 servidor named[5080]: zone in-addr.arpa/IN: loaded serial Sep 10 01:58:15 servidor named[5080]: zone 255.in-addr.arpa/IN: loaded serial 42 Sep 10 01:58:15 servidor named[5080]: zone ip6.arpa/IN: loaded serial Sep 10 01:58:15 servidor named[5080]: zone localdomain/in: loaded serial 42 Sep 10 01:58:15 servidor named[5080]: zone localhost/in: loaded serial 42 Sep 10 01:58:15 servidor named[5080]: running Sep 10 01:58:15 servidor named: Iniciación de named succeeded Sep 10 01:58:15 servidor named[5080]: zone mi-dominio.org/in: transferred serial Sep 10 01:58:15 servidor named[5080]: transfer of 'mi-dominio.org/in' from #53: end of transfer Sep 10 01:58:15 servidor named[5080]: zone mi-dominio.org/in: sending notifies (serial ) Reiniciar servicio y depuración de configuración. Al terminar de editar todos los archivos involucrados, sólo bastará reiniciar el servidor de nombres de dominio. service named restart Si queremos que el servidor de nombres de dominio quede añadido entre los servicios en el arranque del sistema, deberemos realizar lo siguiente a fin de habilitar named junto con el arranque del sistema: chkconfig named on Realice prueba de depuración y verifique que la zona haya cargado con número de serie: tail -80 /var/log/messages grep named Lo anterior, si está funcionando correctamente, debería devolver algo parecido a lo mostrado a continuación: Sep 10 02:15:15 servidor named[30618]: starting BIND u named Sep 10 02:15:15 servidor named[30618]: using 1 CPU Sep 10 02:15:15 servidor named: Iniciación de named succeeded Sep 10 02:15:15 servidor named[30622]: loading configuration from '/etc/named.conf' Sep 10 02:15:15 servidor named[30622]: no IPv6 interfaces found Sep 10 02:15:15 servidor named[30622]: listening on IPv4 interface lo, #53 Sep 10 02:15:15 servidor named[30622]: listening on IPv4 interface eth0, #53 Sep 10 02:15:15 servidor named[30622]: command channel listening on #953 Sep 10 02:15:16 servidor named[30622]: zone in-addr.arpa/IN: loaded serial 3 Sep 10 02:15:16 servidor named[30622]: zone in-addr.arpa/IN: loaded serial Sep 10 02:15:16 servidor named[30622]: zone localhost/in: loaded serial 1 Sep 10 02:15:16 servidor named[30622]: zone mi-dominio.com.mx/in: loaded serial Sep 10 02:15:16 servidor named[30622]: running Sep 10 02:15:16 servidor named[30622]: zone in-addr.arpa/IN: sending notifies (serial ) Sep 10 02:15:16 servidor named[30622]: zone mi-dominio.com.mx/in: sending notifies (serial ) Última Edición 19/10/2011, 09:36 11,359 Accesos Noticias Recientes Comentarios Recientes Enlaces Recientes Censura de términos en libr... SUSE lanza la primera soluc... Excelente oportunidad laboral SUSE realizará la primera c... Foxconn mejora las condicio... Red Hat presente en Sinergi... LiveCD de ServOS 1.3 liberada > [+186] Excelente oportunidad lab... > [+9] [+4] [+2] [+2] * 3CXphone Dezoft.com Soluciones TI El Rincón de Tux Bitácora Personal de.::k... Gomezbjesus. Desarrollo,... Comunidad Salud Libre Comunidad de Software Libre

9 9 de 9 18/09/ :41 a.m. Linux ecológico en español Geeklog Hispano Derechos de autor 2012 Alcance Libre Todas las marcas y logotipos mencionados en este sitio de Internet son propiedad de sus respectivos dueños Joel Barrios Dueñas. Salvo que se indique lo contrario, todo el contenido está disponible bajo los términos de la licencia Creative Commons Reconocimiento 2.5. Visite nuestro Directorio de noticias y Delti.com.mx.