DNSSEC ( Extensiones de seguridad del sistema de nombres de dominio en inglés ) es un conjunto de extensiones IETF para el protocolo DNS que le permite minimizar los ataques asociados con la suplantación de direcciones IP al resolver nombres de dominio . Su objetivo es proporcionar a los clientes DNS (resolución de términos en inglés) respuestas auténticas a las consultas de DNS (o información auténtica sobre el hecho de que faltan datos) y garantizar su integridad. Utiliza criptografía de clave pública. La disponibilidad de los datos y la confidencialidad de las solicitudes no están aseguradas. Garantizar la seguridad del DNS es fundamental para la seguridad general de Internet.
Inicialmente , el Sistema de nombres de dominio (DNS) no se desarrolló con fines de seguridad, sino para crear sistemas distribuidos escalables. Con el tiempo, el sistema DNS se vuelve cada vez más vulnerable. Los atacantes redirigen fácilmente las solicitudes de los usuarios por nombre simbólico a servidores ficticios y así obtienen acceso a contraseñas, números de tarjetas de crédito y otra información confidencial. Los propios usuarios no pueden hacer nada al respecto, ya que en la mayoría de los casos ni siquiera sospechan que la solicitud fue redirigida: la entrada en la línea del navegador y el sitio en sí son exactamente los mismos que el usuario espera ver. DNSSEC es un intento de seguridad mientras es compatible con versiones anteriores.
DNSSEC se diseñó para proteger a los clientes de datos de DNS falsos, como los generados por el envenenamiento de caché de DNS . Todas las respuestas de DNSSEC están firmadas digitalmente. Al verificar una firma digital, el cliente DNS verifica la exactitud e integridad de la información.
DNSSEC no cifra ni cambia la administración de datos y es compatible con versiones anteriores del sistema y las aplicaciones DNS actuales. DNSSEC también puede certificar información como certificados criptográficos de uso general almacenados en el registro DNS CERT . RFC 4398 describe cómo distribuir estos certificados, incluso por correo electrónico, lo que permite que DNSSEC se use como un almacén distribuido globalmente de certificados de clave de firma.
DNSSEC no proporciona privacidad de datos; en particular, todas las respuestas DNSSEC están autenticadas pero no encriptadas. DNSSEC no protege contra los ataques DoS directamente, aunque de alguna manera lo hace indirectamente. Se utilizan otros estándares (no DNSSEC) para proporcionar una gran cantidad de datos que se envían entre servidores DNS.
La especificación DNSSEC ( DNSSEC-bis ) detalla el protocolo DNSSEC actual. Consulte RFC 4033 , RFC 4034 y RFC 4035 .
Inicialmente, el sistema de nombres de dominio no contaba con mecanismos de protección contra la sustitución de información en la respuesta del servidor, ya que en el momento de su desarrollo (a principios de la década de 1980), las amenazas de seguridad de la Internet moderna no eran relevantes. Al mismo tiempo, los clientes juzgaron la exactitud de la información recibida únicamente por el identificador de solicitud de dos bytes. Por lo tanto, el atacante necesitaba iterar sobre 65536 valores para "envenenar el caché". Esto significó que los datos en el sistema DNS se corrompieron (intencionalmente o debido a un error), y el servidor DNS los almacena en caché para optimizar el rendimiento (el caché se "envenena") y comienza a entregar estos datos no auténticos a sus clientes. Allá por 1990, Steve Bellovin identificó graves fallas de seguridad . La investigación en esta área ha comenzado y ha estado en pleno desarrollo desde la publicación del informe en 1995 [1] .
La primera edición de DNSSEC RFC 2065 fue publicada por el IETF en 1997. Los intentos de implementar esta especificación llevaron a la nueva especificación RFC 2535 en 1999. Se planeó implementar DNSSEC basado en IETF RFC 2535 .
Desafortunadamente, la especificación IETF RFC 2535 tuvo serios problemas para escalar a todo Internet. En 2001, quedó claro que esta especificación no era adecuada para redes grandes. Durante el funcionamiento normal, los servidores DNS a menudo no estaban sincronizados con sus padres (dominios superiores en la jerarquía). Por lo general, esto no era un problema, pero con DNSSEC habilitado, los datos desincronizados podrían tener un efecto DoS no intencional. El DNS seguro es mucho más intensivo desde el punto de vista informático y, con mayor facilidad que el DNS "clásico", puede ocupar todos los recursos informáticos.
La primera versión de DNSSEC requería una comunicación de seis mensajes y una gran cantidad de datos para implementar cambios en el niño (todas las zonas DNS del niño deben transferirse completamente al padre, el padre hace los cambios y los envía de regreso al niño ). Además, los cambios en la clave pública podrían tener un efecto desastroso. Por ejemplo, si la zona ".com" cambiara su clave, entonces tendrían que enviarse 22 millones de registros (porque todos los registros en todos los sucesores debían actualizarse). Por lo tanto, DNSSEC en forma de RFC 2535 no se pudo escalar al tamaño de Internet.
Estas complejidades, a su vez, llevaron al surgimiento de nuevas especificaciones ( RFC 4033 , RFC 4034 , RFC 4035 ) con cambios fundamentales en DNSSEC (DNSSEC-bis), cuya nueva versión eliminó el principal problema de la implementación anterior y, aunque en la nueva especificación, los clientes deben realizar acciones adicionales para verificar las claves, resultó ser bastante adecuado para el uso práctico.
En 2005 apareció la edición actual de DNSSEC, con la que todos trabajan. Un evento histórico ocurrió en 2008, cuando Dan Kaminsky le mostró al mundo que puedes envenenar el caché en 10 segundos. Los proveedores de software de DNS han respondido seleccionando aleatoriamente el puerto de salida para la consulta además del ID de la consulta. En el camino, comenzaron las disputas sobre la implementación de DNSSEC.
El cambio de DNSSEC, llamado DNSSEC-bis (el nombre se le dio para distinguir DNSSEC-bis del enfoque original de DNSSEC en RFC 2535 ) utiliza el principio DS ( firmante de delegación ) para proporcionar una capa adicional de delegación indirecta cuando se transfieren zonas de padres a hijos . . En el nuevo enfoque, al cambiar la clave pública, solo se envían uno o dos mensajes al administrador del dominio principal en lugar de seis: el heredero envía un resumen (huella digital, hash) de la nueva clave pública al principal. El padre simplemente almacena el identificador de clave pública para cada uno de los hijos. Esto significa que se enviará una cantidad muy pequeña de datos al padre en lugar de que se intercambie una gran cantidad de datos entre el hijo y el padre.
La firma y validación de datos de DNS genera una sobrecarga adicional, lo que afecta negativamente el rendimiento de la red y del servidor. Por ejemplo, en promedio, la zona DNSSEC (un conjunto de nombres de dominio de cierto nivel incluidos en un dominio específico) es de 7 a 10 veces más grande que el propio sistema DNS. La generación y verificación de firmas consume mucho tiempo de CPU. Las firmas y las claves ocupan un orden de magnitud más de espacio en el disco y en la RAM que los propios datos.
El principio de funcionamiento de las DNSSEC se basa en el uso de firmas digitales . El administrador tiene un registro de coincidencia del nombre de dominio y la dirección IP. DNSSEC pone a cada uno de ellos en estricta conformidad con una secuencia de caracteres especial y estrictamente definida, que es una firma digital. La característica principal de una firma digital es que existen métodos abiertos y disponibles públicamente para verificar la autenticidad de una firma, pero generar una firma para datos arbitrarios requiere que la clave secreta de firma esté disponible. Por lo tanto, cada participante en el sistema puede verificar la firma, pero en la práctica solo el que tiene la clave secreta puede firmar datos nuevos o modificados.
En teoría, nada prohíbe que un hacker calcule la clave secreta y recoja una firma, pero en la práctica, para una clave lo suficientemente compleja y larga, tal operación no se puede realizar en un tiempo razonable con las herramientas informáticas y los algoritmos matemáticos existentes.
Con una clave secreta, calcular una firma digital no es difícil. Tal es el trabajo de los sistemas de encriptación de clave pública asimétrica que subyacen a los algoritmos de firma digital.
Digamos que un usuario accede al sitio wikipedia.org. Sucede lo siguiente:
Si algo no se puede validar, el resolutor devolverá un error de falla de servicio.
La cadena de confianza así formada se reduce al dominio raíz ya la clave de la zona raíz.
El registro de Delegación de firma ( DS ) contiene un hash del nombre de dominio del heredero y su KSK. El registro DNSKEY contiene la parte pública de la clave y sus identificadores (ID, tipo y función hash utilizada).
KSK (clave de firma de clave) significa clave de firma de clave (clave a largo plazo), y ZSK (clave de firma de zona) significa clave de firma de zona (clave a largo plazo). Con la ayuda de KSK, se verifica el ZSK, que se utiliza para firmar la zona raíz. La Zona Raíz ZSK es creada por PTI (la división funcional de la IANA de la ICANN ), que es técnicamente responsable de propagar la zona raíz del DNS. Según el procedimiento de la ICANN, la Zona Raíz ZSK se actualiza cuatro veces al año.
Para validar por completo todos los datos transferidos mediante DNSSEC, se requiere una cadena de confianza desde la zona raíz (.) del DNS. La implementación de una zona raíz debidamente firmada en todos los servidores DNS raíz podría provocar el colapso de la Internet moderna, por lo que el IETF trabajó con la ICANN para desarrollar un procedimiento paso a paso para implementar una zona raíz firmada y un mecanismo de distribución de claves . El procedimiento se prolongó durante más de 8 meses e incluyó una introducción paso a paso a los servidores DNS primero de la zona raíz, firmados con una clave de firma electrónica no válida . Este paso fue necesario para proporcionar pruebas de servidores bajo carga, para mantener la compatibilidad con software anterior y para dejar la capacidad de revertir a una configuración anterior.
Para junio de 2010, todos los servidores raíz funcionaban correctamente con una zona firmada con una clave no válida. En julio, ICANN realizó una conferencia internacional dedicada al procedimiento de generación de claves de firma electrónica, que posteriormente fue firmada por la zona raíz.
El 15 de julio de 2010 se realizó la firma de la zona raíz y se inició la implementación de la zona firmada en los servidores. El 28 de julio, ICANN anunció [2] la finalización de este proceso. La zona raíz se firmó digitalmente y se propagó en el sistema DNS.
El 31 de marzo de 2011, se firmó la zona más grande de Internet (90 millones de dominios) - .com [3] .
ICANN ha elegido un modelo donde la firma de la zona se gestiona bajo el control de representantes de la comunidad de Internet (Representante de la comunidad de confianza, TCR). Los representantes fueron seleccionados entre aquellos que no están asociados con la administración de la zona raíz del DNS. Los representantes electos sirvieron como Crypto Officers (CO) y Accionistas clave de recuperación (RKSH). Los CO recibieron claves físicas para permitir la generación de la clave ZSK EDS, y los RKSH están en posesión de tarjetas inteligentes que contienen partes de la clave (KSK) utilizadas dentro del equipo criptográfico. Algunos medios de comunicación han concluido que se realizarán procedimientos que requieran la presencia del CO o RKSH en caso de emergencias en la red [4] . Sin embargo, de acuerdo con los procedimientos de ICANN, los CO estarán involucrados cada vez que se genere una clave de firma de zona (ZSK), hasta 4 veces al año, y RKSH probablemente nunca, o en caso de pérdida de claves de CO o una zona raíz comprometida. [5] .
A partir de octubre de 2013, hay 81 ccTLD y 13 dominios genéricos firmados por DNSSEC (sin IDN) en la zona raíz , lo que proporciona una cadena de confianza para los dominios de segundo nivel. En 2011, con la ayuda de DNSSEC (NSEC3 opt-out), se firmó la zona .su relacionada con Rusia y, a fines de octubre de 2012, comenzó la publicación de registros DS creados por los usuarios. [6] A finales de 2012, se firmó el dominio ruso .ru y sus registros DS se publicaron en la zona raíz [7] .
El 11 de octubre de 2018, se produjo la primera rotación de la KSK de la Zona Raíz desde la Firma de la Zona Raíz en 2010. La ICANN retrasó la rotación de claves, originalmente programada para octubre de 2017, cuando quedó claro que un número significativo (alrededor del 2 %) de los resolutores estaban utilizando la misma clave para la validación de la cadena de firmas DNSSEC. Durante el año se implementaron algunas soluciones técnicas en los paquetes de servidores Bind, PowerDNS, Knot y otros DNS, se realizó una campaña a gran escala para informar al público en general sobre la rotación de claves, y como resultado, en septiembre de 2018, la ICANN La Junta Directiva decidió implementar la rotación de claves. No hubo problemas significativos con la rotación de claves.
La implementación de DNSSEC se ha retrasado mucho por razones como:
La mayoría de estos problemas son resueltos por la comunidad técnica de Internet.
Las dos implementaciones de servidor DNS más comunes, BIND y NSD , admiten DNSSEC (10 de 13 servidores raíz usan BIND, los 3 restantes usan NSD). También hay soporte para PowerDNS , Unbound y algunos otros servidores DNS.
Debido al hecho de que había muy pocos servidores en los que se implementó la extensión DNSSEC, también se creó muy poco software de usuario final compatible con DNSSEC. Sin embargo, los sistemas operativos de Microsoft ya tienen integrado DNSSEC. En Windows Server 2008 - RFC 2535 , en Windows 7 y Windows Server 2008 R2 - la versión actual de DNSSEC-bis.
Windows XP y Windows Server 2003 son compatibles con RFC 2535 , pero solo pueden reconocer con éxito paquetes de servidores con DNSSEC, aquí es donde terminan sus capacidades.
Se hace mención especial al proyecto DNSSEC-Tools , que es un conjunto de aplicaciones, complementos y complementos que permite agregar soporte DNSSEC al navegador Firefox , cliente de correo Thunderbird , proftpd , servidores FTP ncftp y algunas otras aplicaciones. [8] .
El uso de DNSSEC requiere software tanto del lado del servidor como del cliente.
Protocolos TCP /IP básicos por capas del modelo OSI | |
---|---|
Físico | |
canalizado | |
la red | |
Transporte | |
sesión | |
Representación | |
Aplicado | |
Otro aplicado | |
Lista de puertos TCP y UDP |
de Seguridad en Internet | Mecanismos|||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Cifrado y filtrado de tráfico |
| ||||||||||||||
Autenticación | |||||||||||||||
Protección informática |
| ||||||||||||||
Seguridad Telefonía IP |
| ||||||||||||||
Anonimización del tráfico | |||||||||||||||
Seguridad inalámbrica |