Stéphane Bortzmeyer a écrit 655 commentaires

Euh, je veux bien, mais cela n'a aucun rapport avec le journal, qui parlait de TLS sur SMTP…

Question fichiers de conf' tous faits, il y avait ceux de mon exposé à IEUFI. Mais, évidemment, cela dépend des cas.

Pour le reste, franchement, en l'absence des messages d'erreur, je ne peux rien faire. « Ça ne marche pas » n'est pas un message d'erreur :-) Prenons un exemple concret, le TLD cambodgien :

% zonecheck kh
ERROR: Unable to find nameserver IP address(es) for kh.cctld.authdns.ripe.net

Là, on peut agir : la zone "kh" liste parmi ses serveurs de noms un kh.cctld.authdns.ripe.net qui n'existe pas (comme on peut le vérifier avec dig). Il faut remplacer par le nom correct.

Dans le journal, j'ai donné l'URL du texte écrit (pas un discours) du gouvernement.

Moi, j'ai compris (mais je ne suis pas sûr qu'Ayrault ait compris ce qu'il demandait) qu'il fallait en effet chiffrer en TLS entre serveurs (RFC 3207). D'où le titre de mon journal.

Ah, je ne prétends pas être capable de lire la pensée du gouvernement :-) Comme le projet de Merkel d'un Internet européen, c'est en effet le plus grand flou.

Il faut aussi noter qu'il est très important, pour la sécurité de l'Internet, d'avoir au moins deux mises en œuvre libres de TLS, au cas où…

Les enregistrer dans le doute me parait très dangereux, cela peut vous faire passer dans la catégorie « stocke des données personnelles » (et doit donc faire des formalités à la CNIL).

Et, pendant qu'on en est au flicage, il faudrait aussi stocker le numéro de port :-) http://www.bortzmeyer.org/6302.html

lut.im a un plugin Shutter et Shutter a une fonction très jolie de floutage (Shutter est le logiciel de capture d'écran recommandé).

Visible par les routeurs ? Mais non, pas du tout, si on utilise HTTPS.

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.

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

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.