¿Por qué el ataque Dyn de octubre de 2016 se limitó a la costa este?

  

Los mapas en Internet mostraron que el foco del ataque DynS Dyn estaba en la costa este de los EE. UU. Pero ¿por qué?

Esto se debe a que la primera ola de ataques ocurrió principalmente en la costa este Chicago, Washington DC y Nueva York donde se encuentran los tres centros de datos DNS de Dyn.

  

Mi DNS es 8.8.8.8 (DNS público de Google). Sin embargo, cuando intenté acceder a twitter.com, mi computadora no pudo resolver el nombre. Supongamos que el DNS TTL expiró y Google tuvo que emitir una consulta recursiva que finalmente llegó a Dyn, que tal vez sea el DNS autoritario de Twitter. (¿Es eso cierto?)

Usted tiene toda la razón, esto podría haber ocurrido, las entradas de caché de DNS de Google podrían haber caducado y tuvo que hacer una consulta recursiva a un servidor DNS Dyn que no responde. He aquí el motivo:

• Estás en Colorado, conectado a algún XYZ ISP. Cuando intentas abrir twitter.com. La máquina intenta obtener la dirección IP de la misma desde 8.8.8.8, que es el DNS que está utilizando en su máquina.
• Ahora 8.8.8.8 no pertenece a XYZ ISP, pertenece a Google, que puede estar en Colorado o en otro lugar (tal vez en la costa este). Incluso si 8.8.8.8 está o hubiera estado en Colorado, su ISP no estar conectado a ella (directamente). Por lo tanto, aún puede estar obteniendo la mejor ruta (a 8.8.8.8) desde otro lugar (tal vez la costa este). Punto saturado: hay un número N del servidor de DNS público de Google ubicado en diferentes ubicaciones y no sabe a cuál está consultando (lo que depende de la mejor ruta a 8.8.8.8 de su ISP). Este es un concepto de difusión en cualquier lugar. La dirección IP se encuentra en varias ubicaciones para proporcionar una mayor disponibilidad de servicio.
• Supongamos que llega a 8.8.8.8 con su consulta y, como dijo, el TTL para twitter.com ha caducado. Ahora 8.8.8.8 tiene que hacer una consulta recursiva para obtener la dirección de twitter.com para usted, así que tiene que pasar por un proceso de solicitud de servidor de nombre de raíz - > gTLD - > Servidor raíz de twitter.com (en este caso, Dyn alojó) los siguientes servidores que recibe de la consulta a gTLD.

prok-MacBook:~ anirudh_malhotra$ dig twitter.com @g.gtld-servers.net.

; <<>> DiG 9.8.3-P1 <<>> twitter.com @g.gtld-servers.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11045
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;twitter.com.         IN  A

;; AUTHORITY SECTION:
twitter.com.      172800  IN  NS  ns1.p34.dynect.net.
twitter.com.      172800  IN  NS  ns2.p34.dynect.net.
twitter.com.      172800  IN  NS  ns3.p34.dynect.net.
twitter.com.      172800  IN  NS  ns4.p34.dynect.net.

;; ADDITIONAL SECTION:
ns1.p34.dynect.net.   172800  IN  A   208.78.70.34
ns2.p34.dynect.net.   172800  IN  A   204.13.250.34
ns3.p34.dynect.net.   172800  IN  A   208.78.71.34
ns4.p34.dynect.net.   172800  IN  A   204.13.251.34

;; Query time: 146 msec

Observe que hay cuatro servidores de nombres para twitter.com, que indicarán a 8.8.8.8 cuál es la IP de twitter.com . Ahora, obviamente, Dyn desearía tener varias ubicaciones del mismo servidor de nombres. (cualquier difusión, al igual que el DNS público de google) y también querría los servidores de nombres en diferentes ubicaciones (quizás algunos en la costa este, algunos al oeste o incluso algunos fuera de los EE. UU.)

• Nuevamente, cuando 8.8.8.8 sale a consultar uno de estos servidores de nombres, puede ir o no a los servidores de la costa este, lo que depende completamente de: cuál es la mejor ruta a estos servidores (o más bien, IPs) de estos servidores)

