Journal L'Internet en feu (merci à Jules Verne)

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
27
13
fév.
2014

Peut-être pour faire de la publicité au prochain numéro de MISC qui est consacré aux attaques par déni de service (DoS), l'Internet vit en ce moment au rythme des nombreuses attaques par réflexion+amplification utilisant le protocole NTP. Ces attaques ont atteint des nouveaux sommets (des victimes signalent du 350, voire du 400 Gb/s mais rappelez-vous qu'il n'y a pas d'enquêtes indépendantes sur les attaques DoS).

Le principe de l'attaque est connu depuis longtemps, il est le même que pour les attaques réflexion+amplification utilisant le DNS, simplement NTP fournit typiquement un meilleur rapport d'amplification. La première alarme de la nouvelle utilisation de NTP avait été donnée par CloudFlare et par le CERT lituanien. Il y a un avis officiel
du CERT états-unien et du français.

Un exemple de récit de l'attaque contre CloudFlare dans la presse est sur BFMTV (article tout à fait sérieux) ou, en anglais, donné par ITnews (attention, semble bloqué depuis Free, cela marche depuis les autres opérateurs) ou par la BBC.

Certains opérateurs ont pris des mesures spécifiques ou bien avertissent leurs clients (cas d'Online).

Si vous gérez des serveurs, vérifiez qu'ils ne sont pas amplificateurs NTP, avec le projet OpenNTPproject.

  • # Configuration, pas mise à jour

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

    How can I fix my server, router or other device? You should upgrade tp NTP-4.2.7p26 or later.

    Mauvaise idée. NTP 4.2.7 est une version de développement. En particulier, pour ceux qui attendent que cette version soit publiée dans Debian, oubliez cette idée : ça n'arrivera pas.

    You can add disable monitor to your ntp.conf and restart your NTP process if on an earlier version.

    Voilà, ça c'est la vraie solution avec la version stable de NTP. Malheureusement, ça désactive plus que seulement ce qui serait nécessaire, mais bon…

  • # Quelle heure est il ?

    Posté par  . Évalué à 1.

    Et avec tout ça, on sait quelle heure il est ? ;-)
    Avons nous une idée de l'impact, outre la bande passante utilisé, que cette attaque à pu avoir ? Par exemple serveur NTP non joignable et donc désynchro des niveaux en dessous ? Masquage d'une attaque plus complexe / ciblée ? Il doit encore être trop tôt pour le déterminer, mais je pense que ça sera intéressant à voir.

    • [^] # Re: Quelle heure est il ?

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

      "outre la bande passante utilisé" Qu'est-ce que l'attaquant pourrait vouloir d'autre ? Ce n'est pas une attaque contre NTP, c'est une attaque par déni de service utilisant NTP.

      • [^] # Re: Quelle heure est il ?

        Posté par  . Évalué à -3.

        outre la bande passante utilisé,

        Je chipote, mais on dit débit, ou au pire capacité :)

        • [^] # Re: Quelle heure est il ?

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

          Débit, OK, mais capacité, non, ce n'est pas ça (débit : ce qui passe effectivement dans le tuyau, capacité RFC 5136 : ce qui pourrait passer, bande passante : vieux et ambigu, à ne pas utiliser).

          • [^] # Re: Quelle heure est il ?

            Posté par  . Évalué à -1.

            Oui, je connais la différence entre débit et capacité, mais il vaut peut-être mieux parler de capacité plutôt que de bande passante, au moins capacité ne désigne pas quelque chose d'analogique.

            Le mieux étant de dire débit, là on est d'accord.

      • [^] # Re: Quelle heure est il ?

        Posté par  . Évalué à 4.

        Ce que Toto demande c'est, je pense, est-ce qu'on a évalué les effets de bord sur NTP de cette attaque ?

  • # CloudFlare vend de la protection anti DDOS

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

    Je ne nie pas la réalité de ces attaques, mais il y a un truc qui me chipote quand même. Tous ces communiqués alarmés viennent de chez cloudflare, qui, oh hasard, vend de la protection anti DDOS.

    Grosso modo, ils indiquent que les DDOS, c'est le mal absolu, le cataclysme du siècle, que c'est extrêmement difficile de s'en protéger, mais que d'un autre côté, ça tombe bien, ils sont justement là pour sauver les clients de ces horreurs (pas cher, allez voir la grille tarifaire). Ca fait quand même pompier pyromane surtout que les chiffres sont toujours fournis pas CloudFlare eux mêmes. Ils auraient pu annoncer 500GBits/s ou 1Tbit/s puisque personne ne vient confirmer/infirmer cela.

    Idem avec OVH. Ils ont bien communiqué sur leur protection antiDDOS, il faut bien mettre des chiffres en face.

    Donc bon, je lis toujours ces communiqués avec un peu de distance, surtout que généralement:
    -la cible du DDOS : on ne la connaît pas
    -les raisons du DDOS : on ne les donne pas
    -les sources du DDOS : encore très vague.

    Donc on aurait des pirates qui lancent des attaques non ciblées à 500GB/s vers des IP quelconques pour des raisons floues?

    Mouais mouais mouais.

    • [^] # Re: CloudFlare vend de la protection anti DDOS

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

      Non, non, non, ce n'est pas vrai de dire que les seules annonces viennent des vendeurs de solutions anti-dDoS. Online a été touché aussi (et ne vend rien dans ce domaine) et a communiqué là-dessus. Même chose pour Gitoyen (j'avais mis le graphe sur mon blog. Depuis trois jours, les sirènes d'alarme sonnent partout.

      "les raisons du DDOS" Les attaquants laissent rarement leurs cartes de visite avec leurs motivations dessus ("Arsène Lupin, gentleman-cambrioleur").

      "les sources du DDOS" Si quelqu'un ici a un moyen de trouver les sources d'une attaque où il y a eu usurpation d'adresse IP, qu'il se signale, l'ANSSI sera ravie de l'embaucher :-)

      • [^] # Re: CloudFlare vend de la protection anti DDOS

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

        Comme indiqué, je ne nie pas ces DDOS. Ce sont les chiffres donnés qui me chipotent.

        Concernant les raisons, j'ai du mal à croire qu'une organisation "s'amuserait" à lancer du 500GBit/s juste comme ça, pour voir. Les sources, ce n'est pas l'adresse IP bien sûr, mais l'organisation elle même.
        Je serais une orga capable de lancer du 500Gbit/s, je le ferais savoir et je démolirais une cible visible pour une raison logique:
        - montrer qu'on a la plus grosse
        - montrer un désaccord avec la politique éditoriale du site qui tombe

        mais laisser cloudflare dire: "oh on a vu 500Gbit/s sans trop comprendre pourquoi" j'assimile ça à du marketing assez malsain.

        Maintenant que des gens se prennent 700Mbit dans la carte réseau, oui j'y crois complètement.

        [ Et au sujet des sources de DDOS avec spoof, je suis curieux de savoir pourquoi les fabricants de routeurs/FW n'aggrègent pas les logs en big data pour retrouver ce genre d'infos. Une machine zombie dans son réseau qui va taper des NTP avec une @IP source différente de celle de son réseau d'origine ça devrait se tracker facilement. En tout cas c'est comme ça que je ferais si j'étais l'ANSSI. Mon CV est dispo pour ceux qui veulent :-) ]

        • [^] # Re: CloudFlare vend de la protection anti DDOS

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

          Concernant les raisons, j'ai du mal à croire qu'une organisation "s'amuserait" à lancer du 500GBit/s juste comme ça, pour voir.

          Ça tombe bien, personne ne fait ça. Il s'agit d'attaques par amplification, où l'attaquant envoie des paquets spécialement conçus à un débit relativement faible, et où le serveur utilisé comme rebond répond avec des paquets beaucoup plus gros et donc à un débit plus élevé en destination de la cible de l'attaque.

          Et au sujet des sources de DDOS avec spoof, je suis curieux de savoir pourquoi les fabricants de routeurs/FW n'aggrègent pas les logs en big data pour retrouver ce genre d'infos. Une machine zombie dans son réseau qui va taper des NTP avec une @IP source différente de celle de son réseau d'origine ça devrait se tracker facilement.

          Effectivement, le fournisseur d'accès de l'attaquant pourrait détecter son attaque, à supposer que ça l'intéresse et il ait le droit et la capacité de procéder à ce genre de vérification sur le trafic. Mais comme la cible de l'attaque n'a aucun moyen de savoir d'où provient l'attaque, elle ne pourra pas demander à ce FAI.

          • [^] # Re: CloudFlare vend de la protection anti DDOS

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

            "paquets spécialement conçus à un débit relativement faible"

            Je sais lire, merci. Mais quelle que soit la méthode, envoyer 500Gbit/s dans une cible "pour voir" m'étonne. Ca reste énorme, même si la source n'a qu'a en générer 25x moins. Ensuite si pour toi envoyer 20Gbit/s c'est "un débit relativement faible", pourquoi pas hein, il y a sûrement plein de boîtes qui voudront t'embaucher pour gérer des débits faibles comme ceux-ci :)
            A titre d'infos, certains pays sont reliés encore par des fibres de 7GB/s. Alors 20GBit/s, c'est relativement faible, hein ;)

            "Mais comme la cible de l'attaque n'a aucun moyen de savoir d'où provient l'attaque, elle ne pourra pas demander à ce FAI."

            Non. L'idée c'est d'aggréger des données. Tu n'es pas une victime qui croule sous la charge, tu es l'ANSSI qui a la remontée de beaucoup de sondes/firewalls. Or donc, tu observes en un point un énorme DDOS de plusieurs centaines de GB/s avec en source des serveurs NTP, tu as lu l'article du bortz, tu sais ce dont il s'agit. Et qu'il n'y a rien à faire du côté de la cible.

            Par contre, tu regardes sur tous les autres réseaux que tu monitores les IP qui crachent des données en sortie vers des serveurs ntp avec une IP source différente de celle du réseau d'origine (puisque c'est spoofée et que l'IP source est celle de la victime). Ca tu peux le faire car tu as un maillage de firewalls/sondes suffisamment large pour espérer catcher au moins un de ces zombies: et plus le DDOS est gros, plus il y a de zombies et plus tu as de chances d'en avoir un dans un de tes réseaux. Une fois que tu as choppé le zombie, à toi l'analyse de celui-ci pour trouver le C&C qui a piloté le zombie pour lui demander de flooder la victime (via reflection NTP).
            Tu bloques le canal C&C, l'attaque stoppe immédiatement.

            "il ait le droit et la capacité de procéder à ce genre de vérification sur le trafic."

            Oui, on parle de l'ANSSI ou de ce genre de choses. S'ils n'ont pas le droit, ils doivent bien le prendre ou se débrouiller pour modifier la loi qui va bien.

            • [^] # Re: CloudFlare vend de la protection anti DDOS

              Posté par  . Évalué à 1. Dernière modification le 13 février 2014 à 12:48.

              Ensuite si pour toi envoyer 20Gbit/s c'est "un débit relativement faible", pourquoi pas hein,

              Ouais, c'est faible, ya qu'a regarder les backbone d'hébergeurs comme OVH ou Online, c'est rien 20 Gbits/s.

              Suffit d'avoir la main sur une cinquantaine de serveurs pour pouvoir générer ce trafic là. Bon, c'est sûr que le premier Jean-Kevin qui arrive ne pourra/saura pas faire ça, mais ce n'est pas inaccessible non plus.

              • [^] # Re: CloudFlare vend de la protection anti DDOS

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

                "Suffit d'avoir la main sur une cinquantaine de serveurs pour pouvoir générer ce trafic là."

                Grosso modo, tu veux cracher 500MBit/s en sortie en direction d'un serveur NTP qui va l'amplifier 25x?
                A 500Mbit/s tu vas exploser le pauvre serveur NTP, et je doute qu'il ait 10Gbits/ en sortie pour aller taper une cible.

                • [^] # Re: CloudFlare vend de la protection anti DDOS

                  Posté par  . Évalué à 1.

                  Grosso modo, tu veux cracher 500MBit/s en sortie en direction d'un serveur NTP qui va l'amplifier 25x?
                  A 500Mbit/s tu vas exploser le pauvre serveur NTP, et je doute qu'il ait 10Gbits/ en sortie pour aller taper une cible.

                  Je connais pas du tout NTP, donc je sais pas si un serveur ntp peut supporter autant de débit en sortie c'est vrai. Mais sinon, 400Mbit/s par serveur, c'est largement faisable au niveau réseau.

                • [^] # Re: CloudFlare vend de la protection anti DDOS

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

                  Chacune des 50 machines controlées par l'attaquant peut répartir ses 500Mb/s sur 1000 serveurs NTP différents hein.

                  pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

                  • [^] # Re: CloudFlare vend de la protection anti DDOS

                    Posté par  . Évalué à 6.

                    Sans parler que c'est un bot qui envoie l'attaque. A l'époque où les PC zombies de ces bots floodaient directement la cible. C'était environ 10 à 20 milles IPs différentes.

                    De plus, je ne pense que l'attaque était basé uniquement sur NTP. Il devient aussi y avoir du rebonds par DNS et quelques ICMP ( host ou port unreacheable ). Ce que j'observe actuellement est de l'order NTP 69% DNS 29% et ICMP 2%.

                • [^] # Re: CloudFlare vend de la protection anti DDOS

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

                  Non. Tu as 50 serveurs, chacun pouvant balancer 500mb/s vers l'internet.
                  Tu aggrège un petit million d'IP de serveurs NTP vulnérables, et tu les distribue sur tes 50 serveurs. Chacun va lancer des requêtes sur 20000 NTP par seconde (300 octets * 20000 = 48MB/s) et bim.

                  Il est évident que les 400Gb (ou les 10 dont tu parles) ne sortent pas d'un seul serveur.

            • [^] # Re: CloudFlare vend de la protection anti DDOS

              Posté par  . Évalué à 2.

              Une fois que tu as choppé le zombie, à toi l'analyse de celui-ci pour trouver le C&C qui a piloté le zombie pour lui demander de flooder la victime (via reflection NTP).

              Sauf si le pilotage de ton armée de zombies se fait via un réseau pair à pair. Comme c'est décrit ici par exemple : https://www.usenix.org/legacy/events/hotbots07/tech/full_papers/grizzard/grizzard_html/

              Faut pas gonfler Gérard Lambert quand il répare sa mobylette.

            • [^] # Re: CloudFlare vend de la protection anti DDOS

              Posté par  . Évalué à 1.

              A titre d'infos, certains pays sont reliés encore par des fibres de 7GB/s. Alors 20GBit/s, c'est relativement faible, hein ;)

              C'est un peu hors sujet, mais ça veux dire que quand je télécharge des jeux sur Steam à 25Mio/sec, cela correspond à 1/280 fois la vitesse de connexion que des pays tels que ceci peuvent avoir avec le reste du monde ???

              bépo powered

              • [^] # Re: CloudFlare vend de la protection anti DDOS

                Posté par  . Évalué à 3.

                Si tu télécharge à 25Mio/sec, cela fait ~ 1/33, mais statistiquement, tu dois plutôt télécharger à 20Mb/sec.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: CloudFlare vend de la protection anti DDOS

                  Posté par  . Évalué à 1.

                  Non, non, c'est bien en méga octets, (j'aime bien la fibre ^-^ )
                  Et donc mon débit est donc bien particulièrement élevé par rapport à celui de certain pays entier !

                  bépo powered

                  • [^] # Re: CloudFlare vend de la protection anti DDOS

                    Posté par  . Évalué à 3.

                    j'aime bien la fibre

                    Mais pas les math :)

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                    • [^] # Re: CloudFlare vend de la protection anti DDOS

                      Posté par  . Évalué à 2.

                      Ça n’empêche que je n'ai pas compris ton calcul, vu que 25MB/s * 33 = 825 MB/s, alors que 25MB*280 = 7000 MB/s = 7GB/s.
                      Sauf erreur de ma part, le 'B' majuscule désigne les Bytes (octets) par opposition au 'b' minuscule qui désigne les bits. Donc 'B' me semble bien équivalent à 'Mio'. J'aimerai savoir où est mon erreur.

                      bépo powered

                      • [^] # Re: CloudFlare vend de la protection anti DDOS

                        Posté par  . Évalué à 3.

                        Pour moi, un débit est (presque) toujours annoncé en bits et non pas en byte, du coup, j'imagine qu'il s'agit de 7Gbits par secondes et non pas 7Gbytes par secondes. Et la convention "B" = "bytes", je l'ai rarement vu respectée.

                        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                        • [^] # Re: CloudFlare vend de la protection anti DDOS

                          Posté par  . Évalué à 1.

                          Donc mon calcul était bon, en considérant que les commentaires précédant était correctement écrit, mais tu étais parti du principe que ce n'était pas le cas.
                          Merci pour la précision.

                          bépo powered

                          • [^] # Re: CloudFlare vend de la protection anti DDOS

                            Posté par  . Évalué à 3.

                            Sauf que tu annonce un débit de 25Mio/s et non pas 25Mo/s, ce qui fait 1/267.

                            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: CloudFlare vend de la protection anti DDOS

          Posté par  . Évalué à 1.

          Hors justement, ce sont des attaques avec amplifications, d'un facteur x10 voir environ x20 pour du NTP-AMP.
          Cela veut dire que pour générer une attaque de 500Gb, il suffit à l'attaquant de générer seulement 50Gb ou 25Gb….

          De plus, NTP, c'est principalement du flux UDP, donc sans connexion (on envoi les messages au petit bonheur la chance), on ne sait pas qui est réellement l'émetteur, l'adresse IP source peut-être facilement usurpé (car le destinataire ne va pas établir de connexion avec l'émetteur comme c'est le cas avec le TCP ou usurper une adresse est bien plus compliqué).

          Un parallèle du protocole UDP dans la vie réelle serait l'envois de lettre simple, avec la possibilité d'inscrire l'émetteur au dos de la lettre, il n'y a aucune vérification sur l'identité et n'importe qui peut envoyer des lettres au nom du président.

        • [^] # Re: CloudFlare vend de la protection anti DDOS

          Posté par  . Évalué à 2.

          On peut imaginer plein de choses sur les raisons : detourner l'attention, faire un test grandeur nature de l'exploitation d'un nouveau concept, tester un enorme botnet, etc
          Un mec qui veut vendre un nouveau service, il fait de la pub. Et là, il en a une magnifique…

          Quand a cloudflare, ils proposent effectivement un service antiDDoS (efficace au passage puisqu'ils ne sont pas tombés) et il est logique qu'ils se retrouvent en premiere ligne quand ce genre de phenomene arrive. Idem pour le plus gros hebergeur europeen (OVH)…
          Etre etonné de ca, c'est comme etre etonné que les compagnies d'assurance soient les plus a meme de chiffrer l'ensemble des degats lors d'une catastrophe naturelle.

          • [^] # Re: CloudFlare vend de la protection anti DDOS

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

            Il y a aussi du chantage, j'avais vu dans le témoignage d'un pirate qu'ils contactaient un site en les menaçant de lancer un DDOS

            Si le mec paie, ils laissent tomber, si le mec ne paie pas ils le ddos et comme c'est un site marchand il perd de l'argent car le site est inaccessible

      • [^] # Re: CloudFlare vend de la protection anti DDOS

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

        Autre opérateur qui a communiqué sur ces attaques (et ne vend pas de solutions anti-dDoS), Renater

    • [^] # Re: CloudFlare vend de la protection anti DDOS

      Posté par  . Évalué à 2.

      Témoignage concret: j'ai eu ce matin une attaque dirigée vers un site du réseau dont je m'occupe, pour un débit d'environ 8 Gb/s.
      J'imagine que les scripts kiddies achètent de la capacité pour bombarder une cible de leur choix ? Si quelqu'un connait la manière dont ça se passe ça m'intéresse.

      • [^] # Re: CloudFlare vend de la protection anti DDOS

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

        C'était une attaque NTP (port source 123) ?

        Quant à la manière d'aller sur le darque ouèbe (ou plutôt le darque hièrcé) pour acheter du dDoS (CaaS : Crime as a Service), on ne peut pas la raconter sur un site comme LinuxFr où il y a des mineurs.

        • [^] # Re: CloudFlare vend de la protection anti DDOS

          Posté par  . Évalué à 8.

          où il y a des mineurs

          Donc ça s'achète avec des Bitcoins ?

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: CloudFlare vend de la protection anti DDOS

          Posté par  . Évalué à 3.

          Oui tout à fait, plus précisément:
          - Heure de début: 11:26:12.563
          - Heure de fin: 11:38:49.936
          - Port source: 123, Port destination: 80

          D'après les logs Netflow du routeur, cela fait 6800 adresses IP sources différentes, mais j'ai l'impression
          que le routeur n'en a exporté qu'une petite partie (TCAM trop petite ?).

          • [^] # Re: CloudFlare vend de la protection anti DDOS

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

            Intéressant, le port de destination. Le serveur HTTP ne va évidemment pas pouvoir comprendre ces paquets mais l'attaquant voulait sans doute être sûr de passer les pare-feux.

            • [^] # Re: CloudFlare vend de la protection anti DDOS

              Posté par  . Évalué à 1.

              Les pare-feux mal foutu alors. L'attaque est en UDP si je ne m'abuse et ouvrir UDP/80 pour faire passer du http, c'est pas terrible, même si on ne veux pas faire de suivi de connexion, (ce qui n'est pas forcément déconnant), on peux se contenter d'ouvrir le TCP/80, non ?

              Faut pas gonfler Gérard Lambert quand il répare sa mobylette.

              • [^] # Re: CloudFlare vend de la protection anti DDOS

                Posté par  . Évalué à 2.

                Drop le paquet n’empêchera pas l'attaque de saturer le lien.

                • [^] # Re: CloudFlare vend de la protection anti DDOS

                  Posté par  . Évalué à 2. Dernière modification le 14 février 2014 à 11:58.

                  Bah oui, je sais, mais la remarque de Stéphane portait sur le fait que l'attaquant cherchait à passer des pare-feux. C'est peut-être que des script-kiddies au final (comment on peut dire ça en français ? Un gone à recettes ? ) Par ce que du coup, ça fait une signature super simple pour déployer des filtres en amont de la cible.

                  Faut pas gonfler Gérard Lambert quand il répare sa mobylette.

                  • [^] # Re: CloudFlare vend de la protection anti DDOS

                    Posté par  . Évalué à 2.

                    En ce qui me concerne, j'ai effectivement un filtre à l'entrée qui droppe tout ce qui arrive sur le port 80/udp (parce
                    que j'ai régulièrement des attaques sur ce port).
                    Ca protège le reste de mon réseau, mais pas la liaison 10 Gb/s avec mon upstream (qui a quasiment été saturée).

            • [^] # Re: CloudFlare vend de la protection anti DDOS

              Posté par  . Évalué à 1.

              Je ferais la même remarque que l'intervenant plus haut (Big Pete): je ne pense pas que ça aide spécialement, je pense que personne ne s'amuse
              à laisser ouvert 80/udp pour du HTTP.
              Pour la petite histoire, précédemment j'ai aussi eu des attaques sur le port 0/udp en destination (mais ce n'était pas avec du NTP amplification).

              • [^] # Re: CloudFlare vend de la protection anti DDOS

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

                Le port 0 n'existant pas officiellement, je soupçonne que c'est un logiciel bogué qui ne sait pas interpréter les fragments IP et qui les affichent comme cela.

                • [^] # Re: CloudFlare vend de la protection anti DDOS

                  Posté par  . Évalué à 3.

                  Effectivement, je n'ai pas percuté: ce sont des logs Netflow, et les routeurs renvoient port source et destination à 0
                  pour les paquets fragmentés.
                  J'ai retrouvé une des attaques en question, le port source était 161/udp (donc SNMP), et la taille (donc celle
                  du 1er paquet du flux) était à 1500, ce qui est cohérent avec le fait d'avoir de la fragmentation.

                  Exemple pour un attaquant X.X.X.X vers Y.Y.Y.Y
                  (timestamp | @IP source | @IP destination | protocol port source port dest | nb paquets du flux | taille total flux):

                  2013-11-21 22:05:32.978 | X.X.X.X  | Y.Y.Y.Y  | udp    161    80 |        1 |     1500
