Source: https://mundoerrante.net/dns-el-servicio-mas-preciado-2/
Timestamp: 2020-01-17 23:53:39+00:00

Document:
DNS: el servicio más preciado ... - Mundo errante
febrero 22, 2009 en 1:20 am
Ha sido muy ilustrativo todo, los felicito en verdad.
Pero tengo un caso diferente y real (actual) que no he sabido resolver por mi falta de conocimientos.
Cuando el propio ‘dealer’ establece la conexión con el servidor de Internet satelital, y configura el DNS a su conveniencia, de esta forma, el sistema le reporta directamente de todos los procesos y hasta le permite modificarlos.
¿cómo se soluciona un caso así? si se me permite preguntar
octubre 8, 2008 en 4:06 am
Blog de Juan Galiana » Multitud de implementaciones de DNS vulnerables a ataques de envenenamiento de caché
julio 10, 2008 en 9:47 pm
[…] Y es que DNS no fué un protocolo pensado en la seguridad… una solución sería DNSSEC, al igual que el protocolo SMTP se creó del mismo modo y más tarde surgieron las extensiones (ESMTP). Sobre si DNS es seguro, DNSSEC y la viabilidad de implantación se habló en el blog de administración de redes. […]
Este procedimiento consiste en acceder a IP’s de la LAN en busca del router (van probando las ips más típicas como 192.168.1.1) una posible solución sería que los navegadores incluyeran una protección mediante la cual no fuera posible incluir direcciones que pertenecen a redes privadas locales desde sitios externos (o que alertaran de ello), ya que actualmente ninguno lo hace.
noviembre 26, 2007 en 12:49 pm
Como iba comentando normalmente cuando alguien realiza un ataque de este tipo hasta ahora su objetivo era la máquina local en la cual navega el usuario, pero hispasec alertaba hace poco de un nuevo ataque de Phising o Pharming (realmente se usan los dos), con uno se consige cambiar la resolución de nombres y luego se utilizan páginas con aspecto similar en esas resoluciones cambiadas para robar datos.
El tema es que ahora el objetivo también son los routers ADSL, ya leí algo sobre esto hace tiempo, código ejecutado en el navegador del usuario que aprovechan las passwords por defectos de los routers para intentar modificar ciertos parámetros (en nuestro caso los DNS), pero al parecer es que algunos routers permiten ataques Cross-site request forgery (CSRF), es decir aprovechan sesiones autenticadas o debido a un fallo esta sesión no es imprescindible (bien porque no tenga password o simplemente por un bug) y permiten cambiar los DNS.
De esta manera son varios los inconvenientes para un usuario y varias las ventajas para un atacante, en primer lugar ya no solo se modifican las DNS de una máquina sino de toda la red, por otro lado se rompe la barrera del navegador usado e incluso el sistema operativo.
En concreto los routers afectados son de la marca 2wire, modelos 1701HG, 1800HW, y 2071 Gateway routers, con 3.17.5, 3.7.1, y 5.29.51 software.
«Cross-site request forgery (CSRF) vulnerability in /xslt in 2wire 1701HG, 1800HW, and 2071 Gateway routers, with 3.17.5, 3.7.1, and 5.29.51 software, allows remote attackers to create DNS mappings as administrators, and conduct DNS poisoning attacks, via the NAME and ADDR parameters.»
Ultimamente hay que llevar mucho cuidado, y no solo con tu máquina!
Os dejo aqui los enlaces donde lo comentan, incluso con capturas del código que realiza los cambios en el router (simplemente metido en el campo src de etiquetas img)
http://www.hispasec.com/unaaldia/3313
noviembre 26, 2007 en 12:40 pm
Normalmente cuando hablamos de Pharming o modificación de los DNS del cliente se tratan con virus que infectan la máquina local.
Es el caso de OSX.RSPlug.A un troyano para Mac OS X el cual cambia la configuración de los DNS para que todas las consultas se hagan a servidores en manos de los dueños del troyano, permitiendo que el usuario sea redirigido a sitios distintos a los reales para realizar ataques de phising copiando webs bancarias y llevar a cabo el robo de credenciales.
Hay que decir que el troyano necesita de la participación activa del usuario para instalarse, aunque mucho cuidado a los usuarios de Safari si tienen activado la opción de «Abrir los ficheros seguros automáticamente» ya que viene en formato DMG.
Os dejo aqui unos enlaces donde discuten el tema, e información detallada del troyano.
http://www.quands.cat/wp/2007/11/01/osxrspluga-troia-per-a-mac-os-x/
Juan Carlos Moral Mena
noviembre 24, 2007 en 10:36 pm
Esta vez he tardado mucho en escribir el mensaje 🙂
Aunque ya se ha escrito mucho sobre DNS en esta entrada, me gustaría advertiros de la potencia de lo que conlleva hackear un servidor DNS, podríamos conseguir que todo el que se conecte a la página de la guardia civil se le redirija a otro sitio que queramos. Imaginaros el caos que esto supondría…
Os voy a comentar algunas técnicas más que creo que no se han comentado, si no es así, sorry 😉
– Ejecución de código homebrew a través del servicio RPC:
Este fallo de seguridad afecta a las versiones «server» de windows, aprovecha un fallo de seguridad en el Remote Procedure Call de la máquina. El exploit consiste en enviar una petición malformada que terminará en un overflow que devolverá una shell con permisos de root.
La solución es desactivar el RPC remoto en servidores DNS, (cambiando una clave del registro) o bloquear el tráfico entre los puertos 1024 y 5000.
-Remote DoS q_useDNS:
Este fallo utiliza el array en el que se registran los nameservers, aunque no es un fallo demasiado importante puede provocar la caída del servicio.
La solución para este y para bastantes otros problemas relacionados con DNS es desactivar la recursión.
Se ha hablado mucho verbalmente de como se hacen los ataques, pero aquí voy a poner un código de un exploit real que se aprovecha de la primera vulnerabilidad que comenté. Si estáis interesados en el tema podéis descargaros el exploit en c en esta dirección. Aclarar lo que todos ya sabeis, este codigo se usa con fines educativos 🙂
http://www.hispasec.org
noviembre 21, 2007 en 4:37 pm
Como respuesta a los problemas de seguridad de BIND, se diseñó y, actualmente aunque parezca mentira, es muy usado, el software djbdns.
Es modular, lo que permite que se ejecute sólo las partes que necesitemos y que coexista con BIND.
Mejora, como hemos dicho, la seguridad, pero también en rendimiento y eficiencia al BIND [1]. Sin embargo, no implementa todos los RFC [1] (página 243). Es muy interesante ya que proporciona, además: integridad (mediante ssh y rsync), por defecto sus procesos no se ejecutan como root (y dentro de una jaula).
[1] Seguridad en servidores Linux. Editorial O’Reilly. Autor: Michael D. Bauer.
noviembre 20, 2007 en 3:35 pm
Creo que no se ha mencionado el ataque dns amplification variante que como ataques de negación de servicio pretenden sobrecargr las redes y servidores.
**DNS Amplification**
y consiste en que el atacante envía una alta cantidad de peticiones con una dirección IP falsificada (spoof) al DNS que permite recursión, el DNS procesa estas peticiones como si éstas fueran válidas mandando una respuesta al sistema al cual se quiere atacar, es decir al sistema víctima. Cuando estas peticiones alcanzan un volumen importante pueden inundar al sistema víctima de repuestas del DNS a las peticiones que se le realizan. Este ataque es llevado a cabo gracias a errores en la configuración del DNS y es llamado amplification puesto que los DNS al reflejar el ataque, potencian el nivel de éste hacia un blanco en especifico a causa de que las respuestas del servidor de nombres son de un tamaño considerablemente mayor que las peticiones que se le realizan causando con esto, en ocasiones, la caída del servicio y con ello la negación del mismo.
Configurar los servidores DNS de tal manera que sólo se permitan las consultas recursivas a una cantidad limitada de hosts a los que se tiene confianza o, en el caso de ser un DNS que no tiene ningún dominio al cual permitirle consultas recursivas, bloquear la recursión por completo. A continuación se proveen algunos ejemplos de configuracion donde se elimina o se limita la recursion.
http://listas.seguridad.unam.mx/pipermail/mx-seguridad/2006-March/002780.html
http://foros.hackerss.com/index.php?showtopic=141&st=20
http://www.seguridad.unam.mx/labsec/tuto/?id=181&ap=articulo&cabecera=22
http://www.cert.org.mx/nota/?vulne=5077
noviembre 20, 2007 en 12:58 pm
Perdon por comentar lo mismo dos veces, jeje No me aparecian los dos primeros comentarios 😀
noviembre 20, 2007 en 12:55 pm
Segun he leido los inconvenientes del dnssec serian su aumento de comlejidad y tamaño. Es decir:
Habria una disminucion de las prestaciones debido al aumento del tamaño de los ficheros y de las bases de datos en los servidores.
Como es logico, aumentaria de igual manera el tamaño de los mensajes y el numero de estos. Tambien esto seria causado por la aparicion de nuevos registros (DNSKEY, RRSIG).
Se usará frecuentemente TCP en vez de UDP. Y se tendran que hacer consultas adicionales para obtener las claves de dominios superiores necesarias para la comunicacion.
Todo esto conllevara un aumento de los retardos por el trabajo de la validacion de los datos.
A demas, la complejidad sera superior al clasico dns por la dificultad en crear la cadena de confianza (base del dnssec), verificar firmas y validar claves
noviembre 19, 2007 en 11:22 pm
Tambien he visto otro tipo de ataque a los dns, no se si sera correcto:
Las mafias se han dado cuenta de esto y han diseñado ataques que básicamente anulan este servicio. ¿Cómo? Muy fácil. Lanzan miles de consultas por segundo a los DNS de la entidad financiera, con nombres aleatorios e inexistentes. Con ello logran colapsar y derribar el servicio DNS.
Hasta ahora, los ataques de este tipo que he visto generan paquetes con el mismo identificador de Query (número de petición aleatorio DNS, para cachear las contestaciones y que no puedan ser mezcladas/falsificadas/confundidas con otras queries), pero es cuestión de tiempo que el identificador se genere aleatorio también.
Las soluciones a este tipo de ataques son muy limitadas, al menos de momento. Si no se usa el DNS y se opta por resolver el nombre de las máquinas de la entidad financiera en local (haría falta la distribución de un software específico que modificase el windowssystem32driversetchosts a los usuarios inexpertos), la entidad financiera perderá la flexibilidad que le otorga el DNS.
Sin embargo, esta solución se perfila como la única viable. Claro que, para ser realmente eficaz, ha de ser implantada antes de sufrir el ataque, ya que si no, después será terriblemente costoso.
http://multingles.net/docs/seguratas/dos.html
Basicamente segun he leido las grandes desventajas del DNSEC se centran en la disminucion de las prestaciones con respecto al DNS tradicional. Ya que deberan aumentar el tamaño de los ficheros y de las bases de datos en los servidores, por lo que los mensajes q se transmitiran tambien seran de mayor tamaño y habra mas, ya que contendran registros DNSKEY y RRSIG.
Aumentaran las consultas ya que se tendran que hacer consultas adicionales para obtener claves de dominio superiores.
Y se usara frecuentemente tcp en vez de el udp tradicional.
Habra mayores retardos causados por la validacion de datos,
A demas de todo esto se sumara la dificultad de establecer una red de confianza, es decir, la base del funcionamiento de dnssec
noviembre 19, 2007 en 9:26 pm
Bueno, yo voy a comentar el ataque DDoS que han mencionado arriba y una de sus variantes: DRDoS.
Inutilización del servidor.
El DDoS, como bien se ha mencionado, consiste en un ataque de inundación (flood) que persigue colapsar la capacidad de atención de paquetes del equipo víctima. Mientras que el DoS consiste generalmente en hacer que quede inutilizada de varias formas, como la inundación, la explotación de vulnerabilidades, etc.; tenemos que DDoS se centra en la inundación, pero con la diferencia de que se realiza desde un gran número de máquinas en lugar de una.
Las máquinas son controladas mediante algún software malicioso que permita su uso para el ataque, que habrá sido extendido anteriormente de alguna forma. Lo importante para el ataque es, sobre todo, que las máquinas esclavo estén muy distribuidas, pues su flujo de paquetes podrá superar las barreras de los routers intermedios, algo que no ocurriría si la mayoría de las máquinas pertenece, por ejemplo, a una misma red.
Tenemos, por tanto, que a la orden del atacante, todas las máquinas realizarán un envío de paquetes (peticiones DNS, por ejemplo) de forma sincronizada hacia el equipo víctima, el cual llegará a tener colapsada su cola de peticiones DNS a atender y pasará a descartar las peticiones que reciba en adelante.
El ataque DRDoS (Distributed Reflection DoS) es un ataque DDoS que se realiza aprovechando las respuestas de muchos servidores TCP a un paquete SYN falsificado. Concretamente, enviamos paquetes SYN a los que les hemos cambiado la dirección IP origen por la del equipo víctima, así, el servidor TCP responderá con un SYN/ACK a la víctima, en vez de a nosotros. Aquí, la clave es generar los paquetes SYN falsificados y enviarlos a gran cantidad de routers para que dejen sin ancho de banda a la víctima con sus respuestas.
Como ejemplos de DDoS ocurridos sobre los servidores DNS raíz, cabe mencionar:
-Ataque del 22 de octubre de 2002. El ataque duró 1 hora aproximadamente y quedaron inutililzados 9 servidores DNS raíz de los 13 existentes en todo el mundo. Pretendía bloquear Internet y lo cierto es que estuvo cerca de conseguirlo.
-Ataque del 7 de febrero de 2007. Duró unas 5 horas. Ninguno de los servidores llegó a caer, pero 2 presentaron una congestión casi letal, mientras que el resto un estado de alto tráfico.
noviembre 19, 2007 en 8:39 pm
bueno quitare sentencias que parece que no permite subir(si quereis verlas ir al enlace)….
En este ejemplo se le preguntó al servidor DNS del dominio aeromexico.com si tenía en su un registro A (dirección IP) para el dominio http://www.terra.es, en la respuesta del servidor DNS, «alguién» utilizó este servidor en el pasado para resolver el nombre de dominio http://www.terra.es
Dependiendo de cómo esté configurado el servidor DNS y si éste permite queries recursivos o no a todo aquel que lo utilice, no podemos saber si este «alguién» fue un usuario propio de Aeroméxico o si fue un usuario «externo» que tiene configurado su cliente de DNS (su DNS resolver) con la dirección IP del servidor DNS de Aeroméxico.
Es más, por lo que se ve en la respuesta, a este registro le quedan más o menos 11,992 segundos antes de que expire en la cache. Si asumimos que el TTL para el registro de http://www.terra.es es de 28,800 , podemos incluso deducir que la primera vez que alguién utilizó el servidor de DNS de aeromexico.com para resolver el nombre de http://www.terra.es, fue hace aproximadamente 4.66 hrs.
Con lo cual si un servidor DNS esta afectado por el DNS cache snooping, entonces técnicamente cualquiera desde Internet puede hacer un profile de los nombres de dominios que son más frecuentados por la comunidad de este servidor. Esta información se puede utilizar para fines de mercado o quizás para fines más oscuros.
Una utilidad todavía mayor, es precisamente la que Dan Kaminsky de Doxpara le está dando en su proyecto Deluvian. Básicamente su línea de razonamiento va de la siguiente manera:
– Muchos virus, troyanos y malware en general «llaman a casa» una vez instalados.
_ Para «llamar a casa», necesitan resolver un nombre de dominio.
– La resolución de este nombre de dominio queda en el cache del servidor DNS utilizado.
– Si es posible aplicar la técnica de «Caché Snooping» a todos los servidores DNS que existen en Internet sería posible detectar todos aquellos DNS que existen en el mundo los cuales han sido utilizados por este malware
– Si se tienen geo-localizados a todos estos servidores DNS entonces es posible hacer mapas que indiquen las zonas geográficas afectadas (asumiendo que los servidores DNS están más cerca de la comunidad de usuarios que los utilizan, cosa que sabemos no necesariamente es siempre así)
En fin que para solucionar este problema los expertos recomiendan:
– Separar los DNS que su utilizados por los usuarios «internos» de una organización y aquellos que son utilizados para que todo el mundo pueda resolver dominios para los cuáles sean autoritarios
– Configurar a los DNS para que no respondan a queries para los cuales nos sean autoritativos
– Limitar con ACL’s del propio DNS en cuestiónlas IPs que pueden resolver recursivamente
enlaces: http://osinfra.blogspot.com/2006/01/seguridad-dns-cache-snooping.html
http://www.sysvalue.com/papers/DNS-Cache-Snooping/files/DNS_Cache_Snooping_1.1.pdf
continuo con mi mensaje porque ayer no me dejo subirlo bien…
->>HEADER
noviembre 19, 2007 en 11:11 am
Vamos a comentar los objetivos y algunos tipos de ataque cuando se usa la técnica de DNS Caché Poisoning, comentada por Juan Galiana (#3).
Un atacante hace uso del Cache Poisoning para una de dos razones. La primera es una Negación de Servicio (DoS), como se ha comentado en #5, y la otra es enmascararse como una entidad de confianza.
Fuente consultada: http://www.seguridad.unam.mx/labsec/tuto/?id=133&ap=articulo&cabecera=2
noviembre 19, 2007 en 1:15 am
He encontrado un articulo que hace referencia a un tipo de ataque que creo que aun no se ha hablado de él, es el llamado: «DNS Cache Snooping», se trata de una técnica que permite conocer qué nombres de dominio han sido resueltos por la comunidad de usuarios que utiliza al servidor DNS en cuestión.
La técnica básicamente consiste en hacer una query a un servidor DNS para un nombre de dominio para el cual éste no sea autoritativo. La clave está en que esta query no tiene que ser recursivo para obtener solamente la información que se encuentra en la cache del servidor DNS.
Si el servidor DNS devuelve una respuesta válida podemos asumir que «alguien» en el pasado (tan atrás «en el pasado» como el TTL del registro en el servidor DNS haya establecido) utilizó este servidor DNS para resolver el nombre de dominio en cuestión
En el ejemplo siguiente que se cita:
[[email protected] ~]# dig @ns.aeromexico.com.mx http://www.terra.es +norecurse
; > DiG 9.3.1 > @ns.aeromexico.com.mx http://www.terra.es +norecurse
noviembre 17, 2007 en 9:15 pm
La mayoría de usuarios confían en el sistema de nombres de dominio de la Internet, que conduce a partir de nombres fáciles de recordar a direcciones IP (Protocolo de Internet), y esperan ser bien conducidos la web que han ingresado en un buscador, q le remite un correo electrónico etc….
Desafortunadamente, eso no siempre ocurre a causa de las vulnerabilidades d DNS y para ello como comentais arribe surge dnssec
La extensión DNSSEC legaliza la información del DNS y garantiza que este la información es auténtica y completa.Produciendo asi una correcta identificación y recepcion hasta los servidores raiz.
*Repercusiones DNSSEC en phising spoofing…
Bueno Las repercusiones de este sistema de seguridad tendria sobre
estos sistemas seria la deshabilitacion en gran parte de ellos sobre todo en los casos de phising spoofing ya que al tener certificado un dominio dificilmente el sistemas podria conducirnos a un sitio fraudulento sin que nos dieramos cuenta de ello.
*Estado d dnssec y próximos pasos
El Registro Nacional Sueco (.SE) se convirtió en el primer dominio de máximo nivel (TLD) que desplegó el protocolo en septiembre de 2005. La organización de servicios de infraestructura europea, RIPE NCC, también ha comenzado a desplegar DNSSEC en sus zonas, y .AERO, un TLD patrocinado en el sector de servicios de transporte para la aviación con sede en Ginebra, ha anunciado planes para hacerlo también. El grado de interés es alto
Desde el punto de vista de la organización, los gastos indirectos operativos pueden probablemente ser absorbidos dentro de los marcos de organización existentes. Sin embargo, el protocolo sí acarrea nuevos procedimientos y puede causar una desorganización temporal. Quienes lo han adoptado tempranamente observan, no obstante, que el despliegue puede introducirse a través del ciclo natural de “upgrading” y ofrece una oportunidad para racionalizar sistemas ad hoc que en ocasiones son heredados.
*El depliegue se esta viendo afectado por diversas razones prinvcipalmente y es algo logico por los contes que acarrearia la implantacion y la segunda razon los denominados costes de migracion (como casi todo en la informatica ) a pesar de que el sistema DNS actual no es del todo caotico.
http://ww2.grn.es/merce/2002/dns.html
http://www.citel.oas.org/newsletter/2006/agosto/dns_e.asp
http://www.dnssec.org.mx/?q=node/12(articulo interesante donde compara la seguridad de DNS con mercados de primera y segunda clase y propone solucion basade en dnssec).
Para proporcionar una seguridad adecuada a un servidor DNS se precisan dos mecanismos: firmar los datos (para proporcionar
integridad y autenticidad de datos) y autentificar a las partes implicadas. La integridad asegura que una información recibida no ha sido modificada en el camino. Este primer mecanismo es ofrecido por DNSSEC.
El segundo mecanismo trata de asegurar a un host que el otro es quien dice ser. Este aspecto de autenticidad de datos no lo contempla directamente DNSSEC. Por lo que será necesario servirse de ciertos protocolos como TSIG, SIG(0) e IPSec para ofrecer una seguridad de DNS más completa capaz de autentificar las comunicaciones entre servidores mediante actualizaciones
dinámicas y transferencias de zonas.
http://www.saulo.net/des/DNSSEC-pre.pdf
Aquí os dejo un resumen de los protocolos que usaríamos para asegurar la autenticidad de las comunicaciones entre los servidores:
Las TSIG se usan para asegurar que la información del DNS que pretende provenir de cierto servidor es realmente de ese servidor. Añaden las firmas criptográficas como método de autenticación en una conversación del DNS, que consisten en usar una clave secreta compartida para establecer la confianza entre las partes involucradas.
http://www.wikilearning.com/que_es_una_tsig_y_para_que_se_necesita-wkccp-597-10.htm
IPSec es un conjunto de protocolos cuya función es asegurar las comunicaciones sobre el Protocolo de Internet (IP) autenticando y/o cifrando cada paquete IP en un flujo de datos.
noviembre 16, 2007 en 4:06 pm
El DNSSEC ha sido ideado para brindar proteccion contra ataques de tipo spoofing al DNS(comportamiento por defecto del explorador web)este se diferencia de una infraestructura publica tradicional (PKI), en que el protocolo no utiliza certificados, el directorio es descentralizado y l aautenticacion se basa en autoridades subdivididas y delegadas.
Windows server 2003, permite que los servidores DNS actuen como servidores DNS secundarios para las zonas seguras existentes permitiendo la compatibilidad con DNSSEC.
Creo que uno de los principales problemas puede ser la compatibilidad en servidor, cuando un servidor DNS recibe una propuesta o consulta que contiene registros de recursos DNSSEC, «no comprueba las firmas digitales», sino que almacena en cache la respuesta y la usa para emitir consultas. Cuando el servidor recibe una consulta de un registro en una zona donde tmbien tiene recursos de DNSSEC, el servidor adjunta estos recursos para elaborar esta respuesta.
Cuando una propuesta contiene registros DNSSEC, garantiza que es totalmente segura?
Inés Martínez Cerda
noviembre 16, 2007 en 1:19 pm
Aquí http://www.saulo.net/des/DNSSEC-pre.pdf aparece otro problema de DNSSEC
«DNSSEC tiene algunos problemas operacionales basados en la transmisión de claves
públicas. ¿Cómo enviar la clave ZSK a la zona padre de forma segura? ¿cómo sabe la
zona padre que esa clave se la está enviando realmente su zona delegada? En el caso de
los resolvers, ¿cómo saben que la clave que configuran localmente es realmente una clave
de confianza correcta y no la de un suplantador?»
noviembre 15, 2007 en 7:18 pm
según mencionan en » http://ww2.grn.es/merce/2002/dns.html » el problema que tiene dnssec es el mismo que tiene IPv6: el elevado coste que supone la migración de la tecnología convencional a la moderna (DNSSEC y IPv6). Y en cuanto a vulnerabilidades y problemas que tenga el DNSSEC en http://docs.nicmxlabs.org.mx/dnssec/DNSSEC-trial-Mexico-LACTLD-LACNICIX.pdf
he encontrado algo de información a partir de la página 30 (RETOS) en donde se presentan los problemas.
(he sido yo el que tenía problemas para postear)
noviembre 15, 2007 en 7:16 pm
Hola, tengo problemas para postear. He enviado una tutoría a JUAN ANTONIO. Gracias, un saludo.
Jose Vte Ramos Llinares
noviembre 15, 2007 en 3:20 pm
Según los expertos, el problema no son los servidores raíz sino la misma base del sistema, el protocolo DNS está obsoleto y plagado de fallos, que conecta a millones de servidores de nombres de todo el mundo.
Las extensiones de seguridad realizadas a DNS en DNSSEC (RFC 2535) ofrecen servicios para realizar la autenticación de origen de datos y la comprobación de integridad. Estos servicios permiten cifrar firmas digitales utilizando claves privadas y enviarlas como registros de recursos desde servidores DNS que alojen zonas firmadas (compatibles con DNSSEC) a interpretadores en los que se puedan autenticar los registros de recursos utilizando claves públicas. Tanto las firmas digitales como las claves públicas se agregan a una zona firmada en forma de registros de recursos.
Es importante observar que las extensiones DNSSEC no pretenden proteger un servidor DNS frente a problemas de seguridad, sino que se utilizan como método para la protección de los datos de nombre de dominio enviados utilizando DNS. Tanto las claves privadas como las públicas están asociadas a zonas específicas y no a los servidores DNS que alojen dichas zonas. Si se infringe la seguridad de los servidores DNS que albergan dichas zonas, la capacidad de los interpretadores para autenticar los registros de recursos de dichas zonas permanecerá intacta y segura.
Este nuevo protocolo (DNSSEC) acabaría con estos problemas. Pero, DNSSEC no consigue despegar, igual que IPv6 y otros protocolos modernos, porqué suelen ser más costosos en términos de recursos. Además, los viejos no funcionan tan mal y hay tantos millones de máquinas que el coste de la migración sería brutal.
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/es/library/ServerHelp/22c89608-248f-43a4-974f-a0437b1db37d.mspx?mfr=true
noviembre 15, 2007 en 3:01 pm
http://www.cnc.una.py/cms/invest/download.php?id=407240,54,1
http://www.saulo.net/redir.php?cod=descarga&url=DNSSEC-pre.pdf
http://greco.dit.upm.es/~encarna/doctorado/0203/trabajos/dnssec_DLopez.ppt
noviembre 15, 2007 en 2:57 pm
DNSSEC son unas extensiones de seguridad para el protocolo actual DNS creado como respuesta ante los fallos de seguridad encontrados en este sistema tan crítico, está basado en una infrastructura para conseguir la autenticación de servicios basada en clave pública (RSA/DSA).
Su especificación se puede encontrar en el RFC2535, aunque la nueva especificación revisada por el IETF se encuentra en los RFCs 4033-4035, y está compuesto por varios componentes que ofrecen diferentes caracteristicas:
Por un lado tenemos la protección entre servidores (master -> slave) es lo que se conoce como DNSSEC (TSIG/SIG0), y permite la autenticación entre servidores para asegurar las transferencias de zona.
Por otro lado tenemos la protección e integridad de los datos, el componente DNSSEC (KEY/SIG/NXT) para autenticación e integridad y DNSSEC DS (Delegation Signing) permite crear redes de confianza.
Estas extensiones se han creado como respuesta a comprobar la integridad de los datos y detener el spoofing de direcciones, pero no cubre otros problemas como desbordamientos de buffer o ataques DDoS.
Es soportado en las últimas versiones de bind y existen aplicaciones específicas como dnssec-tools.
Uno de los mayores problemas será la mayor complejidad administrativa que acarrea implementar estas extensiones y la viabilidad en cuanto al despliegue en los root servers.
Surgen varias preguntas de todo esto…
Creeis que es posible que desplieguen DNSSEC en los servidores raiz? que implicaciones tendría para problemas cotidianos hoy día como el spoofing o el spam? por qué razones se está retrasando este despliegue?
noviembre 15, 2007 en 2:16 pm
DNSSEC no proporciona confidencialidad de datos ni tampoco protege de los ataques DDoS, además es difícil de implementar(se han de crear registros y procedimientos), aun así DNSSEC sigue siendo la apuesta con más futuro para la protección de datos.
Fragmento extraído de la página de Microsoft sobre como actúa el DNSSEC:
En DNSSEC, cada zona tiene su propia clave pública y privada utilizada para cifrar y descifrar firmas digitales. Una zona cifrada o segura es una zona DNS que tiene tanto clave privada como pública. Cuando un conjunto de registros de recursos (RRset) de una zona está firmado con una clave privada, los interpretadores que contienen la clave pública de la zona puede autenticar si un RRset recibido de la zona está autorizado.
Al utilizar la clave privada de la zona para firmar cada RRset de la zona, cada nombre de dominio de la zona, como widgets.microsoft.com, tiene una clave privada. La firma digital de dicho RRset se agrega a la zona como un nuevo registro de recursos, SIG. Cuando un servidor DNS responde positivamente a una consulta de un nombre DNS, contesta con los registros de recursos solicitados y el registro de recursos SIG que corresponde a dicho nombre. Los interpretadores que conozcan la clave pública asociada al nombre solicitado reciben el registro de recurso SIG y utilizan la clave pública para autenticar los registros de recursos. La clave pública de la zona se almacena en un nuevo tipo de registro de recursos, KEY. Se deben proporcionar los registros de recursos KEY al interpretador antes de que este pueda autenticar registros de recursos SIG.
DNSSEC verifica con un interpretador que los registros recibidos desde una zona segura realmente procedan de la zona correcta. Con DNSSEC, el interpretador comprueba que la dirección IP del dominio widgets.microsoft.com realmente haya llegado de la única zona de widgets.microsoft.com válida.
http://www.dnssec.org.mx
http://www.dnssec.net (ingles)
noviembre 15, 2007 en 1:22 pm
Buenas para empezar voy a poner un video que he encontrado bastante interesante con respecto a este tema:
Yo voy a hablar de «Ataque DNS ID Hacking»
El DNS ID Hacking no es una forma usual de hacking/spoofing o cualquier otro. Este método se basa en una vulnerabilidad en protocolo del DNS. Más eficaz, el DNS ID hack/spoof es muy eficiente y muy fuerte porque no hay generación de demonios de DNS que se escape de ella (incluso WinNT).
Paquete DNS.
Abajo se muestra el formato de un mensaje DNS:
| ID | Banderas |
| Número de preguntas | Número de respuestas |
| Número de RR autoritarios | Número de RR suplementario |
Etc… NO IMPORTA
1 ID: El ID permite identificar cada paquete DNS.
2 Banderas:[QR | opcode | AA| TC| RD| RA | zero | rcode ] –>QR: Si el bit QR = 0, significa que el paquete es una pregunta, si no es una respuesta.
DNS ID Hack/Spoof.
Ahora vamos a explicar claramente que es DNS ID hacking/spoofing. Como se explicó antes, la única manera para que el demonio DNS reconozca las diferentes preguntas/respuestas es la bandera en el paquete. Obsérvese este ejemplo:
ns.prueba.com;53 —–>[?www.pagina.com] ——> ns.pagina.com:53
Solamente tenemos que engañar la IP de ns.pagina.com y contestar información falsa antes de que ns.pagina.com lo haga a ns.prueba.com
ns.prueba.com > Oct 06 El 05:18:12 ADM named[1913 ]: db_free: DB_F_ACTIVE set – ABORT at this
time named daemon is out of order.
4. O podemos utilizar la vulnerabilidad en las versiones 8.1.x, 4.9.3, 4.9.5 y 4.9.6 de BIND descubierta por SNI (Secure Networks, Inc.) con la predicción del ID.
Vulnerabilidad de BIND.
Esta es una vulnerabilidad en BIND (descubierta por SNI). De hecho, el DNS es fácilmente predecible, tenemos que escuchar sólamente un DNS en orden para hacer lo que deseemos. El DNS utiliza un ID al azar en el principio pero sólamente aumenta para las preguntas siguientes. Es fácil explotar esta vulnerabilidad. Abajo se muestra la forma:
1. Puede escuchar fácilmente los mensajes que viene a un DNS al azar (ns.ejemplo.com para este ejemplo).
2. Preguntamos NS.victima.com para resolver (aleatorio).ejemplo.com. NS.victima.com pedirá a ns.ejemplo.com resolver (aleatorio).ejemplo.com
ns.victima.com –> [?(aleatorio).ejemplo.com ID = 444 ] –> ns.ejemplo.com
3. Ahora tenemos el ID del mensaje de NS.victima.com, y sabemos qué rango ID tendremos que utilizar. (ID = 444 en este ejemplo).
4. Entonces hacemos una petición de resolución por ejemplo a http://www.microsoft.com para NS.victima.com
(Nosotros) –> [?www.microsoft.com ] –> ns.victima.com
nc.victima.com –> [?www.microsoft.com ID = 446 ] –> ns.microsoft.com
5. Inundamos el servidor de nombres ns.victima.com con el ID (444) que tenemos y entonces lo aumentamos.
ns.microsoft.com –> [www.microsoft.com = 1.1.1.1 ID = 444] –> ns.victima.com
ns.microsoft.com –> [www.microsoft.com = 1.1.1.1 ID = 445] –> ns.victima.com
ns.microsoft.com –> [www.microsoft.com = 1.1.1.1 ID = 446] –> ns.victima.com
ns.microsoft.com –> [www.microsoft.com = 1.1.1.1 ID = 447] –> ns.victima.com
ns.microsoft.com –> [www.microsoft.com = 1.1.1.1 ID = 448] –> ns.victima.com
ns.microsoft.com –> [www.microsoft.com = 1.1.1.1 ID = 449] –> ns.victima.com
(Ahora sabemos que los ID’s son predecibles, y aumentan solamente. Inundamos ns.victim.com con respuestas engañosas con ID 444+. Las versiones de 8.3.4, 4.9.11 y las recientes 8.2.x y 9.x de BIND no son vulnerables a este tipo de ataque.)
http://www.seguridad.unam.mx/labsec/tuto/?id=134&ap=articulo&cabecera=2
noviembre 15, 2007 en 12:23 pm
Según mencionan en » http://ww2.grn.es/merce/2002/dns.html » el problema que tiene dnssec es el mismo que tiene IPv6: el elevado coste que supone la migración de la tecnología convencional a la moderna (DNSSEC y IPv6). En cuanto a vulnerabilidades de DNSSEC no he encontrado nada hasta ahora.
noviembre 15, 2007 en 11:56 am
Buenas, he encontrado esta noticia sobre un ataque que tiene que ver con el tema del DNS.He copiado lo más importante; dejo el link de la página para mas información.
La Oficina Federal de Investigaciones (FBI) estadounidense investiga el origen de un ataque a gran escala que afectó hace dos días a nueve de los 13 ordenadores que controlan el tráfico global de Internet, pero que duró sólo una hora y no tuvo graves consecuencias.
Las autoridades estadounidenses que investigan el incidente han descrito este ataque como «el mayor y más sofisticado en la historia de la Red», a pesar de que la mayoría de los usuarios individuales no se percataron, ya que duró solamente una hora.
Estos 13 súper servidores están diseminados por el mundo, como una precaución contra un desastre físico (entre otros lugares, están en los estados de Maryland, Virginia, California y Texas, y en ciudades como Estocolmo o Tokio), lo que contribuyó a evitar que el incidente fuera a más.
Los expertos informáticos consideran que el Sistema de los Nombres de Dominio (DNS o «Domain Name System» en inglés) y los servidores en los que se apoya este sistema son el talón de Aquiles de la Red.
Unos 4.000 ataques de «denegación de servicio» ocurren cada semana como media, y la mayoría de ellos están dirigidos contra los servidores de DNS.
http://www.elmundo.es/navegante/2002/10/24/seguridad/1035450013.html
noviembre 15, 2007 en 12:51 am
#1 (Alfonso) propone DNS Spoofing
#2 (Yolanda) propone DNS Inject
#3 (Juan) propone DNS Cache Poisoning
# 4 )I. Martínez) propone pharming
#5 (María José) propone DoS
#7 (Antonio) proporne DNS Footprinting
#8 (Victor) propone DDoS
#9 (Armando) proporne DNS ID Hacking
#11 (Samuel) los ataques que propones no son típicamente del DNS, aunque sí que le afectan
#12 (Victor M) correspondencia de red más DNS Footprinting
Existen acciones muy fáciles, no se aprovechan de errores del protocolo, pero sí de cómo éste funciona para obtener información de un posible objetivo y después…
Desde el punto de vista de la administración el objetivo es comprender cómo se puede usar esta información y actuemos en consecuencia cuando proporcionamos esta información.
¿A qué me refiero? Los Networks INformation Center (NIC) guardan información muy útil en los WHOIS: Nombres de contacto de la empresa, dominio, correos, teléfono de contacto,…
También, como hemos visto en clase, porque permitimos consultas o transferencias de zona a quien no se debe, con lo que todo esto puede conllevar.
Otro tipos de errores que pueden afectar al DNS son las vulnerabilidades de programación (existen documentadas en función de la versión de BIND)
A partir de ahora, ¿comentemos las propuestas realizadas? ¿Pensáis que con sólo DNSSEC se resuelven todos los problemas? ¿Qué problemas nos encontraríamos en la implantación de DNSSEC?
Intentemos resumir y que las respuestas no sean largas …
noviembre 14, 2007 en 9:19 pm
Los métodos más comunes de ataques a Servidores DNS ya han sidos nombrados así que iré a por otro que no daña el servicio o la información que éste proporciona, pero que puede utilizar esta información con fines malignos.
Footprinting mediante consulta de DNS
Los intrusos pueden lograr gran cantidad de información acerca de la infraestructura de la red simplemente interceptando los paquetes de DNS y así identificar sus posibles objetivos dentro de la red. Al capturar paquetes DNS se puede aprender acerca de el sistema de resolución de nombres, nombres de las máquinas de la red, y el esquema IP de la red. Esta información de red revela la funcionalidad de cada máquina, permitiendo decidir cuáles son los objetivos más fructíferos para el atacante y obtiener información sobre la forma de atacarlos.
Por lo tanto esta técnica revela vulnerabilidades o incluso hace más claro al atacante la forma de ser explotadas. Se podría denominar como una técnica de la fase de pre-ataque.
Una posible solución a este problema es encriptar el tráfico DNS mediante IPSec, que puede ser utilizado para proteger protocolos de la capa 4 del modelo OSI, incluyendo UDP que es el que interesa en este caso.
Referencias y ampliaciones:
http://www.creangel.com/drupal/?q=node/128
noviembre 14, 2007 en 1:19 pm
Dentro de los ataques mediante DoS (Negación de Servicio) que ya ha comentado Mª José, tenemos distintas variantes:
– Consumo de ancho de banda: Son los más viejos y elementales y
consisten simplemente en consumir todo el ancho de banda, es relativamente sencillo:
Un servidor de Internet pequeño, un ADSL típico, con una entrada de 512 Kb. Desde un equipo malintencionado con un ancho de banda de 2 Mb se realiza el ataque. Equivale al choque frontal de un tren con un triciclo, o bien, y es lo más normal, uniendo multitud de pequeñas máquinas para saturar la conexión de red de la víctima. Con simples modems de 56 Kb se pueden saturar líneas de 60 Mb de una manera sencilla: puede basarse por ejemplo, en que el atacante convenza a los sistemas amplificadores para enviar tráfico de red a la víctima consiguiendo de esa manera con un simple módem el enviar a la víctima flujos de información de hasta 100 Mb (megas!!). No es difícil usar estas técnicas de amplificación. O bien basarse en sistemas «zombies», miles, capturados previamente y en espera de ser despertados para organizar un ataque conjunto. En Internet se venden listas de miles de equipos conquistados y lo que es peor: alguien las compra, o puede comprarlas, cuando desea realizar uno de estos ataques.
– Inanición de recursos: Esta enfocado, en vez de a agotar el ancho de banda del sistema atacado, al consumo de los recursos del sistema, a la saturación de la CPU, memoria, lo que sea, hasta que la máquina se cae. Este tipo de ataque, generalmente provoca un fallo general del sistema, o que se llene un disco de log, o procesos que se cuelgan porque necesitan CPU que el sistema no le está proporcionando o se lo proporciona escasamente: y alguno de estos procesos puede ser crítico para el sistema.
– Errores de programación: Envío de datos «anormales», que no cumplen las RFC (normas de definición del protocolo) al sistema objetivo: si la pila TCP/IP no es capaz de manejar estas excepciones y los programadores no han supuesto estos casos, terminará con la caída del sistema al ser en la capa de drivers que se ejecuta en RING 0 o RING 1 de la máquina. A veces no son defectos de programación: son defectos del hardware, defectos de algún chip, o defectos de la propia CPU. No está de más recordar el famoso defecto existente en algún Pentium (no voy a citar modelos presentes o pasados) por el cual un proceso, incluso en modo usuario sin privilegios, podía colgar a la CPU con algo tan simple como enviarle la instrucción 0xf00fc7c8 a la CPU.
– DNS y de enrutamiento. La mayoría de los protocolos de enrutamiento como RIP (Routing Information Protocol) o BGP (Border Gateway Protocol) carecen de autenticación, o tienen una muy sencilla. Se trata por tanto de un escenario perfecto para que cualquier atacante pueda alterar las rutas correctas y, falsificando su IP origen, crear una condición DoS. Las víctimas de estos ataques verán como su tráfico se dirige por ejemplo hacia un agujero negro: a una red que no existe.
Los ataques DoS sobre servidores de nombres de dominios (DNS) son tan problemáticos como los anteriores. Estos ataques intentan convencer al servidor DNS, por ejemplo, para almacenar direcciones falsas: cuando un servidor DNS realiza una búsqueda el atacante puede redireccionar a su propio servidor o bien a un «agujero negro». En los últimos años se han sufrido varias veces ataques a alguno de los servidores «root» DNS de Internet colapsando media red y con tiempos de normalización superiores a las 48 horas.
1. Establecimiento de contactos expeditos entre los distintos ISPs y grandes clientes: si bien el correo electrónico es una buena vía, en los momentos en que un ISP o cliente estén bajo ataques, resulta mejor otras vías de comunicación. Teléfonos de emergencia (con sus respectivos contactos) serían de gran utilidad. Una base de datos con los contactos entre los distintos ISPs sería conveniente. Además, como regla de buena práctica, los ISPs deberían proveer a sus clientes de los respectivos contactos de emergencia. Un contacto expedito entre los distintos administradores de DNS dentro del país también resultaría beneficioso.
2. Los ISPs deben filtrar el tráfico saliente (dentro de sus routers), que no provenga efectivamente de sus redes: un ataque DDoS basa su funcionamiento en generar tráfico con un origen falsificado. Si un ISP permite que dicho tráfico se genere dentro de sus clientes (sea por error, virus, gusano, mala intención, etc), se convierte en un proveedor contribuyente al ataque. Simples medidas, como la de filtrar cualquier tráfico que no provenga efectivamente de sus redes registradas, minimiza el riesgo de un DDoS anónimo. Al respecto existen un par de documentos con recomendaciones de seguridad que todo ISP debería tomar en consideración. Dichos documentos son los RFC (Request For Comments, por sus siglas en inglés; son los documentos estándares en la Internet) números 2827 y 3013:
3. Similarmente a lo anterior, los ISPs deben filtrar el tráfico proveniente de la Internet hacia sus clientes, cuando dicho tráfico no esté dirigido específicamente a ninguna de sus redes.
4. Los ISPs deben filtrar el trafico proveniente de la Internet, cuyas direcciones IPs fuentes provengan del rango de numeros IPs privadas.
http://multingles.net/docs/jmt/ataques.htm
noviembre 14, 2007 en 12:32 pm
Se me ha olvidado poner la referencia:
noviembre 14, 2007 en 12:29 pm
Breve explicacion del protocolo DNS
El cliente (cliente.prueba.com) envía una petición de resolución del dominio «www.pagina.com». Para resolver el nombre, cliente.prueba.com utiliza «dns.prueba.com» para el DNS. Ahora que dns.prueba.com ha recibido la petición de la resolución de cliente.prueba.com, dns.prueba.com tendrá que resolver el nombre.
dns.prueba.com pregunta a ns.internic.net quién es el servidor de nombres raíz para la dirección de http://www.pagina.com, y si no la tiene, envía la petición a un servidor de nombres que tenga autoridad en dominios ‘.com’. Aquí podemos ver que ns.internic.net contestó a ns.prueba.com (que es el DNS que tiene autoridad sobre el dominio prueba.com), que el servidor de nombres de otro.com tiene la IP 144.44.44.4 (vamos a llamarlo ns.otro.com). Ahora nuestro ns.prueba.com pedirá a ns.otro.com la dirección de http://www.pagina.com, pero éste no la tiene y transmitirá la petición al DNS de pagina.com el cuál tiene autoridad para pagina.com. hora que conocemos qué dirección IP tiene autoridad en el dominio «pagina.com» (lo llamaremos ns.pagina.com), le preguntamos cuál es la IP de la máquina www (www.pagina.com). Y ahora tenemos por lo menos nuestra respuesta. Teniendo la respuesta, podemos remitirla a nuestro cliente cliente.prueba.com.
Ahora sabemos que los ID’s son predecibles, y aumentan solamente. Inundamos ns.victim.com con respuestas engañosas con ID 444+. Para solucionar este problema las versiones de 8.3.4, 4.9.11 y las recientes 8.2.x y 9.x de BIND no son vulnerables a este tipo de ataque.
Víctor Manuel Gonzalez Mira
noviembre 14, 2007 en 1:51 am
Me gustaria matizar lo que dijo el compañero sobre el ataque DoS, muy bien explicado. Existe una variante mas «reciente» del ataque DoS llamada DDoS (Distributed Denial of Service).
La mecanica es similar a la del ataque DoS, por no decir identica. La unica diferencia radica en que el ataque no se realiza desde una sola maquina, ya que eso hoy dia es totalmente inviable dado el enorme ancho de banda que manejan estos servidores.
Una sola maquina enviando paquetes jamás podria saturar un servidor de estas caracteristicas.
Por lo tanto el ataque DDoS se realiza utilizando varias maquinas previamente infectadas, llamadas «zombies».
Normalmente las maquinas son infectadas con mucha antelacion mediante algun tipo de virus o gusano y programadas para que se ejecute el ataque DoS al mismo tiempo en todas las maquinas contra un mismo servidor.
Esto hace que generalmente el servidor se sature o caiga durante un tiempo indefinido, lo que puede provocar grandes perdidas en segun que empresas. En cuanto a los servidores DNS, pues lo mismo.
noviembre 13, 2007 en 6:42 pm
– DNS Footprinting –
Con este tipo de ataque los intrusos pueden captar una gran cantidad de información acerca de la infraestructura de la red interceptando los paquetes de DNS para lograr identificar sus objetivos, aprender acerca de su DNS, los nombres de las máquinas, y el esquema IP que se emplea en dicha red. Esta información revela la funcionalidad de ciertas máquinas presentes en la misma, permitiendo al intruso decidir cuáles son los objetivos más fructíferos y otra forma de atacarlos.
En otras palabras, es el proceso de recolectar datos observando el ámbito de una red específica, usualmente con el propósito de encontrar caminos para introducirse dentro del ambiente en el que está inmersa. El footprinting puede revelar vulnerabilidades e incluso mejorar la facilidad con la cual éstas pueden ser explotadas.
Soluciones a este problema y otros como IPSoopfing, DoS, direccionamiento, etc, se comentan a continuación aunque no siempre consiguen abordarlo por completo:
– DNS redundante. Esto significa colocar más de un solo servidor DNS para la resolución de nombres dentro de la red. Esto puede implicar una mayor cantidad de recursos inicialmente pero a la larga es la solución más eficaz y más escalable que se puede representar.
– Doble configuración del cliente. Se recomienda en cada uno de los clientes colocar dos direcciones para DNS, una la del servidor de directorio activo, y otra la de su proveedor de acceso Internet. De esta manera está garantizando que tu servicio de DNS va estar activo 100%, si no de forma local de forma remota a través de el sistema de tu proveedor de acceso a Internet.
– Instalar un servidor en tu red externa de DNS y otro para la red interna. Esta estrategia te permite controlar el acceso a los recursos por separado, es decir, así se van a resolver todos los requerimientos de todos aquellos que sobrepasen el ámbito de su red local, mientras que el sistema de resolución de nombres para la LAN esta respaldado por un servidor interno que permite mantener actualizado y seguro el esquema de direcciones IP’s sin tener que realizar consultas a recursos externos.
– Control de interfaces de red. Limitando el acceso a consultas con esta medida, se consigue la resolución de DNS sólo por una de las interfaces de su servidor. De esta manera la interface de la red interna hacerla que a permitir la resolución de nombres de dicha red mientras que la interfase externa no a permitir resolución de nombres de tipo DNS.
– Uso de directorio activo(Active Directory). Es la implementación de Microsoft del servicio de directorios LDAP para ser utilizado en entornos Windows. El Directorio Activo permite a los administradores establecer políticas a nivel de empresa, desplegar programas en muchos ordenadores y aplicar actualizaciones críticas a una organización entera. Un Directorio Activo almacena información de una organización en una base de datos central, organizada y accesible. Pueden encontrarse desde Directorios Activos con cientos de objetos para una red pequeña hasta Directorios Activos con millones de objetos.
– Limitar el trafico por IP. Una forma de proteger las transferencia de zonas es especificando la IP de los servidores DNS que participan en la transferencia de zonas. De esta manera se puede limitar a dichos servidores el acceso, y un intruso va tener una labor mucho más difícil para lograr dicho acceso.
– Encriptar el trafico DNS. Utilizando el protocolo de IPSec o la implementación de VPN del sistema operativo. ¿Alguno ha usado IPSec?
– Proteger la caché. Consiste en prevenir la corrupción de la caché. No he encontrado como llevar a cabo esta parte, ¿si alguno sabría hacerlo?
– Autorizar las actualizaciones dinámicas de DHCP. Se realiza a través del sistema DHCP, el cual entrega direcciones de configuración inicial a los clientes. Para prevenir las actualizaciones dinámicas no autorizadas se debe autorizar el servidor DHCP dentro del servidor de directorio activo.
Por otra parte se puede cerrar todo el tráfico de su red al mundo exterior denegando todo acceso Internet y creando únicamente un punto de acceso al sistema para el servidor. Estas medidas aseguran el servidor DNS para tomar la mayoría de los tráficos pero pueden comprometer la funcionalidad del mismo en la red impidiendo al usuario el acceso a Internet, o resolver nombres que no pertenezcan al directorio activo o redes externas. Hay ocasiones en las que este tipo de medidas radicales pueden llegar a ser una garantía pero es el usuario el que debe hacer balance entre seguridad y funcionamiento de la red.
– http://www.creangel.com/
– http://www.microsoft.com/latam/technet/seguridad/
– http://msi.wikispaces.com/mo1_mades
Esta web te indica algunas nociones de como llevar a cabo un ataque de este tipo :O
– http://www.hackersdelocos.com.ar/
I Martinez Cerda
noviembre 13, 2007 en 1:37 pm
Nombre:pharming
explota los problemas de los servidores DNS o el de los usuarios. El atacante redirecciona un nombre de dominio a otra máquina distinta. De esta forma el usuario piensa que esta usando el servidor pero esta en otro.
Funcionamiento, dos formas:
1- se puede atacar directamente a los servidores DNS, (esta solución es la menos discreta y más complicada)
2- atacando a los clientes (modificando el fichero hosts) presente en Windows, GNULinus o Unix. Para ello se introduce un troyano en el disco duro de la víctima (lo cual es mucho más sencillo)El propio «troyano»puede tener instrucciones para restaurar la tabla original y autoinmolarse, borrando del disco duro el rastros de su presencia, eliminando casi totalmente las huellas del ataque, la próxima visita al banco no será desviada y el usuario no se dará cuenta del robo de su password.
Posibles soluiciones
-software para ello
«los expertos recomiendan:
Utilizar un software antimalware que combine sistemas de detección proactivos y reactivos, ya que la forma más sencilla de manipular un ordenador para que sea víctima del “pharming” es a través de un código malicioso, generalmente troyanos. Hay que utilizar sistemas de protección proactivos, capaces de adelantarse a las amenazas y bloquearlas.»http://www.belt.es/noticias/2005/abril/01/pahrming.htm
«Instalar un firewall personal: con esta precaución se evita que un hacker pueda entrar en el ordenador a través de un puerto de comunicaciones desprotegido, y modificar el sistema.
Actualizar regularmente el software instalado en el equipo o tener activados los sistemas de actualización automática, de forma que no existan vulnerabilidades.» http://www.belt.es/noticias/2005/abril/01/pahrming.htm
http://www.belt.es/noticias/2005/abril/01/pahrming.htm
http://www.laflecha.net/canales/seguridad/articulos/pharming/
noviembre 13, 2007 en 1:35 pm
ATAQUE A DNS MEDIANTE DENIAL OF SERVICE «DoS»
(NEGACIÓN DE SERVICIO)
La negación de servicios contra el DNS es uno de los impactos más peligrosos de ataque al sistema de nombres.
DoS puede ser logrado en diferentes maneras:
– Puede devolver respuestas negativas que nos indican que el nombre DNS no existe.
– También puede redireccionar la petición del cliente a un servidor que no contiene el servicio que el cliente pide.
– Se puede enviar una gran cantidad de peticiones con una dirección IP falsificada al DNS que permite recursión, el DNS procesa las peticiones enviadas y manda una respuesta al sistema ocupando muchísimo espacio lo que provoca que caiga el sistema.
Los ataques DoS en los servidores DNS pueden también alcanzar el mismo objetivo con mayor efecto.
Estos ataques intentan convencer al servidor DNS, por ejemplo:
– Para almacenar direcciones falsas;
Cuando un servidor DNS realiza una búsqueda el atacante puede redireccionar a su propio servidor o bien a un “agujero negro”.
La negación de servicio se utiliza contra los servidores raíz DNS de Internet, lo que produce es que se colapse la red generando tiempos de normalización superiores a las 48 horas.
Los servidores DNS tienen recursión activada.
La mayoria de las veces estos problemas se producen porque el DNS no está bien configurado.
Asegurarnos de que el DNS no tenga recursión, para ello podemos habilitar el BIND, por ejemplo en su última versión BIND9.
BIND es una implementación del sistema de nombres de dominio.
http://ftp.ucv.ve/Documentos/Evento%20de%20Seguridad/Ponencia%2012%20Francisco%20Obispo.ppt
http://www.seguridad.unam.mx/labsec/tuto/?id=181&ap=articulo&cabecera=2
I Martínez Cerdá
noviembre 13, 2007 en 1:32 pm
«Instalar un firewall personal: para evitar que un hacker pueda entrar en el ordenador a través de un puerto de comunicaciones desprotegido, y modificar el sistema.
Abro esta sección (ventajas de tener el blog sindicado) con un bug en el servicio DNS que ha dado varios quebraderos de cabeza, mi idea, excepto si me quitan todas las ideas es postear algún otro post para no escribir ahora un post enorme que nadie lea.
DNS Cache Poisoning [1] [2] [3]
Esta técnica se remonta a los orígenes de los servidores DNS.
Se trata de someter al servidor de DNS a un engaño haciendole creer que ha recibido información correcta. cuando realmente es información envenenada (algo parecido puede suceder en ARP.. otro protocolo de traducción de direcciones), y esta información se distribuya durante el tiempo que quede cacheada a los clientes que realizen peticiones DNS.
Normalmente se aprovecha un fallo de seguridad en el servidor, para poder ‘inyectar’ y que el servidor acepte información envenenada, por ejemplo, cuando el servidor no puede determinar la veracidad de la información de origen y hace que acepte cualquier petición.
Esto puede aprovecharlo un atacante para tomar el control de las acciones del servidor, pudiendo redirigirlo a otro que este bajo su control.
Este tipo de envenenamiento se produce en el servidor, cuando hablamos de envenamiento en el cliente se denomina Pharming [4].
Las razones que suelen mover este tipos de ataques son robos de identidad, distribución de malware y la distribución de información falsa, también para aprovecharse de ataqutes MITM (man-in-the-middle).
Una solución es usar servidores DNS seguros, DNSSEC [5]
No quiero extenderlo mucho más aunque se podrían dar más detalles, os dejo unas referencias muy interesantes, en concreto el pdf de [3] que además de definir este concepto da medidas con el objetivo de prevenior estos ataques, aqui mas abajo:
[1] http://en.wikipedia.org/wiki/DNS_cache_poisoning
[2] http://www.sahw.com/wp/archivos/2006/03/28/envenanamiento-dns-definicion-y-metodos-de-prevencion/
[3] http://www.infosecwriters.com/text_resources/pdf/DNS_TOlzak.pdf
[4] http://es.wikipedia.org/wiki/Pharming
[5] http://en.wikipedia.org/wiki/DNSSEC
yolanda campos arenas
noviembre 13, 2007 en 2:12 am
Con esta técnica conseguimos spoofear nuestro hostname, es decir, que un servidor nos asocie el nombre de host que queramos (y no el que tiene realmente, que es único) (en realidad, puede haber más de uno, pero sólo uno es el real, lo que se conoce como «canonical name» mientras que los demás son simples «aliases»).
Como se puede intuir el truco está en forzar al NS a que de una respuesta falsa (siempre en favor nuestro :-)). Digamos que modificamos los datos del NS para que responda a nuestra IP con el hostname que nosotros queremos y no con el que debería hacerlo realmente. Se dice que hemos «inyectado» (injectado, en inglés :-P) el NS.
Una solución que se me ocurre es la de llevar un control más preventivo de las respuestas que nos da el NS verificando periódicamente que sean las verdaderas, con alguna copia de seguridad encriptada que no sea modificable por cualquiera.
http://www.um.es/docencia/barzana/DIVULGACION/INFORMATICA/irc01.html
noviembre 13, 2007 en 1:53 am
Se describe como un servidor DNS que hace uso de información falsa recibida desde un host que no es autoridad para la información. Es una amenaza significativa para la seguridad de las organizaciones que no han tomado medidas para protegerse de ella. El DNS Spoofing puede permitir a los atacantes acceder al correo de un sitio, y puede hacer que los usuarios sean redirigidos a sitios Web incorrectos incluso proporcionando una abertura para un ataque de Negación de Servicio.
Ejemplos de modus operandi:
Escenario: La compañía, TAMJTeK Inc., está compitiendo para acabar el desarrollo del último software de juegos antes de que el capital de la empresa salga. Se comienza a anunciar el aviso pendiente de una brecha en tecnología de este juego en el sitio Web de Internet. Usted tiene una llamada de uno de los socios de la empresa. Ella desea saber por que termina llegando a http://www.hackncrack.net cuando intenta llegar a http://www.tamjtek.com. Usted intenta conectarse al sitio Web y, seguro, termina llegando a http://www.hackncrac.net. Usted prueba algunos otros sitios y todo parece muy bien excepto, que encuentra que su competidor más fuerte ha anunciado una brecha en el mismo juego. Su sitio Web demuestra una imagen de su juego, la cual parece notablemente similar a la suya con aspectos virtualmente idénticos. ¿Coincidencia? Quizás no.
Hackncrack.net (10.0.0.0) Tamjtek.com (11.0.0.0)
Ns1.hackncrack.net (10.0.0.5) ns1.tamjtek.com (11.0.0.5)
http://www.hackncrack.net(10.0.0.6) http://www.tamjtek.com(11.0.0.6)
El atacante ha modificado el servidor de nombres Hackncrack para responder a una consulta recursiva para los registros DNS Hackncrack con un falso registro autoritario, mapeando http://www.tamjtek.com a la dirección IP 10.0.0.6. El atacante entonces dirige una consulta al servidor de nombres TAMJTeK preguntando por los registros DNS sobre el sitio del atacante. El servidor de nombres TAMJTeK resuelve la consulta yendo al servidor de nombres Hackncrack. Desde que el servidor de nombres TAMJTeK no esta protegido contra DNS Spoofing, acepta y almacena el registro falso que incluye la respuesta. Siempre que una consulta se haga al sitio Web de TAMJTeK, el registro para el sitio Web Hacncrack será regresado y todo será redireccionado a http://www.hacckncrack.net. El atacante en Hackncrack puede también engañar un registro MX para dirigir el correo de TAMJTeK a su servidor de correo. Un registro falso MX puede desapercibir una cantidad de tiempo significativa si el atacante esta bien informado.
Ejemplo 2: Prediciendo el número de consulta ID, un atacante puede realizar otra adaptación de DNS Spoofing personificando un servidor de nombres. El protocolo DNS usa el protocolo UDP para comunicarse. Dada la naturaleza sin conexión de UDP, DNS es diseñado para establecer comunicaciones ordenadas entre equipos. Esto es logrado identificando datagramas con un número de consulta ID. El host que inicia la consulta asigna este número. En las versiones anteriores de BIND, este se incrementaba secuencialmente para cada nueva consulta. Con este ejemplo, podra observar como el atacante engaña a los usuarios de TAMJTeK.com haciendo parecer que ellos van a http://www.AnyBank.com cuando, en realidad, se están conectando a http://www.Hackncrack.net. El atacante en Hackncrack.net consulta TAMJTeK.com para la información que los atacantes poseen del dominio. El servidor de nombres TAMJTeK resuelve las consultas referidas a Hackncrack.net El servidor de nombres del atacante regresa la información correcta sobre sí mismo a TAMJTeK.com y el servidor de nombres de la víctima lo reenvía al host del atacante que inició la consulta. Para montar este ataque, el intruso tiene que, primero, aprender cual es el número ID de la consulta. Escuchando los datos durante la consulta se puede obtener éste. Una vez que el número ID sea disponible, el atacante hace un datagrama de la respuesta del DNS con información falsa: http://www.AnyBank.com = 10.0.0.6 y lo configura como si la fuente fuera ns.AnyBank.com. El atacante inicia una consulta para TAMJTaK.com preguntando por información sobre AnyBank.com e inserta el datagrama modificado en la línea como la respuesta. De nuevo, el servidor de nombres inseguro TAMJTeK.com acepta y almacena los datos. Cuando los usuarios de TAMJTeK intentan conectarse a http://www.AnyBank.com, ellos son redirigidos a una página Web específica en el servidor Web Hackncrack que contiene exactamente la información de la página de la cuenta AnyBank.com. En este punto, el atacante puede recolectar cuentas de usuarios y números de PIN a voluntad.
1. Mail-Form (Mínima Seguridad): El contacto somete una dirección de correo electrónico de la cual toda la administración de registro origine. Cuando un cambio de registro se somete a la NSI vía correo electrónico, la dirección de correo electrónico fuente es comprada con la dirección de correo sometida durante el inicio del dominio original.
2. Cryp-Password (Un poco de Seguridad): Durante la disposición inicial, el contacto escoge una contraseña. Esta contraseña es cifrada y almacenada en la base de datos del NSI. Cuando el administrador somete un cambio de registro, la versión en texto plano de la contraseña es incluida. NSI cifra el texto plano de la contraseña que acompaña la petición de cambio y la compara con la original.
3. PGP (Más Seguridad): NSI soporta mensajes cifrados con PGP si se originaron desde una plataforma Unix. Ninguna otra plataforma es soportada en este momento.
Una posible solución sería eliminar las relaciones de confianza basadas en la dirección IP o el nombre de las máquinas, sustituyéndolas por relaciones basadas en claves criptográficas; el cifrado y el filtrado de las conexiones que pueden aceptar nuestras máquinas también son unas medidas de seguridad importantes de cara a evitar el spoofing.
http://www.ibiblio.org/pub/linux/docs/LuCaS/Manuales-LuCAS/doc-unixsec/unixsec-html/node274.html
http://www.seguridad.unam.mx/labsec/tuto/?id=135&ap=articulo&cabecera=2

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución