Journal dDoS contre les serveurs DNS

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
58
15
déc.
2015

Il y a des tas d'articles sur LinuxFr qui parlent de dDoS, puisqu'elles sont une des plaies de l'Internet d'aujourd'hui, et que tout le monde a eu à gérer une « attaque par déni de service répartie » au moins une fois.

Ce court journal parle de deux attaques récentes visant des serveurs DNS. En effet, si on veut planter un service Internet (Web, IRC, etc), attaquer ses serveurs DNS est souvent plus simple et plus efficace que d'attaquer le service lui-même. Peu connu, et donc peu financé, le DNS est souvent le maillon faible dans la sécurité.

En outre, un TLD (domaine de tête) national étant un des symboles d'un pays, attaquer ce TLD peut être tentant si on a un désaccord avec ce pays, comme dans l'un des exemples ci-dessous.

Attention, je parle bien d'attaques contre les serveurs DNS, pas des attaques utilisant les serveurs DNS, comme le sont les attaques par réflexion.

La première attaque est celle qui a visé les serveurs de la racine du DNS les 30 novembre et 1er décembre. Par ses effets (plusieurs serveurs ont cessé de répondre), c'est la plus grosse attaque contre la racine depuis 2002. Elle a même stoppé des serveurs anycastés (répartis sur plusieurs sites physiques). À noter qu'on ignore l'identité de l'attaquant, ou ses motivations.