2013-11-21 22:05:32.978 | X.X.X.X  | Y.Y.Y.Y  | udp      0     0 |        2 |     3000

    • [^] # Re: CloudFlare vend de la protection anti DDOS

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

      Et ils vendent du Man in the Middle, surtout.
      Ils proposent du SSL pour leurs clients (seulement les payants ? Je ne sais plus), qui s'arrête chez eux, avec aucune garantie ensuite.
      Techniquement, ils ont accès à tout ce que vous envoyez/recevez sur korben.info, www.pcinpact.com, ycombinator.com, 4chan.org, et bien d'autres, y compris quand vous êtes en HTTPS, et peuvent très bien s'amuser à croiser le tout.
      Perso, c'est peut-être un peu bourrin, mais je bloque tout simplement toutes leurs adresses IPs. Pour ce faire, je bloque tous les préfixes annoncés par l'AS AS13335.
      Une manière d'obtenir ces adresses est d'interroger whois.radb.net :

      whois -h whois.radb.net '!gAS13335' # IPv4
whois -h whois.radb.net '!6AS13335' # IPv6
whois -h whois.radb.net -i origin AS13335 # Plus d'infos sur chaque préfixe

      Ceci-dit, ces données n'ont pas l'air entièrement fiable : en effet, une ou deux plages d'adresses retournées par radb ne semble pas/plus être annoncées par CloudFlare.
      C'est le cas de “203.161.188.0/24”, qui est d'ailleurs vachement louche (CloudFlare aurait été un transit pour une banque à un moment ? Et c'est le seul réseau dans ce cas ?)

    • [^] # Re: CloudFlare vend de la protection anti DDOS

      Posté par  . Évalué à 3. Dernière modification le 14 février 2014 à 17:19.

      Je crois que les chiffres sont trompeurs en raison du caractère distribué de l'attaque, qui est non seulement distribué du coté de l'émetteur, mais aussi du coté de la cible.

      Je vais tenter de faire un calcul simple et sûrement faux pour illustrer et expliquer ce que je pense :

      Cloudflare a 24 centres de données réparti dans le monde (disons, 24 points de présence) Ces 24 points sont sûrement connectés localement aux réseaux régionaux (fournisseurs d’accès, hébergeurs etc …). Et y annonce les mêmes plages d’adresses, même si elles correspondent a des infrastructures différentes, mais qui fournissent le même service (En faisant par exemple du BGP anycast). C'est d'ailleurs ce système qu'ils mettent en avant dans leur offre de service anti-DDOS.

      Quand ils annoncent 400 Gb/s de débit sur l'attaque, ils doivent faire la somme des débits sur l'ensemble des points de présence. Ce qui fait une moyenne d'environ 16 Gb/s par point de présence. Ce qui semble déjà plus "normal", même si ça reste énorme.

      Si on considère qu'une machine utilisé en réflecteur ntp a une capacité de 100Mb/s, il en faut donc 160 par secteur. (en moyenne) et donc (en gros) 3840 en tout. Ce qui ne semble pas déconnant vu le nombre de serveur NTP potentiellement vulnérables et le facteur d'amplification.

      Ils ont publié dans l'article suivant la liste des sources du DDOS par AS. Si on en fait la somme on tombe sur 4529 sources avec une moyenne de débit de 87Mb/s par serveurs. Ça semble aller dans le sens de ce raisonnement.

      Surtout si on compare la carte de leurs points de présences avec celle des source de l'attaque dans l'article que je cite précédemment.

      Faut pas gonfler Gérard Lambert quand il répare sa mobylette.

  • # Et là...

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

    Plouf le serveur !

  • # Test de ses serveurs

    Posté par  . Évalué à 2.

    Le site Open NTP Project n'est vraiment pas très clair je trouve.

    En gros avec ntpd sur des Debian à jour, il y a quelque chose à faire ?

    • [^] # Re: Test de ses serveurs

      Posté par  . Évalué à 2.

      Oui, la derniere version de NTP sous debian est a reconfigurer. Je viens de le faire sur mes serveurs.

      Et comme le dit Tanguy Ortolo , il faut ajouter "disable monitor" dans la conf et pas seulement attendre une maj de ntp qui n'arrivera pas.

      Effectivement, le site openntp project a une page d'explication plutot mauvaise car il faut bien tester sur l'IP locale (ou publique) du serveur et non pas sur 192.0.2.1

      • [^] # Re: Test de ses serveurs

        Posté par  . Évalué à 2.

        Remplacer l'ip donnée en exemple c'est pas la mort non plus, ça j'avais trouvé quand même.
        Non ce qui est gênant c'est qu'ils ne disent pas comment interpréter le résultat.

        Bref je vais changer la config sur mes serveurs après avoir lu à quoi sert cette option.

        Je comprends que Debian ne mettent pas à jour la version de NTP, mais ils ne peuvent pas changer le fichier de conf par défaut ?

        • [^] # Re: Test de ses serveurs

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

          C'est inutile, le fichier de configuration par défaut n'est pas vulnérable à cela.

          • [^] # Re: Test de ses serveurs

            Posté par  . Évalué à 0.

            Un des tests indiqués sur OpenNTPProject (la commande avec -c monlist) me renvoie des données avant la modification et plus ensuite.

            Bref c'est ce qu je disais : le test pour savoir si on peut contribuer ou non aux DDOS n'est pas clair. C'est quand même rassurant de savoir que la config par défaut ne pose pas problème.

            Perso je n'utilise pas le monitoring donc je vais le virer dans le doute. :)

      • [^] # Re: Test de ses serveurs

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

        Oui, la derniere version de NTP sous debian est a reconfigurer.

        Pas forcément. La configuration par défaut sous Debian n'est pas vulnérable à cette attaque (ou plutôt, ne permet pas de servir de rebond pour cette attaque, comme vous l'aurez compris). En revanche, les configurations modifiées, où la restriction noquery a été enlevée, sont vulnérables.

        • [^] # Re: Test de ses serveurs

          Posté par  . Évalué à 0. Dernière modification le 13 février 2014 à 17:15.

          J'ai installé NTP sur mes serveurs debian 7 sans aucune modification et ils repondent positivement au test…

          Le fichier de conf par defaut est le suivant : 

          # /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift


# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable


# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst


# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust


# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient

          [edit] Je viens de me rendre compte que j'ai fait le test en local et non a distance. Il est probable que le "restrict" suffise a bloquer la vulnerabilité. Quoiqu'il en soit, j'ai ajoute le disable monitor et tout va bien[/edit]

  • # Détails techniques

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

    Depuis, CloudFlare a publié quelques détails techniques intéressants.

    • [^] # Re: Détails techniques

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

      Je vois que OVH est troisième, derrière deux réseaux Chinois.

      Il faudrait savoir, pour OVH, quel est la part correspondant aux lignes ADSL.

      A+

      Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

  • # FIltrer NTP en u32...

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

    Pour ceux et celles qui n'ont vraiment rien d'autre à faire, une solution compliquée et fragile (mais cool techniquement) pour empêcher que son serveur NTP soit utilisé comme réflecteur/amplificateur, utilisant Netfilter et son module u32

    • [^] # Re: FIltrer NTP en u32...

      Posté par  . Évalué à 3.

      Pour ceux et celles qui n'ont vraiment rien d'autre à faire

      Ou, comme dit dans l'article, qui n'ont pas la main sur les machines qu'ils hébergent.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: FIltrer NTP en u32...

      Posté par  . Évalué à 3. Dernière modification le 16 février 2014 à 14:36.

      On peut aussi implémenter BCP38.

      Sur un routeur GNU/Linux il y a deux manière de faire :

      • passer la valeur de net.ipv4.conf.default.rp_filter à 1 (à la place de default, on peut aussi mettre le nom d’une interface spécifique) ;
      • avec un noyau et un iptables récents (linux 3.3 et iptables 1.4.13) : iptables -t raw -A PREROUTING -i <interface> -m rpfilter --invert -j DROP.

      La première solution ne fonctionne qu’en IPv4 et est dépréciée, la seconde ne fonctionnera pas sous Debian Wheezy puisque le noyau est trop vieux (cependant, la version d’iptables est bonne donc un noyaux backporté fera l’affaire).

      Par contre, c’est le genre de chose que j’aurai aimé trouver plus facilement en faisant des recherches. Malheureusement, j’ai du fouiller un peu avant de trouver une documentation.

      Voilà les référence que j’ai touvé :

      • [^] # Re: FIltrer NTP en u32...

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

        Euh, cela n'a rien à voir. Là, on discutait de ce qu'on pouvait faire lorsqu'on est la victime d'une attaque ou bien lorsqu'on est le réflecteur. BCP 38 est ce que peuvent faire les opérateurs qui hébergent l'attaquant. C'est certainement très important mais, en attendant que tout le monde le fasse, il faut bien prendre des mesures contre les réflecteurs, et pour protéger les victimes.

      • [^] # Re: FIltrer NTP en u32...

        Posté par  . Évalué à 0.

        Merci pour cette réponse :)
        (je cherchais partout de la doc complète sur rp_filter)

    • [^] # Re: FIltrer NTP en u32...

      Posté par  . Évalué à 2.

      Sur une machine client ou un serveur lambda, je ne vois pas l'intérêt de déployer tout le merdier NTPd alors qu'un bête ntpdate régulier suffit ?
      J'ai raté un truc ?

      • [^] # Re: FIltrer NTP en u32...

        Posté par  . Évalué à 4.

        Oui. Avec des ntpdate régulier tu as des saut d'horloge, et ça provoque des problèmes. Entre les taches exécutés deux fois, ou non exécutés les compilations qui se basent sur l'heure de modifications, les sauvegardes qui se basent sur l'heure de modification, les clients mails, et plein d'autres choses.

        Bref dès que tu fais un saut d'horloge c'est s'exposer à plein de problèmes, dont en plus on ne comprends pas immédiatement la cause.

        ntpd ralenti ou accélère l'horloge (avec un rapport 1/2000 de mémoire) pour rester synchronisé sans faire de saut.

Suivre le flux des commentaires

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