Perché l'attacco Dyn di ottobre 2016 è stato limitato alla costa orientale?

Question

Perché l'attacco Dyn di ottobre 2016 è stato limitato alla costa orientale?

#1 da (3 voti)
#2 da (3 voti)
#3 da (2 voti)

8

Le mappe su Internet hanno mostrato che il focus dell'attacco Dyn DDoS era sulla costa orientale degli Stati Uniti. Ma perché?

Il mio provider DNS non si trova sulla costa orientale e sono in Colorado. Il mio DNS è 8.8.8.8 (Google Public DNS). Tuttavia, quando ho provato a contattare twitter.com, il mio computer non ha potuto risolvere il nome.

Supponiamo che il TTL DNS sia scaduto e Google abbia dovuto emettere una query ricorsiva che è atterrato alla fine su Dyn, che forse è il DNS autorevole per Twitter. (È vero?) E supponiamo che Dyn non possa rispondere. Ciò non spiegherebbe ancora perché l'attacco si concentrerebbe geograficamente sulla costa orientale.

Qualcuno può spiegare?

dns ddos

posta Fixee 22.10.2016 - 04:02

fonte

3 risposte

3

Se parliamo specificamente del caso di twitter.com; Perché il sito non era accessibile dalla costa orientale e perché era accessibile dal resto del mondo (all'incirca).

BGP indirizza l'annuncio della stessa rete IP da più posizioni e l'esistenza dell'infrastruttura in varie località è la risposta della tua query.

Nel fare lo scavo per twitter.com da più risolutori aperti, ho ottenuto più indirizzi IP per il suddetto dominio ma appartengono tutti alla stessa rete IP / 24.

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$

Quindi, il sito twitter è ospitato nel segmento 104.244.42.0/24 (ottenendo un ip da questo segmento solo da varie posizioni, potrebbero esistere casi d'angolo).

Nel fare il WHOIS per questo segmento IP, ho avuto modo di sapere che i seguenti risultati -

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

Ciò significa che il segmento IP 104.244.40.0/21 appartiene a Twitter.

Twitter ha annunciato questo segmento (/ 21 o / 22 o / 24) dai suoi vari Data Center (o dalle strutture di co-location) in tutto il mondo.
Quindi, quando richiedo Twitter.com, vado a Singapore (poiché sto ricevendo i migliori itinerari da Singapore per questo particolare segmento) e quando qualcuno cerca di accedere a twitter.com dalla costa orientale, potrebbe avere il percorso migliore per il segmento dalla posizione che era sotto attacco DDoS.

A causa di questa possibilità di annuncio del segmento IP da più posizioni e dall'esistenza di infrastrutture in tutto il mondo, il servizio è stato interessato solo per pochi (luoghi che erano sotto attacco).

Spero che questo risponda alla tua domanda.

risposta data 22.10.2016 - 09:36

fonte

2

DNS con bilanciamento del carico geografico Vedere la seguente risposta per ulteriori dettagli:

link

Farò anche notare che il sistema che hai colpito a 8.8.8.8 non è probabilmente il sistema che avrei colpito a 8.8.8.8 a causa dei trucchi di scaling BGP. Per alcune query DNS otterremo risultati diversi (probabilmente solo siti di Google e siti con bilanciamento del carico geografico) ma altrimenti sarebbero uguali.

FWIW: Vedo quanto segue per Twitter da più postazioni e sembra che tutti i loro server DNS siano attualmente ospitati su Dyn Dynamic.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

risposta data 22.10.2016 - 08:39

fonte

Leggi altre domande sui tag dns ddos

Come si può aggiungere un file PHP più e più volte al mio sito compromesso? Tecnica di scansione predefinita Nmap

score 3 · Accepted Answer

Maps on the Internet showed that the focus of the Dyn DDoS attack was on the East Coast of the US. But why?

Questo perché la prima ondata di attacchi è avvenuta principalmente sulla costa orientale Chicago, Washington D.C. e New York dove sono presenti tre data center DNS di Dyn.

My DNS is 8.8.8.8 (Google Public DNS). Yet when I tried to reach twitter.com, my computer could not resolve the name. Suppose the DNS TTL expired and Google had to issue a recursive query that landed eventually at Dyn, which perhaps is the authoritative DNS for twitter. (Is that true?)

Hai assolutamente ragione che questo potrebbe essere successo, le voci della cache DNS di Google potrebbero essere scadute e ha dovuto eseguire una query ricorsiva a un server Dyn DNS non rispondente, ecco perché:

Sei in Colorado, collegato a qualche XYZ ISP. Quando provi ad aprire twitter.com. La macchina tenta di ottenere l'indirizzo IP da 8.8.8.8 che è il DNS che si sta utilizzando nel proprio computer.
Ora 8.8.8.8 non appartiene a XYZ ISP appartiene a Google che potrebbe essere in Colorado o altrove (forse sulla costa orientale), Anche se 8.8.8.8 è o sarebbe stato in Colorado, il tuo ISP potrebbe non essere collegato ad esso (direttamente). Quindi potrebbe ancora ottenere il miglior percorso (a 8.8.8.8) da qualche altra parte (forse dalla costa est). Punto di saturazione: esiste un numero N di server DNS pubblico di Google localizzato in posizioni diverse e non si sa a quale si sta effettuando una query (che dipende dal percorso migliore a 8.8.8.8 dal proprio ISP) si tratta di un concetto di anycasting in cui lo stesso Gli indirizzi IP sono situati in più punti per fornire una maggiore disponibilità di servizio.
Supponiamo di raggiungere 8.8.8.8 con la tua query e come hai detto il TTL per twitter.com è scaduto. Ora 8.8.8.8 deve fare una query ricorsiva per ottenere l'indirizzo di twitter.com, Quindi deve passare attraverso un processo di richiesta di Root Name Server - > gTLD - > Root server di twitter.com (in questo caso Dyn ha ospitato) i seguenti server che ottiene dalla query 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

Notate che ci sono quattro server dei nomi per twitter.com, che diranno 8.8.8.8 qual è l'IP di twitter.com , Ora ovviamente Dyn vorrebbe avere più sedi dello stesso server dei nomi (anycasting, proprio come il DNS pubblico di google) e vorrebbe anche i name server in luoghi diversi (forse alcuni sulla costa est, alcuni ad ovest o anche alcuni fuori dagli Stati Uniti)

Quindi di nuovo quando 8.8.8.8 esce per interrogare uno di questi server dei nomi può o meno andare ai server della costa orientale, che dipende interamente da: qual è il percorso migliore per questi server (o meglio gli IP) di questi server)

Conclusione: twitter.com non funzionava con XYZ ISP in Colorado quando l'attacco era sulla costa est sarebbe successo perché o stavate interrogando un server 8.8.8.8 che si trovava nella costa est, che era interno interrogando i server colpiti dalla costa orientale Dyn (a causa della sua vicinanza e ottenendo il miglior percorso da lì) O il 8.8.8.8 (che potrebbe ancora essere sulla costa occidentale) avrebbe comunque dovuto interrogare i server interessati dalla costa orientale della Dyn a causa del percorso migliore da lì. Quindi anche io, seduto in India, potrei non ottenere twitter.com (anche se altamente improbabile, a causa dell'elevata quantità di ridondanze) proprio per lo stesso motivo.