Conclusión: twitter.com no funcionó en XYZ ISP en Colorado cuando el ataque se realizó en la costa este habría ocurrido porque O bien usted estaba consultando un servidor 8.8.8.8 que estaba ubicado en la costa este, que era un interno que consultaba los servidores afectados de la costa este Dyn (debido a su proximidad y la mejor ruta desde allí) O el 8.8.8.8 (que aún puede estar en la costa oeste) aún habría estado consultando a los servidores afectados de la costa este de Dyn debido a la mejor ruta desde allí. Así que incluso yo sentado en la India puede que no consiga twitter.com (aunque es muy poco probable, debido a la gran cantidad de despidos) por la misma razón.

Si hablamos específicamente del caso de twitter.com; Como el sitio no era accesible desde la costa este y por qué era accesible desde el resto del mundo (aproximadamente).

BGP enruta el anuncio de la misma red IP desde varias ubicaciones y la existencia de infraestructura en varias ubicaciones es la respuesta de su consulta.

Al hacer la excavación de twitter.com desde varios resolvedores abiertos, obtuve varias direcciones IP para dicho dominio, pero todas pertenecen a la misma red / 24 IP.

Kansals-MacBook:~ Kansal$ dig twitter.com A +short @4.2.2.4 104.244.42.193 104.244.42.65 Kansals-MacBook:~ Kansal$ dig twitter.com A +short @8.8.8.8 104.244.42.129 104.244.42.65 Kansals-MacBook:~ Kansal$ dig twitter.com A +short 104.244.42.65 104.244.42.193 Kansals-MacBook:~ Kansal$ dig twitter.com A +short @8.20.247.20 104.244.42.129 104.244.42.1 Kansals-MacBook:~ Kansal$

Por lo tanto, el sitio de Twitter está alojado en el segmento 104.244.42.0/24 (obteniendo una dirección IP de este segmento solo desde varias ubicaciones; pueden existir casos en las esquinas).

Al hacer WHOIS para este segmento de IP, tengo que saber que los siguientes resultados:

Kansals-MacBook:~ Kansal$ whois 104.244.42.65 NetRange: 104.244.40.0 - 104.244.47.255 CIDR: 104.244.40.0/21 NetName: TWITTER-NETWORK NetHandle: NET-104-244-40-0-1 Parent: NET104 (NET-104-0-0-0-0) NetType: Direct Assignment OriginAS: AS13414 Organization: Twitter Inc. (TWITT) RegDate: 2014-12-08 Updated: 2014-12-08

Esto significa que el 104.244.40.0/21 segmento de IP pertenece a twitter.

Twitter ha anunciado este segmento (/ 21 o / 22 o / 24) desde sus diversos Centros de datos (o desde instalaciones de ubicaciones conjuntas) en todo el mundo.
Entonces, cuando solicito twitter.com, voy a Singapur (ya que estoy obteniendo las mejores rutas para este segmento en particular) Y cuando alguien intenta acceder a twitter.com desde la costa este, puede que tenga el mejor camino para el segmento desde la ubicación que estaba bajo ataque DDoS.

Debido a esta posibilidad de anuncio del segmento IP desde varias ubicaciones y la existencia de infraestructura en todo el mundo, el servicio solo se vio afectado por algunas (ubicaciones que estaban bajo ataque).

Espero que esto responda a su consulta.

DNS con carga geográfica equilibrada Consulte la siguiente respuesta para obtener más detalles:

enlace

También señalaré que el sistema al que tocaste en 8.8.8.8 probablemente no sea el sistema al que toco en 8.8.8.8 debido a los trucos de escalado de BGP. Para algunas consultas de DNS obtendremos resultados diferentes (probablemente solo los sitios de Google y los sitios con carga equilibrada geográficamente), pero de lo contrario serían los mismos.

FWIW: veo lo siguiente para twitter desde varias ubicaciones y parece que todos sus servidores DNS están actualmente alojados en dynect.net Dyn DNS:

dig -t NS twitter.com

; <<>> DiG 9.8.1-P1 <<>> -t NS twitter.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41734
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;twitter.com.           IN  NS

;; ANSWER SECTION:
twitter.com.        82622   IN  NS  ns2.p34.dynect.net.
twitter.com.        82622   IN  NS  ns3.p34.dynect.net.
twitter.com.        82622   IN  NS  ns4.p34.dynect.net.
twitter.com.        82622   IN  NS  ns1.p34.dynect.net.

;; Query time: 8 msec
;; SERVER: 173.203.4.8#53(173.203.4.8)
;; WHEN: Sat Oct 22 06:39:33 2016
;; MSG SIZE  rcvd: 115