Una de las funciones de un servidor DNS es traducir un nombre de dominio a una dirección IP que las aplicaciones necesitan para conectarse a un recurso de Internet, como un sitio web. Esta funcionalidad se define en varios estándares formales de Internet que definen el protocolo con considerable detalle. Los equipos y usuarios con acceso a Internet confían implícitamente en los servidores DNS para resolver correctamente los nombres en las direcciones reales registradas por los propietarios de un dominio de Internet.

Servidor DNS fraudulenteditar

Un servidor DNS fraudulento traduce nombres de dominio de sitios web deseables (motores de búsqueda, bancos, corredores, etc.).) en direcciones IP de sitios con contenido no deseado, incluso sitios web maliciosos. La mayoría de los usuarios dependen de servidores DNS asignados automáticamente por sus ISP. Los ordenadores zombis utilizan troyanos que cambian el DNS para cambiar de forma invisible la asignación automática del servidor DNS por parte del ISP a la asignación manual del servidor DNS desde servidores DNS falsos. Los servidores DNS asignados a un enrutador también se pueden alterar mediante la explotación remota de una vulnerabilidad dentro del firmware del enrutador. Cuando los usuarios intentan visitar sitios web, se les envía a un sitio web falso. Este ataque se denomina pharming. Si el sitio al que son redirigidos es un sitio web malicioso, que se hace pasar por un sitio web legítimo, con el fin de obtener información confidencial de forma fraudulenta, se denomina phishing.

Manipulación por ISPsEdit

Una serie de ISPs de consumo como AT&T, Optimum Online de Cablevision, CenturyLink, Cox Communications, RCN, Rogers, Charter Communications (Spectrum), Plusnet, Verizon, Sprint, T-Mobile US, Virgin Media, Frontier Communications, Bell Sympatico, Deutsche Telekom AG, Optus, Mediacom, Tal, TalkTalk, Bigpond (Telstra), TTNET, Türksat y Telkom Indonesia utilizan o utilizan el secuestro de DNS para sus propios fines, como mostrar anuncios o recopilar estadísticas. Los ISP holandeses XS4ALL y Ziggo usan secuestro de DNS por orden judicial: se les ordenó bloquear el acceso a The Pirate Bay y mostrar una página de advertencia en su lugar. Estas prácticas violan el estándar RFC para respuestas DNS (NXDOMAIN) y pueden abrir a los usuarios a ataques de scripting entre sitios.

La preocupación con el secuestro de DNS implica este secuestro de la respuesta NXDOMAIN. Las aplicaciones de Internet e intranet se basan en la respuesta NXDOMAIN para describir la condición en la que el DNS no tiene entrada para el host especificado. Si se consultara el nombre de dominio no válido (por ejemplo www.ejemplo.inválido), uno debería obtener una respuesta NXDOMAIN-informando a la aplicación que el nombre no es válido y tomando la acción apropiada (por ejemplo, mostrar un error o no intentar conectarse al servidor). Sin embargo, si se consulta el nombre de dominio en uno de estos ISP no compatibles, siempre se recibe una dirección IP falsa que pertenece al ISP. En un navegador web, este comportamiento puede ser molesto u ofensivo, ya que las conexiones a esta dirección IP muestran la página de redirección de ISP del proveedor, a veces con publicidad, en lugar de un mensaje de error adecuado. Sin embargo, otras aplicaciones que se basan en el error NXDOMAIN intentarán iniciar conexiones a esta dirección IP falsificada, exponiendo potencialmente información confidencial.

Ejemplos de funcionalidad que se rompe cuando un ISP secuestra DNS:

  • Las computadoras portátiles móviles que son miembros de un dominio de Windows Server se verán falsamente inducidas a creer que están de vuelta en una red corporativa porque parecerán estar disponibles recursos como controladores de dominio, servidores de correo electrónico y otra infraestructura. Por lo tanto, las aplicaciones intentarán iniciar conexiones a estos servidores corporativos, pero fallarán, lo que resultará en un rendimiento degradado, tráfico innecesario en la conexión a Internet y tiempos de espera.
  • Muchas redes pequeñas de oficinas y hogares no tienen su propio servidor DNS, sino que dependen de la resolución de nombres de difusión. Muchas versiones de Microsoft Windows priorizan de forma predeterminada la resolución de nombres DNS por encima de las transmisiones de resolución de nombres NetBIOS; por lo tanto, cuando un servidor DNS ISP devuelve una dirección IP (técnicamente válida) para el nombre del equipo deseado en la LAN, el equipo de conexión utiliza esta dirección IP incorrecta e inevitablemente no se conecta al equipo deseado en la LAN. Las soluciones alternativas incluyen usar la dirección IP correcta en lugar del nombre del equipo o cambiar el valor del registro DhcpNodeType para cambiar el orden del servicio de resolución de nombres.
  • Los navegadores como Firefox ya no tienen la funcionalidad de «Buscar Por nombre» (donde las palabras clave escritas en la barra de direcciones llevan a los usuarios al sitio coincidente más cercano).
  • El cliente DNS local integrado en los sistemas operativos modernos almacenará en caché los resultados de las búsquedas de DNS por razones de rendimiento. Si un cliente cambia entre una red doméstica y una VPN, las entradas falsas pueden permanecer en caché, lo que crea una interrupción del servicio en la conexión VPN.
  • Las soluciones antispam de DNSBL se basan en DNS; por lo tanto, los resultados de DNS falsos interfieren con su funcionamiento.
  • Los datos confidenciales del usuario pueden ser filtrados por aplicaciones engañadas por el ISP para que crean que los servidores a los que desean conectarse están disponibles.
  • La elección del usuario sobre qué motor de búsqueda consultar en caso de que una URL se escriba mal en un navegador se elimina a medida que el ISP determina qué resultados de búsqueda se muestran al usuario.
  • Los equipos configurados para usar un túnel dividido con una conexión VPN dejarán de funcionar porque los nombres de intranet que no se deben resolver fuera del túnel a través de Internet pública comenzarán a resolver a direcciones ficticias, en lugar de resolver correctamente a través del túnel VPN en un servidor DNS privado cuando se reciba una respuesta NXDOMAIN de Internet. Por ejemplo, un cliente de correo que intenta resolver el registro DNS A de un servidor de correo interno puede recibir una respuesta DNS falsa que lo dirigió a un servidor web de resultados de pago, con mensajes en cola para su entrega durante días mientras se intentaba retransmitir en vano.
  • Rompe el Protocolo de Detección automática de Proxy Web (WPAD) por parte de los principales navegadores web que creen incorrectamente que el ISP tiene un servidor proxy configurado.
  • Rompe el software de monitoreo. Por ejemplo, si uno se pone en contacto periódicamente con un servidor para determinar su estado, un monitor nunca verá un error a menos que intente verificar la clave criptográfica del servidor.

En algunos, pero no en la mayoría de los casos, los ISP proporcionan configuraciones configurables por el suscriptor para deshabilitar el secuestro de las respuestas de NXDOMAIN. Si se implementa correctamente, esta configuración revierte el DNS al comportamiento estándar. Otros ISP, sin embargo, en su lugar usan una cookie del navegador web para almacenar la preferencia. En este caso, el comportamiento subyacente no se resuelve: Las consultas de DNS se siguen redirigiendo, mientras que la página de redirección de ISP se reemplaza por una página de error de DNS falso. Las aplicaciones que no sean navegadores web no pueden excluirse del esquema utilizando cookies, ya que la exclusión solo se dirige al protocolo HTTP, cuando el esquema se implementa realmente en el sistema DNS neutral.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.