Attention, pas mal de gens (comme d'habitude) ont raconté n'importe quoi sur cette attaque, donc prudence.

Au plus fort de l'attaque, le 30 novembre, vers 08200 UTC. Trois des serveurs ne répondent pas :

% check-soa -4 -i .
a.root-servers.net.
        198.41.0.4: OK: 2015113000 (23 ms)
b.root-servers.net.
        192.228.79.201: ERROR: Timeout
c.root-servers.net.
        192.33.4.12: OK: 2015113000 (23 ms)
d.root-servers.net.
        199.7.91.13: OK: 2015113000 (9 ms)
e.root-servers.net.
        192.203.230.10: OK: 2015113000 (23 ms)
f.root-servers.net.
        192.5.5.241: OK: 2015113000 (4 ms)
g.root-servers.net.
        192.112.36.4: ERROR: Timeout
h.root-servers.net.
        128.63.2.53: ERROR: Timeout
i.root-servers.net.
        192.36.148.17: OK: 2015113000 (18 ms)
j.root-servers.net.
        192.58.128.30: OK: 2015113000 (15 ms)
k.root-servers.net.
        193.0.14.129: OK: 2015113000 (348 ms)
l.root-servers.net.
        199.7.83.42: OK: 2015113000 (10 ms)
m.root-servers.net.
        202.12.27.33: OK: 2015113000 (2 ms)

La seconde est celle qui a stoppé le TLD turc, .tr, le 14 décembre. Il est rare qu'une attaque mène à l'interruption de service d'un TLD entier. Là non plus, l'attaquant n'a pas laissé sa carte de visite, mais, vue la situation géopolitique, et l'utilisation de dDoS par un certain pays contre ses voisins, difficile de ne pas penser à un pays qui vient de perdre un avion, descendu par l'armée turque.

  • # le maillon faible ?

    Posté par  . Évalué à 6.

    Bonsoir,

    Post intéressant, mais est-ce que les serveurs DNS sont-t-ils vraiment les maillons faibles de la sécurité d'un service ?

    Dans le sens où si l'on souhaite attaquer un service et que l'on a le choix entre le service lui-même ou les serveurs DNS du service, attaquer les premiers peut avoir un impact direct sur la qualité du service alors qu'une attaque sur un serveur DNS n'impacterait que les clients qui l'interroge, et avec le système de cache du DNS ces requêtes sont relativement rares (par rapport aux requêtes que doivent gérer les serveurs du même service). Pour toucher la totalité des clients ne faudrait-t-il pas que l'attaque dure autant de temps que le TTL de l'enregistrement DNS comme je le pense (je prend comme référence le TTL de votre blog qui est d'environ 24h) ? Après il est vrai que si le résolveur DNS d'un FAI par exemple n'arrive pas à contacter le serveur DNS du service, cela risque de toucher de très nombreuses personnes et qu'il est peut-être plus facile de faire tomber les serveurs DNS d'un service que le service lui-même.

    Des attaques DDOS sur les serveurs DNS d'un service sont-t-elles réellement courantes ? Et si oui, réussissent-t-elles et dans quelle proportion ? Le coût en temps et en bande passante est-t-il rentable pour un attaquant ?

    ps : Le cas présenté dans le journal est tout de même bien différent puisqu'il mentionne des attaques sur des serveurs qui servent un TLD entier.

    • [^] # Re: le maillon faible ?

      Posté par  . Évalué à -4.

      les attaque des serveurs root DNS me laisse dubitatif.
      C'est tellement simple de limiter la casse.
      "Normalement" seul les fai requetent les serveurs root pour alimenter leurs caches et les clients requetent les caches des fai. Je sais pas vraiment comment les fai gèrent ça mais ça me parait assez simple à gérer:

      si ttl dns expiré et que root repond
      alors
      update du cache
      sinon si ttl dns expiré et que root repond pas
      alors
      on update pas le cache => aucune action
      sinon si ttl dns expiré et que root repond pas depuis plus d'1h
      on update pas le cache et on droppe les requêtent dns de nos clients vers les serveurs root histoire de couper l'herbe sous le pied des botnets et de réduire la charge des root DNS.
      sinon
      aucune action

      Au pire ça peut ralentir la propagation des nouveaux enregistrements/update mais bon si les root ne répondent pas … Il faut vraiment que l'attaque dure looongtemps pour avoir un impact. En tout cas je n'ai jamais vu d'impact des attaques sur les root DNS. En 2002 j'étais au courant pendant (mais j'ai rien ressenti) là je viens de l'apprendre…

      • [^] # Re: le maillon faible ?

        Posté par  . Évalué à 8.

        Ton algo est dangereux… un enregistrement expiré ne doit pas être reservi, donc si TTL expiré et que root ne répond pas, alors on répond par un NXDOMAIN, mais certainement pas avec l'ancien enregistrement.

        Pourquoi ? Pour éviter de foutre la grouille dans une procédure de migration qui serait en cours par exemple :-)

      • [^] # Re: le maillon faible ?

        Posté par  (site web personnel, Mastodon) . Évalué à 10.

        Il y a des dizaines d'ingénieurs très pointus qui travaillent sur les serveurs racine et je ne sais pas combien de millions de dollars sont dépensés, alors qu'il suffisait de lire LinuxFr, où on apprend que « c'est tellement simple de limiter la casse » :-)

        Autrement, l'algorithme est mauvais, pour les raisons expliquées par Gérald.

    • [^] # Re: le maillon faible ?

      Posté par  (site web personnel) . Évalué à 5.

      Pour toucher la totalité des clients ne faudrait-t-il pas que l'attaque dure autant de temps que le TT

      Une grosse partie (dirais-je la majorité ?) des sites utilisent des TTL compris entre 1h30 et 1mn (15mn par exemple pour linuxfr) ce qui n'est en rien une durée exceptionnelle pour les attaques DOS.

      Le compromis entre sécurité et souplesse est toujours délicat à trouver.

    • [^] # Re: le maillon faible ?

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      « Pour toucher la totalité des clients ne faudrait-t-il pas que l'attaque dure autant de temps que le TTL de l'enregistrement DNS » Non. Prenons l'exemple de .fr. Le TTL de l'ensemble d'enregistrements NS est de 48 h. Mais les requêtes arrivent en permanence. Si la racine est en panne et que, par malchance, votre résolveur avait mis en cache l'information il y a 47 h et 59 m, vous allez avoir un problème.

      En cas de panne de la racine, si elle dure une heure, 1/48 % des résolveurs auront un problème avec .fr. Si la panne dure trois heures, ce sera 3/48 %.

      Et c'est pire pour les TLD rares et peu utilisés, qui ne sont pas souvent dans le cache.

      « Des attaques DDOS sur les serveurs DNS d'un service sont-t-elles réellement courantes ? » Non. Mais pas forcément parce qu'elles sont inefficaces. Les attaquants ne sont pas des dieux et n'utilisent pas forcément toutes les méthodes.

    • [^] # Re: le maillon faible ?

      Posté par  . Évalué à 5.

      Les DDOS contre les DNS ne sont pas courants.

      Par contre s'attaque aux serveurs racines c'est un bon moyen de mesurer sa bistou benchmarker son artillerie. L'avantage c'est que la cible ne tombe jamais. Ensuite, cela fait bien sur une carte de visite de location de botnet de dire que tu peux descendre n'importe quel site -chiffre à l'appui - sur le net. Sauf erreur il y a 8 ans l'attaque contre les serveurs racines avait entraîné une charge d'1Gb/, la connexion quotidienne de certaines personnes maintenant…

      Avec une telle force de frappe (200-400Gb/s) c'est plus facile d'aller rançonner un site web (ex. protonmail) ou de faire des coups politique/médiatique (CIA, OTAN, Ukraine)

      Mais personne n'aurait avantage à faire tomber tout les serveur racines.

      Je trolle dès quand ça parle business, sécurité et sciences sociales

  • # Retour vers le futur

    Posté par  (site web personnel) . Évalué à 2.

    La seconde attaque a eu lieu le 14 décembre et non le 14 novembre !

  • # check-soa ?

    Posté par  (site web personnel) . Évalué à 3.

    Merci pour ce compte rendu et pour les liens. Même si ce n'est pas le genre d'opération qu'un administrateur réseau doit avoir à gérer souvent, c'est toujours bon de savoir ce que font les autres.

    Une question : d'où vient la commande check-soa ? À ma connaissance ce n'est pas un outil proposé par BIND ou Unbound. Est-ce un script personnel ou un outil tiers ?

  • # Information complémentaire sur les auteurs probables

    Posté par  . Évalué à -5.

    http://www.ibtimes.co.uk/are-isis-hackers-trying-destroy-internet-1533332

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.