{"id":10598,"date":"2015-07-09T09:00:21","date_gmt":"2015-07-09T14:00:21","guid":{"rendered":"http:\/\/ctrl-x.com.mx\/ctrlx\/?p=10598"},"modified":"2015-07-09T09:00:21","modified_gmt":"2015-07-09T14:00:21","slug":"como-mitigar-los-ataques-ddos-dns","status":"publish","type":"post","link":"https:\/\/ctrl-x.com.mx\/ctrlx\/como-mitigar-los-ataques-ddos-dns\/","title":{"rendered":"C\u00f3mo mitigar los ataques DDoS DNS"},"content":{"rendered":"

Un ataque de denegaci\u00f3n de servicio (DDoS) es un intento malicioso para hacer que un servidor o un recurso de red disponibles para los usuarios sean, por lo general, interrumpidos temporalmente o para suspender los servicios de un <\/span><\/span>host<\/i><\/span><\/span> conectado a Internet.<\/span><\/span>
\n\"dosx\"Los ataques DDoS se han incrementado en un 240% en el a\u00f1o 2014, de acuerdo con la Security Watchdog. Por su parte, un estudio del Instituto Ponemon estima que el costo promedio de un minuto y el tiempo de inactividad debido a un ataque DDoS es de 22 mil d\u00f3lares, mientras que el tiempo de inactividad promedio es de aproximadamente 54 minutos. Por fortuna, se pueden mitigar los ataques DDoS tomando algunas medidas preventivas.<\/span><\/span>
\nHay tantas maneras en las que los <\/span><\/span>hackers<\/i><\/span><\/span> pueden atacar a los servidores DNS como formas en las que los administradores de sistemas pueden mitigar algunos de estos embates. Por desgracia, los usuarios no pueden hacer mucho para modificar los servidores DNS a fin de atenuar los ataques, aunque deben tener en cuenta algunas precauciones.<\/span><\/span>
\n\"ipx\"El principal problema est\u00e1 en el propio protocolo DNS, que permite a los <\/span><\/span>hackers<\/i><\/span><\/span> utilizar direcciones IP diferentes a la del usuario cuando hacen una consulta DNS, por lo que la respuesta se env\u00eda a otra persona; es decir, la v\u00edctima. <\/span><\/span>
\nEl est\u00e1ndar DNSSEC propone modificar el protocolo DNS para permitir la firma del DNS ra\u00edz, lo que bloquear\u00eda la modificaci\u00f3n de los registros DNS para que apunte a otros sitios. El Internet Corporation for Assigned Names and Numbers (ICANN) asegura que algunos dominios de primer nivel, como .com, .se y .uk ya est\u00e1n protegidos con este mecanismo.<\/span><\/span><\/p>\n

TIPOS DE ATAQUES<\/b><\/span><\/span><\/p>\n

DDoS DNS<\/span><\/span><\/h2>\n

En un ataque DNS DDoS el <\/span><\/span>hacker<\/i><\/span><\/span> falsifica la direcci\u00f3n IP de la consulta DNS. Supongamos que \u00e9ste quiere acabar con un servidor DNS en la direcci\u00f3n IP 1.2.3.4, para lo cual puede usar cualquiera de las herramientas de <\/span><\/span>hacking<\/i><\/span><\/span> de libre acceso o una red de <\/span><\/span>bots<\/i><\/span><\/span> que puede alquilar a otros <\/span><\/span>hackers<\/i><\/span><\/span> a fin de enviar una consulta a cualquier servidor DNS con la direcci\u00f3n IP de retorno 1.2.3.4. <\/span><\/span>
\nEl servidor de DNS, si tiene ese registro en su cach\u00e9 o si es la fuente autorizada, env\u00eda la respuesta UDP al servidor DNS ubicado en 1.2.3.4. El atacante intent\u00f3 enviar varias solicitudes de b\u00fasqueda a la v\u00edctima mediante el env\u00edo de las solicitudes a varios servidores DNS, tantas que el servidor 1.2.3.4 es incapaz de responder al tr\u00e1fico leg\u00edtimo debido al volumen del mismo.<\/span><\/span>
\nCuando un equipo consulta un servidor DNS y este \u00faltimo no tiene el nombre de dominio en su cach\u00e9, consulta otros servidores DNS en la cadena. Cuando as\u00ed se hace, \u00e9stos no usan la misma direcci\u00f3n IP falsa 1.2.3.4 del servidor que hizo la consulta; en su lugar, utilizan su propia direcci\u00f3n IP. El servidor DNS recibe la respuesta y a continuaci\u00f3n reenv\u00eda la consulta al servidor DNS objetivo 1.2.3.4, as\u00ed que el ataque no puede ser empujado hacia la cadena de confianza.<\/span><\/span>
\nUna manera de minimizar este ataque DNS es verificando que la direcci\u00f3n IP simulada sea v\u00e1lida. Los administradores son reacios a hacer eso porque frenar\u00edan un proceso que ahora es casi instant\u00e1neo. Para hacer esta verificaci\u00f3n pueden utilizar Unicast Reverse Sendero Forwarding (Unicast FPR) o rechazar las consultas que ya se encuentran en una direcci\u00f3n IP.<\/span><\/span><\/p>\n

Amplificaci\u00f3n de DNS<\/span><\/span><\/h2>\n

En el caso de un ataque de la amplificaci\u00f3n, los <\/span><\/span>hackers<\/i><\/span><\/span> actualizan la informaci\u00f3n de zona DNS en un servidor de dominio TLD comprometida para alargar la respuesta (digamos 4,000 <\/span><\/span>bytes<\/i><\/span><\/span>); es m\u00e1s grande que el tama\u00f1o m\u00e1ximo del paquete IP, por lo que la respuesta se env\u00eda a trav\u00e9s de TCP en vez de UDP a fin de asegurarse que los paquetes se devuelven en el orden correcto. La conversaci\u00f3n SYN-ACK-SYN de TCP, por supuesto, lleva m\u00e1s tiempo que UDP, atando <\/span><\/span>sockets<\/i><\/span><\/span> y puertos y complicando a\u00fan m\u00e1s la situaci\u00f3n. En este tipo de ataques los 60 <\/span><\/span>bytes<\/i><\/span><\/span> de la consulta inicial devuelta al servidor DNS objetivo 1.2.3.4 ha sido amplificada por casi 70 veces.<\/span><\/span><\/p>\n

Inundaciones UDP<\/span><\/span><\/h2>\n

La otra manera de atacar a un DNS es mediante una \u201cinundaci\u00f3n UDP\u201d. Las consultas DNS utilizan el protocolo UDP y el servidor DNS responde con una respuesta de ICMP. Una manera de mitigar esto es limitando la tasa de respuestas ICMP al utilizar RRL DNS.<\/span><\/span><\/p>\n

Envenenamiento de DNS<\/span><\/span><\/h2>\n

\"dnsx\"Intoxicaci\u00f3n significa sobrescribir un registro DNS leg\u00edtimo con uno falso. Hay varias formas de ejecutar un envenenamiento de DNS; una de ellas es poner en peligro un servidor DNS de nivel superior (TLD) y modificar el DNS TTL (<\/span><\/span>time to live informaci\u00f3n<\/i><\/span><\/span>)<\/span><\/span>. El servidor DNS no purgar\u00e1 ese registro DNS hasta que transcurra el tiempo TTL; por lo tanto, no podr\u00e1 modificarse la direcci\u00f3n IP \u201ctuempresa.com\u201d, por ejemplo, para que apunte a una direcci\u00f3n que no es la correcta, por lo que la gente que busque \u201ctuempresa.com\u201d no la encontrar\u00e1 durante alg\u00fan tiempo o ser\u00e1 dirigida a un sitio diferente que aloja <\/span><\/span>malware<\/i><\/span><\/span>.<\/span><\/span>
\nUna forma de mitigar este tipo de ataque es cambiando el puerto que el servidor DNS escucha en el valor predeterminado de 53. Al intentar atacar el servidor DNS, el <\/span><\/span>hacker<\/i><\/span><\/span> debe adivinar el n\u00famero de puerto hasta que encuentre el correcto. El problema con este enfoque es<\/span><\/span> que se suele traducir este regreso al puerto 53 por defecto, frustrando as\u00ed la t\u00e1ctica para mitigar el ataque.<\/span><\/span>
\nLa otra cosa que puede hacerse es externalizar el tr\u00e1fico DNS a una empresa como <\/span><\/span>DYN.com<\/i><\/span><\/span>, que tambi\u00e9n ofrece servicios de gesti\u00f3n de tr\u00e1fico; asimismo, es posible usar Prolexic (<\/span><\/span>http:\/\/www.prolexic.com<\/i><\/span><\/span>) que cuenta con una amplia infraestructura para ayudar a mantenerse al d\u00eda con el volumen de consultas DNS a fin de que las b\u00fasquedas sean leg\u00edtimas, adem\u00e1s de que puede filtrar una parte del tr\u00e1fico ileg\u00edtimo.<\/span><\/span><\/p>\n

Open resolvers<\/span><\/span><\/h2>\n

Un \u201csolucionador abierto\u201d es aqu\u00e9l que responde a una consulta que est\u00e1 fuera de su propio dominio. El problema es que la mayor\u00eda de los servidores DNS de todo el mundo no se vigila de manera adecuada. Para proteger servidores DNS m\u00e1s peque\u00f1os contra eso (es decir, dominio propio e infraestructura en la nube) habr\u00eda que coordinarlos con otros servidores DNS a fin de bloquear solucionadores abiertos y sin garant\u00eda, lo cual no es tan dif\u00edcil si se restringe la b\u00fasqueda a clientes o a los rangos propios de la IP de la empresa.<\/span><\/span><\/p>\n

Nombre de dominio, extensiones de seguridad<\/span><\/span><\/h2>\n

Las extensiones de seguridad DNS son una extensi\u00f3n del protocolo DNS que agrega una clave y una firma para el paquete DNS; es compatible con versiones anteriores, por lo que puede utilizarse sin romper nada. Pero esto s\u00f3lo funcionar\u00e1 si los administradores configuran DNSSEC totalmente hasta llegar a la cadena de confianza, por ejemplo \u201c<\/span><\/span>cuenta.tuempresa.com<\/i><\/span><\/span>\u201d, \u201c<\/span><\/span>tuempresa.com<\/i><\/span><\/span>\u201d o \u201c<\/span><\/span>.com<\/i><\/span><\/span>\u201d. Esto tomar\u00e1 alg\u00fan tiempo para asimilarlo, a pesar de su adopci\u00f3n por parte de los administradores de servidores DNS.<\/span><\/span>
\nEn resumen, no hay una soluci\u00f3n 100% eficaz para la denegaci\u00f3n de ataques de servicio DNS; ayudar\u00eda en algo si los usuarios pudieran obtener el control de <\/span><\/span>botnets<\/i><\/span><\/span>, pero la mayor\u00eda de quienes cuentan con un equipo no sabe si \u00e9ste ha sido <\/span><\/span>hackeado<\/i><\/span><\/span>, por lo que de alguna manera son c\u00f3mplices involuntarios en este tipo de delito.<\/span><\/span>
\nMuchas organizaciones que han luchado contra los ataques DDoS en sus sitios web u otras partes vitales de sus infraestructuras de red est\u00e1n moviendo algunos de sus recursos a la nube para aprovechar la seguridad y los beneficios operativos que ofrecen algunos proveedores de este tipo de servicios.<\/span><\/span><\/p>\n

www.hdmexico.com<\/a>.mx<\/i><\/span><\/span><\/p>\n

www.hdlatinoamerica.com<\/i><\/span><\/span><\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Un ataque de denegaci\u00f3n de servicio (DDoS) es un intento malicioso para hacer que un servidor o un recurso de red disponibles para los usuarios sean, por lo general, interrumpidos temporalmente o para suspender los servicios de un host conectado a Internet. Los ataques DDoS se han incrementado en un 240% en el a\u00f1o 2014,… Seguir leyendo C\u00f3mo mitigar los ataques DDoS DNS<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":10600,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8,30,34,41,44,51,54],"tags":[518,1184,1416,1597,2474,2655,2663,2669],"class_list":["post-10598","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","category-internet","category-marketing","category-negocios","category-organizaciones","category-seguridad","category-tecnologia","tag-ataques","tag-conectado","tag-ddos","tag-dns","tag-host","tag-intento-malicioso","tag-internet","tag-interrumpidos","entry"],"_links":{"self":[{"href":"https:\/\/ctrl-x.com.mx\/ctrlx\/wp-json\/wp\/v2\/posts\/10598","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ctrl-x.com.mx\/ctrlx\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ctrl-x.com.mx\/ctrlx\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ctrl-x.com.mx\/ctrlx\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/ctrl-x.com.mx\/ctrlx\/wp-json\/wp\/v2\/comments?post=10598"}],"version-history":[{"count":0,"href":"https:\/\/ctrl-x.com.mx\/ctrlx\/wp-json\/wp\/v2\/posts\/10598\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ctrl-x.com.mx\/ctrlx\/wp-json\/"}],"wp:attachment":[{"href":"https:\/\/ctrl-x.com.mx\/ctrlx\/wp-json\/wp\/v2\/media?parent=10598"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ctrl-x.com.mx\/ctrlx\/wp-json\/wp\/v2\/categories?post=10598"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ctrl-x.com.mx\/ctrlx\/wp-json\/wp\/v2\/tags?post=10598"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}