Stéphane Bortzmeyer a écrit 645 commentaires

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.

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.

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.

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

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

Non, c'est faux. L'implémentation de référence écoute par défaut sur le port 123. Il faut TESTER et ne pas chercher à se rassurer.

Mais c'est vrai que "sudo lsof -n -l -i:123" serait peut-être un meilleur test

Pour les instructions précises, avec test et tout, sur Unix, cf. http://www.bortzmeyer.org/ntp-reflexion.html

Disons que la distinction entre client et serveur, pour NTP, est floue.

Donc, sur Linux, si ps auxwww | grep ntp trouve quelque chose, vous êtes concerné.

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).

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 :-)

"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.

Le RFC sur NAT64 est le 6146 Celui sur DNS64 est le 6147

Ah oui, effectivement, ces CGU sont inacceptables. Merci de les avoir lues, je retourne vers Flattr et Bitcoin.

Alors, c'est que le moteur de recherche de LinuxFr est broquenne car il ne trouvait rien pour "tipeee" (maintenant, il ne trouve que mon journal).

Personnellement, je ne suis pas très chaud a priori, notamment à cause de ce système de validation du contenu (à l'inscription du créateur, et ensuite à la publication, pour vérifier que le créateur tient ses promesses). Cela me semble lourd pour les équipes de Tipeee, très ouvert à l'arbitraire, et pas très cohérent avec la logique de crowdfunding.

Bon, qui parmi les lecteurs de LinuxFr est sur Twister, qu'on puisse essayer ensemble ? Moi, c'est "bortzmeyer" sur Twister.

Mon compte-rendu d'expérience : http://www.bortzmeyer.org/twister.html

Oui, j'ai en effet l'impression que c'est pas mal endormi. Mais, bon, pour les serveurs faisant autorité, entre BIND, NSD et Knot, on a déjà un bon choix.

La comparaison avec IRC est tout à fait injuste. D'abord, ce n'est pas la même sémantique (IRC : chaque membre du canal écrit à tous les membres du canal, Twister : chacun écrit à ses suiveurs). Ensuite, IRC est centralisé. Le serveur sait tout (qui communique, depuis quelle adresse IP) et décide tout (de supprimer ton compte, par exemple). Enfin, le cahier des charges en terme de sécurité n'est pas le même (IRC diffuse ton adresse IP à tous les membres du canal).

IRC est cool mais vaut absolument zéro, question vie privée !

Namecoin n'a absolument rien à voir avec le DNS (à moins qu'on baptise tous les protocoles de nommage « DNS »).

Outre l'argument « petite machine qu'on veut économiser », il y a un argument de sécurité/résilience : les attaques par déni de service étant fréquentes, il faut de la marge. Les serveurs racine ou des TLD ont typiquement une marge de 20 à 40 (pouvoir encaisser 20 à 40 fois le trafic habituel).

La supervision est l'ensemble des mécanismes qui teste régulièrement l'état d'un système ou réseau et alerte s'il y a un problème. Par exemple, si on a deux serveurs DNS pour une zone (le minimum recommandé), la panne d'un des deux serveurs n'est pas visible par les utilisateurs, en raison de la redondance du DNS. La supervision permettra à l'admin' système de se dire « ah, il faut réparer ns2.example.com, BIND a encore crashé »

Un adjudant est autoritaire mais un serveur DNS fait autorité.

"Zone BIND" n'a pas de sens. Le format des fichiers de zone n'a rien à voir avec BIND, il est normalisé dans le RFC 1035.

Aussi bien NSD que BIND et Knot ont une configuration très simple dans ce cas, en quatre ou cinq lignes (l'exemple Knot donné dans mon article est complet et marche).

C'est plutôt la supervision qu'il faut soigner.

Mettre quelque chose sur LinuxFr procure un bon référencement ? Ça m'intéresse, alors :-)