La Fibre
Télécom => Réseau => 
Attaques informatiques => Discussion démarrée par: BadMax le 21 octobre 2016 à 16:16:42
-
EDIT: Fusion du sujet "DNS: Twitter.com" suite au retour de l'attaque vers 18h00 (heure de Paris)
1ère attaque le 21/10/2016
https://krebsonsecurity.com/2016/10/ddos-on-dyn-impacts-twitter-spotify-reddit/
Le site attaqué est Dyn, un hosteur DNS : https://www.dynstatus.com/incidents/nlr4yrr162t8
L'attaque est terminée depuis 13h20 UTC
Update: liste des sites impactés sur http://gizmodo.com/this-is-probably-why-half-the-internet-shut-down-today-1788062835
ActBlue
Basecamp
Big cartel
Box
Business Insider
CNN
Cleveland.com
Esty
Github
Grubhub
Guardian.co.uk
HBO Now
Iheart.com (iHeartRadio)
Imgur
Intercom
Intercom.com
Okta
PayPal
People.com
Pinterest
Playstation Network
Recode
Reddit
Spotify
Squarespace Customer Sites
Starbucks rewards/gift cards
Storify.com
The Verge
Twillo
Twitter
Urbandictionary.com (lol)
Weebly
Wired.com
Wix Customer Sites
Yammer
Yelp
Zendesk.com
Zoho CRM
Update2: Carte de l'impact d'après Level3
(http://static2.uk.businessinsider.com/image/580a17a7dd089523498b4c8d-1030/screen%20shot%202016-10-21%20at%209.22.54%20am.png)
2ème attaque vers 16h00 UTC
Update 20h20: Carte de l'impact d'après Level3
-
Bonsoir,
Je ne parviens plus du tout à accéder à https://twitter.com.
Aucun srv DNS ne résout le domaine.
Est-ce pareil chez vous?
Cdt,
DamienC
-
DynDNS est tombé, du coup... :/
[hugues@atlantis:~] dig twitter.com +trace
; <<>> DiG 9.8.3-P1 <<>> twitter.com +trace
;; global options: +cmd
. 347387 IN NS k.root-servers.net.
. 347387 IN NS c.root-servers.net.
. 347387 IN NS f.root-servers.net.
. 347387 IN NS j.root-servers.net.
. 347387 IN NS l.root-servers.net.
. 347387 IN NS b.root-servers.net.
. 347387 IN NS h.root-servers.net.
. 347387 IN NS e.root-servers.net.
. 347387 IN NS d.root-servers.net.
. 347387 IN NS i.root-servers.net.
. 347387 IN NS m.root-servers.net.
. 347387 IN NS a.root-servers.net.
. 347387 IN NS g.root-servers.net.
;; Received 508 bytes from 2001:470:1f13:5c1::16#53(2001:470:1f13:5c1::16) in 18 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
;; Received 501 bytes from 193.0.14.129#53(193.0.14.129) in 55 ms
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.
;; Received 179 bytes from 192.12.94.30#53(192.12.94.30) in 63 ms
IRC marche toujours sinon, donc tout va bien ::)
-
Sujet à fusionner avec https://lafibre.info/attaques/ddos-contre-twitter-spotify-reddit/ non ?
-
L'attaque est terminée depuis 13h20 UTC
J'ai fais un autre sujet car je pense qu'il s'agit d'un autre problème?
-
Chez Bouygues Telecom (en 4G, je suis dans le RER) cela ne fonctionne pas non plus.
$ ping twitter.com
ping: twitter.com: Nom ou service inconnu
-
A mon avis c'est juste la même attaque qui reprend de plus belle. GitHub est tombé aussi, globalement ça a de gros impacts.
-
Selon les infos que j'ai récup sur IRC, ils s'attaquent aux serveurs EU de Dyn.
-
à paste dans un fichier hosts si vous voulez twitter :
199.59.148.10 *.twitter.com
199.59.148.10 twitter.com
93.184.220.70 pbs.twimg.com
104.244.43.39 abs.twimg.com
104.244.43.103 ton.twimg.com
104.244.42.3 analytics.twitter.com
104.244.42.5 t.co
-
104.244.42.1 twitter.com
199.16.156.7 tweetdeck.twitter.com
192.229.173.16 abs.twimg.com pbs.twimg.com
104.244.43.39 ton.twimg.com
199.16.156.11 t.co
-
Un jour je vous apprendrai :
(http://image.noelshack.com/fichiers/2016/42/1477068967-swag.png)
-
C'est quoi ce truc ?
-
J'ai pas compris... Comme d'hab quoi.
-
Moi non plus...
-
Semblerait que les DNS de Google marchent encore sans souci sinon.
-
J'ai pas compris... Comme d'hab quoi.
Faut tout vous dire ou quoi ? :
(https://i.gyazo.com/2adeec238dca6906788728174e7aaf47.png)
-
C'est bien, mais bon y a la solution 2 posts plus haut... Tu veux une médaille ou c'est pour le plaisir d'être ridicule ?
-
Surtout que c'est Tweeter qui a changé de hosting:
badmax@batou:~$ host -t ns tweeter.com
tweeter.com name server ns1.sedoparking.com.
tweeter.com name server ns2.sedoparking.com.
EDIT: je suis un boulet, faut que j'apprenne à taper
-
attention, twitter n'est pas tweeter :)
-
Faut tout vous dire ou quoi ? :
(https://i.gyazo.com/2adeec238dca6906788728174e7aaf47.png)
Je vois juste un ping de merde.
-
Donc c'est bien l'attaque qui a repris, prenons les DNS :
badmax@batou:~$ host -t ns twitter.com
twitter.com name server ns2.p34.dynect.net.
twitter.com name server ns4.p34.dynect.net.
twitter.com name server ns3.p34.dynect.net.
twitter.com name server ns1.p34.dynect.net.
NS2 et NS4 ne répondent plus, un traceroute vers leurs IP nous emmènent sur la côte Est des US.
NS1 et NS3 semblent aux Pays-bas.
-
Donc c'est bien l'attaque qui a repris, prenons les DNS :
badmax@batou:~$ host -t ns twitter.com
twitter.com name server ns2.p34.dynect.net.
twitter.com name server ns4.p34.dynect.net.
twitter.com name server ns3.p34.dynect.net.
twitter.com name server ns1.p34.dynect.net.
NS2 et NS4 ne répondent plus, un traceroute vers leurs IP nous emmènent sur la côte Est des US.
NS1 et NS3 semblent aux Pays-bas.
C'est censé être anycast; les 4 NS m'envoient vers Palo Alto via différents transitaires (d'Orange)
-
NS2 et NS4 semblent en effet vers Palo Alto, je n'avais pas suffisamment attendu le résultat de mtr et traceroute, ça drop sur les derniers hops.
-
Ça remarche au ralenti j'ai l'impression.
Par contre, pendant que sur mon PC, Twitter ne fonctionnait pas, sur mon smartphone (Android) il fonctionnait, des amis postaient même des Tweets sans problèmes. ???
EDIT : Il semblerait que le site abs.twimg.com ne fonctionne pas, Twitter sans CSS c'est... :-X
-
En fait, ça dépend sur quel DNS tu pointes : ceux en Europe répondent.
Côté PSN, c'est pas la joie. Xbox Live n'affiche pas de problème sur la page d'accueil.
-
Une personne m'avait fait connaître se site, qui est très bon pour connaître les NS et l'IP sur lesquels un site pointe.
https://www.whatsmydns.net/#NS/twitter.com
Je vois que le serveur Ouest des USA est down :/
-
Tu ne regardes pas comme il faut ! Les glue records des DNS on s'en fiche là, ils sont par terre, c'est le A qui est important. https://www.whatsmydns.net/#A/twitter.com
-
Tant que le AAAA est présent... ;D
(J'ai l'impression que c'est pire en IPv6 sur leur carte)
-
Twitter est dispo en IPv6 ? me semblait que le site ne marchait pas en v6 only.
-
Y'a pas beaucoup de site qui marche en v6 only. P'tet même aucun.
-
les 3/4 des sites IPv6 que je croise :)
-
Il me semble qu'une partie des sites de Google fonctionnent parfaitement en absence de connectivité IPv4.
LaFibre.info devrait aussi fonctionner, elle fait pas appel a trop de sites tiers.
Il faudrait que je m'amuse de nouveau à couper IPv4 pour voir... (il suffit de déclarer à la main IPv6 dans /etc/network/interfaces et de commenter l'IPv4)
-
Ah non Google ne fonctionne pas en v6 only -> les NS de Google.fr sont en v4 :)
Donc il faut encore une connectivité v4 quelque part pour les trouver :)
-
Enfin, si tu as un PC avec une connectivité IPv6 uniquement et qui utilise un ré-solveur DNS externe (par exemple 2001:4860:4860::8888, c'est google DNS ou 2001:910:800::12 pour FDN) tu devrais surfer sur de nombreux sites IPv6.
-
Des tests que j'ai fait, ne répondent pas Twitter et PayPal depuis les DNS Google, Level3, FDN, Oxid.
Répondent sur mes DNS qui utilisent OpenNIC et pour les domaines ICANN ça tourne entre OpenNIC, Level3, DNS.watch et les root.
Pour ceux qui veulent, mes résultats DNS:
;; QUESTION SECTION:
;twitter.com. IN A
;; ANSWER SECTION:
twitter.com. 992 IN A 104.244.42.129
twitter.com. 992 IN A 104.244.42.1
;; AUTHORITY SECTION:
twitter.com. 327 IN NS ns1.p34.dynect.net.
twitter.com. 327 IN NS ns2.p34.dynect.net.
twitter.com. 327 IN NS ns3.p34.dynect.net.
twitter.com. 327 IN NS ns4.p34.dynect.net.
;; ADDITIONAL SECTION:
ns1.p34.dynect.net. 257 IN A 208.78.70.34
ns2.p34.dynect.net. 5602 IN A 204.13.250.34
ns3.p34.dynect.net. 257 IN A 208.78.71.34
ns4.p34.dynect.net. 5602 IN A 204.13.251.34
;; Query time: 15 msec
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;paypal.com. IN A
;; ANSWER SECTION:
paypal.com. 861 IN A 64.4.250.23
paypal.com. 861 IN A 64.4.250.24
;; AUTHORITY SECTION:
com. 4188 IN NS i.gtld-servers.net.
com. 4188 IN NS d.gtld-servers.net.
com. 4188 IN NS b.gtld-servers.net.
com. 4188 IN NS f.gtld-servers.net.
com. 4188 IN NS k.gtld-servers.net.
com. 4188 IN NS c.gtld-servers.net.
com. 4188 IN NS g.gtld-servers.net.
com. 4188 IN NS l.gtld-servers.net.
com. 4188 IN NS j.gtld-servers.net.
com. 4188 IN NS e.gtld-servers.net.
com. 4188 IN NS a.gtld-servers.net.
com. 4188 IN NS m.gtld-servers.net.
com. 4188 IN NS h.gtld-servers.net.
;; ADDITIONAL SECTION:
a.gtld-servers.net. 2425 IN A 192.5.6.30
a.gtld-servers.net. 2425 IN AAAA 2001:503:a83e::2:30
b.gtld-servers.net. 4574 IN A 192.33.14.30
b.gtld-servers.net. 4574 IN AAAA 2001:503:231d::2:30
c.gtld-servers.net. 4119 IN A 192.26.92.30
d.gtld-servers.net. 1343 IN A 192.31.80.30
e.gtld-servers.net. 1515 IN A 192.12.94.30
f.gtld-servers.net. 2528 IN A 192.35.51.30
g.gtld-servers.net. 3906 IN A 192.42.93.30
h.gtld-servers.net. 4979 IN A 192.54.112.30
i.gtld-servers.net. 3494 IN A 192.43.172.30
j.gtld-servers.net. 3884 IN A 192.48.79.30
k.gtld-servers.net. 739 IN A 192.52.178.30
l.gtld-servers.net. 739 IN A 192.41.162.30
m.gtld-servers.net. 828 IN A 192.55.83.30
;; Query time: 16 msec
-
Peering Twitter chez K-net :
(https://lafibre.info/images/k-net/201610_twitter_k-net.png)
-
Il y a peut-être un reste de TTL parce qu'ils ont pas l'air en bonne santé quand même :
Authoritative answers can be found from:
twitter.com nameserver = ns4.p34.dynect.net.
twitter.com nameserver = ns1.p34.dynect.net.
twitter.com nameserver = ns3.p34.dynect.net.
twitter.com nameserver = ns2.p34.dynect.net.
ns1.p34.dynect.net internet address = 208.78.70.34
ns1.p34.dynect.net has AAAA address 2001:500:90:1::34
ns2.p34.dynect.net internet address = 204.13.250.34
ns3.p34.dynect.net internet address = 208.78.71.34
ns3.p34.dynect.net has AAAA address 2001:500:94:1::34
ns4.p34.dynect.net internet address = 204.13.251.34
> server ns1.p34.dynect.net
Default server: ns1.p34.dynect.net
Address: 208.78.70.34#53
Default server: ns1.p34.dynect.net
Address: 2001:500:90:1::34#53
> set all
Default server: ns1.p34.dynect.net
Address: 208.78.70.34#53
Default server: ns1.p34.dynect.net
Address: 2001:500:90:1::34#53
Set options:
novc nodebug nod2
search recurse
timeout = 0 retry = 3 port = 53 ndots = 1
querytype = any class = IN
srchlist = local
> set q=any
> twitter.com
;; connection timed out; no servers could be reached
-
Beaucoup de bruit médiatique pendant lequel AT&T tente de racheter Time Warner ... coincidence ? :P
-
L'impact pour Bouygues Telecom est sur AMS-IX, Equinix Internet Exchange Paris et le peering privé avec Edgecast :
-
Soit l'attaque a cessée, soit ils ont trouvé une solution (ou les deux ?) : les DNS de Dyn répondent à nouveau et certaines zones ont été modifiées.
-
Cela réponds de nouveau.
> twitter.com
;; Truncated, retrying in TCP mode.
Server: ns3.p34.dynect.net
Address: 208.78.71.34#53
twitter.com
origin = ns1.p26.dynect.net
mail addr = zone-admin.dyndns.com
serial = 2007130853
refresh = 3600
retry = 600
expire = 604800
minimum = 60
twitter.com mail exchanger = 30 ASPMX2.GOOGLEMAIL.COM.
twitter.com mail exchanger = 20 alt1.aspmx.l.google.com.
twitter.com mail exchanger = 30 ASPMX3.GOOGLEMAIL.COM.
twitter.com mail exchanger = 10 aspmx.l.google.com.
twitter.com mail exchanger = 20 alt2.aspmx.l.google.com.
twitter.com nameserver = ns3.p34.dynect.net.
twitter.com nameserver = ns1.p34.dynect.net.
twitter.com nameserver = ns2.p34.dynect.net.
twitter.com nameserver = ns4.p34.dynect.net.
Name: twitter.com
Address: 199.59.149.198
Name: twitter.com
Address: 199.59.150.7
Name: twitter.com
Address: 199.16.156.70
Name: twitter.com
Address: 199.16.156.38
Name: twitter.com
Address: 199.59.148.10
Name: twitter.com
Address: 199.16.156.6
Name: twitter.com
Address: 199.16.156.102
Name: twitter.com
Address: 199.16.156.230
Name: twitter.com
Address: 199.16.156.198
Name: twitter.com
Address: 199.59.150.39
Name: twitter.com
Address: 199.59.148.82
Name: twitter.com
Address: 199.59.149.230
twitter.com text = "v=spf1 ip4:199.16.156.0/22 ip4:199.59.148.0/22 ip4:8.25.194.0/23 ip4:8.25.196.0/23 ip4:204.92.114.203 ip4:204.92.114.204/31 ip4:23.21.83.90 include:_spf.google.com include:_thirdparty.twitter.com -all"
twitter.com text = "google-site-verification=h6dJIv0HXjLOkGAotLAWEzvoi9SxqP4vjpx98vrCvvQ"
>
-
Question aux spécialistes : ce soir j'ai du redémarrer mon netgear r7000 (en mode point d'accès ) pour pouvoir accéder de nouveau à Twitter sur le wifi. Par contre le pc fixe en ethernet sur la livebox fonctionnait.
Hazard ou lien ?
-
Les 2 DNS HS de la zone twitter.com qui étaient à Palo Alto répondent désormais à Frankfort: 204.13.250.34 et 204.13.251.34
-
Question aux spécialistes : ce soir j'ai du redémarrer mon netgear r7000 (en mode point d'accès ) pour pouvoir accéder de nouveau à Twitter sur le wifi. Par contre le pc fixe en ethernet sur la livebox fonctionnait.
Hazard ou lien ?
Il y a certainement un lien, comme c'est instable,c'est difficile de répondre,cela dépends de pas mal de paramètres.
-
> twitter.com
;; Truncated, retrying in TCP mode.
Mais c'est pas encore ça...
-
J'ai forcé le TTL élevé sur mes DNS pour les sites impactés, je sais que c'est pas bien (RFC-1912 je crois) mais pour garder un certain niveau de qualité pour mes users faut faire des sacrifices :p
(en recherchant le nom de la RFC, je pense avoir trouvé la source du soucis : http://www.bortzmeyer.org/forcer-ttl.html
En plus des DDoS, dyn utiliserait un TTL trop bas...)
-
Complètement transparent pour moi qui tape chez Google (8.8.8.8, pas de problème constatée. Oui c'est mal je sais btw .. Mais bon je leur fais confiance pour marcher le bouzin a défaut de garder ma vie privée intacte ^^
-
Oui enfin là même avec 8.8.8.8 ou un résolveur perso c'était down pour une bonne partie des gens !
-
Il serait aussi possible à Google de rajouter à la main les entrées en absence de réponse (si absence de réponse, utiliser les derniers enregistrements DNS connus)
Ce type de comportement permettrait d'éviter que des attaques DDOS sur l'infra DNS aient trop d'impacts sur les gros résolveurs.
-
Question aux spécialistes : ce soir j'ai du redémarrer mon netgear r7000 (en mode point d'accès ) pour pouvoir accéder de nouveau à Twitter sur le wifi. Par contre le pc fixe en ethernet sur la livebox fonctionnait.
Hazard ou lien ?
Tu es sûr que ton routeur Netgear R7000 n'a pas été hacké, et ne sert pas à l'attaque présente ? Parmi les objets participant aux attaques, il y a bien sûr beaucoup de cameras de videosurveillance pas mises à jour et utilisées en botnet, mais aussi de home routeurs. Voir le lien de krebs sur le premier sujet.
Tu as mis le firmware à jour quand sur ton routeur ? Comme l'injection tient en mémoire, le rebooter permet de reprendre le contrôle, jusqu'au prochain hack.
Voir :
https://blog.sucuri.net/2016/09/iot-home-router-botnet-leveraged-in-large-ddos-attack.html
-
Je viens de modifier le titre, le DDoS étant contre DYN et pas Twitter/Spotify/reddit.
-
Il serait aussi possible à Google de rajouter à la main les entrées en absence de réponse (si absence de réponse, utiliser les derniers enregistrements DNS connus)
Ce type de comportement permettrait d'éviter que des attaques DDOS sur l'infra DNS aient trop d'impacts sur les gros résolveurs.
C'est une violation des RFC et du principe des DNS, ça ^^
-
Ce serait pas le premier DNS à mentir !
-
Tu es sûr que ton routeur Netgear R7000 n'a pas été hacké, et ne sert pas à l'attaque présente ? Parmi les objets participant aux attaques, il y a bien sûr beaucoup de cameras de videosurveillance pas mises à jour et utilisées en botnet, mais aussi de home routeurs. Voir le lien de krebs sur le premier sujet.
Tu as mis le firmware à jour quand sur ton routeur ? Comme l'injection tient en mémoire, le rebooter permet de reprendre le contrôle, jusqu'au prochain hack.
Voir :
https://blog.sucuri.net/2016/09/iot-home-router-botnet-leveraged-in-large-ddos-attack.html
Sur non mais Je fais un minimum attention : firmware a jour et login admin remplacé, mdp aléatoire
-
Il me semble que tu as pris les précautions nécessaires, et tu ne devrais pas être concerné par un hacking (bien que l'on ne sait jamais, faille non corrigée etc..).
-
Oui enfin là même avec 8.8.8.8 ou un résolveur perso c'était down pour une bonne partie des gens !
Résolveur perso qui tape les ROOT= 0 impact de mon côté, même pas un ralentissement.
-
Moi, avec 3 résolveurs qui tapent les Root, chez K-Net : Mort à partir des DNS de dyn.
-
Si tout le monde tapait les root, ils ne tarderaient pas à tomber... Ce n'est quand même pas pour rien qu'il y a une hiérarchie DNS (même si bien sûr, les DNS root ont été renforcés pour éviter qu'ils tombent). A mon avis, ce n'est pas une bonne pratique.
-
Résolveur perso qui tape les ROOT= 0 impact de mon côté, même pas un ralentissement.
Pareil que Hugues, j'ai tweetdeck qui a continué de fonctionner sur mon PC mais Twitter.com et l'appli iOS étaient down.
-
Si tout le monde tapait les root, ils ne tarderaient pas à tomber...
Avec des si, on mettrait Paris en bouteille.
-
Si tout le monde tapait les root, ils ne tarderaient pas à tomber...
1/ ça n'arrivera jamais, madame michu ne sait pas ce que c'est. ;D
2/ de plus en plus root sont en anycast, et sont largement surdimensionnés (pour faire face à une attaque)
3/ sur un serveur DNS bien configuré, tu tape les root assez rarement, quand même.
cf : https://fr.wikipedia.org/wiki/Serveur_racine_du_DNS :)
-
Si tout le monde tapait les root, ils ne tarderaient pas à tomber... Ce n'est quand même pas pour rien qu'il y a une hiérarchie DNS (même si bien sûr, les DNS root ont été renforcés pour éviter qu'ils tombent). A mon avis, ce n'est pas une bonne pratique.
Attention, "Taper les root"=avoir son propre bind qui va chercher la réponse et gère son propre cache -> comportement normal de DNS
Je n'ai pas mis les ROOT en resolveur de mes machines.
Taper les ROOT ça a aussi des inconvénients : la résolution de Facebook me renvoie sur les US, j'ai été obligé de forward sur les NS de Free pour avoir une résolution France/EU. Y'a quelques autres sites où ça fait pareil, je ne vois pas les CDN EU.
Après, heureusement que les ROOT sont prévus pour encaisser de grosses charges sinon l'impact serait bien pire qu'hier soir.
-
OK, je préfère cela, ce n'est pas ce que j'avais compris. Donc tu as un résolveur local, tout simplement.
-
cf : https://fr.wikipedia.org/wiki/Serveur_racine_du_DNS :)
Oui, en fait :
Les serveurs racine sont non-récursifs, c'est-à-dire qu'ils ne fournissent que des réponses qui font autorité, ne transmettent aucune requête à un autre serveur et ne font pas usage d'un cache. Ils ne sont donc pas utilisables directement par un resolver d'un client final.
Donc de toute façon, on ne peut pas les utiliser directement, heureusement...
-
Ce serait pas le premier DNS à mentir !
Conserver une valeur de cache obsolète qu'on n'arrive pas à revalider est un pieu mensonge!!!
-
La première chose à faire c'est d'utiliser le DNS comme il a été conçu déjà : pas centralisé par une même boîte.
-
La première chose à faire c'est d'utiliser le DNS comme il a été conçu déjà : pas centralisé par une même boîte.
Je partage cette opinion, d'autant que les structures qui ont été impactées ont les moyens financiers d'assurer la gestion de cet élèment qui est stratégique pour leur activité.
Cela dit,il va nécessairement avoir cette réflexion dans les comités exécutifs des sociétés impactées.
La transparence de DYN a été exemplaire à ce sujet,je crains que cela ne suffise pas à ne pas perdre certains clients.
-
La première chose à faire c'est d'utiliser le DNS comme il a été conçu déjà : pas centralisé par une même boîte.
c'est bien pour des trucs statiques avec un gros TTL. Des que tu commences à avoir des durées de vie plus courte ou des entrées dynamiques a la demande c'est souvent plus simple de n'avoir qu'un prestataire et d'utiliser son API.
Mais il est vrai "twitter.com" ca ne devrait pas être juste un seul prestataire...
Apres le probleme ici c'est plus Dyn (le prestation donc) qui n'est pas résilient a une attaque DDoS. Ca c'est plus inquiétant. Quand on lit leur offre de service on s'attend a un truc tres distribué et adaptable aux conditions des réseaux...
-
twitter.com ne fait pas d'IPv6 et apparement n'est pas non plus capable de faire du DNS, donc beauf.
-
Compte-rendu de Dyn: http://hub.dyn.com/static/hub.dyn.com/dyn-blog/dyn-statement-on-10-21-2016-ddos-attack.html
En gros, "c'était dur mais on a plutôt bien géré, merci à nos clients (s'il-vous-plait restez)".
Rien sur la volumétrie ou la nature de l'attaque. Rien sur les correctifs déployés (IP déplacés sur AMS pour l'EU par exemple).
Conclusion, ils en ont pris plein la tronche et ont galéré à restaurer le service.
-
Mouais ça dit pas grand chose, ça donne les impacts, ça dit que c'est beaucoup des botnet Mirai sur IoT, mais techniquement aucune info sur l'attaque et leurs contraintes, donc peu d'intérêt.
-
Il serait aussi possible à Google de rajouter à la main les entrées en absence de réponse (si absence de réponse, utiliser les derniers enregistrements DNS connus)
Ce type de comportement permettrait d'éviter que des attaques DDOS sur l'infra DNS aient trop d'impacts sur les gros résolveurs.
Mais si par exemple un site ferme, l'IP serait encore présente et ça pourrait rediriger sur un site malveillant.
Ce serait pas le premier DNS à mentir !
Des noms! Des noms! On veut des noms!
-
Dans le même genre, une extension Chrome : https://chrome.google.com/webstore/detail/siderites-dns-resolver/fjjomhepnnicmnkfiopeimfpdbpegboa?utm_source=chrome-app-launcher-info-dialog
(c'est à toi d'ajouter un site au host si il y a un soucis, il enregistre ses précédentes IPs)
-
À vendre, botnet neuf, servi une fois
http://www.forbes.com/sites/thomasbrewster/2016/10/23/massive-ddos-iot-botnet-for-hire-twitter-dyn-amazon/#1d6bf4b2c915
-
To Bring Down The Web
Argumentum ad metum FUD
-
Mais si par exemple un site ferme, l'IP serait encore présente et ça pourrait rediriger sur un site malveillant.
Je pense qu'il veut dire conserver le RR pendant des heures, pas pendant des mois!