Bonjour, Je plussoie, cette conf par défaut un peu light nous a déjà joué des tours avec des techs qui vont un peu trop vite ou ne savent pas ce qu'ils font.
J'ai trouvé la parade il y a quelques semaines : on filtre UDP/53 et TCP/53 (moins pertinent) en entrée sur nos routeurs de collecte. Ca a fait déjà un bon gros ménage. Le reste, on traite manuellement. Julien ----- Mail original ----- De: "David Ponzone" <david.ponz...@gmail.com> À: "Jeremy" <li...@freeheberg.com> Cc: "frnog-tech" <frnog-t...@frnog.org> Envoyé: Mardi 26 Septembre 2017 23:40:05 Objet: Re: [FRnOG][TECH] Attaques en série Oui, si j'en crois: http://www.cogentco.com/files/docs/customer_service/guide/global_cogent_customer_user_guide.pdf Y a pas grand chose à part arrêter d'annoncer tes préfixes à leurs peers et clients :) Bon, comme ton problème est de nettoyer ton lien 10G au départ de Cogent pour le désaturer, t'as pas bcp de solution si Cogent n'a pas de solution type uRPF. Changer de transit en urgence semble peut-être le mieux si ça dure. C'est peut-être le moment de savoir qui a de l'uRPF en offre standard (sans te faire payer des $ pour rentabiliser le Arbor). Concernant les Mikrotik, j'imagine que le "bug" dont tu parles, c'est le fait que quand tu ouvres le resolver interne (avec allow-remote-requests = yes), il est ouvert pour le monde entier car il répond sur toutes les IP du routeur, donc tu dois impérativement mettre des ACL, ce qui n'est pas implicite pour quelqu'un qui est habitué à un CPE classique. C'est vrai que c'est pénible, ça serait pas mal qu'ils rajoutent un champ pour binder le resolver sur une ou plusieurs IP, mais aucune par défaut. Le 26 sept. 2017 à 22:58, Jeremy a écrit : > Le plus simple serait de faire un blackhole pour refuser les routes d'un AS > spécifique. (ChinaNet comme d'hab... AS4134). > Le problème c'est que Cogent ne propose pas -à ma connaissance- de leur > envoyer une communauté pour blackholer les routes provenant d'un AS. > > > Le 26/09/2017 à 22:50, David Ponzone a écrit : >> Tu peux pas l'alléger en filtrant de manière statique les blocs d'IP source >> les plus fréquents ? >> >> >> Le 26 sept. 2017 à 22:38, Jeremy a écrit : >> >>> Nop, pas d'antiddos chez Cogent... >>> On a un routeur en MITM (Wanguard Filter BGP) mais bon, même si il est >>> costaux, il en peu plus là ... >>> >>> Le 26/09/2017 à 22:34, David Ponzone a écrit : >>>> Y a pas des origines géographiques que tu pourrais filtrer en inbound en >>>> ajoutant un routeur MITM (Linux par exemple) pour nettoyer un peu ? >>>> Pas d'offre anti-DDoS chez Cogent ? >>>> >>>> >>>> Le 26 sept. 2017 à 22:23, Jeremy a écrit : >>>> >>>>> C'est du "tout ou rien" chez Cogent. Soit il bloque tout ce qui passe sur >>>>> le port 53, soit ils bloquent rien. Pas possible de faire des ACL >>>>> excluant nos serveurs dns par exemple :( >>>>> Là, l'attaque vient de changer, elle cible notre site public. Pour le >>>>> coup, je m'en fou tant que mes clients sont tranquille. Mais ça deviens >>>>> relou là. >>>>> >>>>> Le 26/09/2017 à 22:21, David Ponzone a écrit : >>>>>> J'ai peut-être raté un truc mais si tu demandes à Cogent de filtrer les >>>>>> paquets en outbound vers ton port 53, sauf pour tes DNS, ça limite pas >>>>>> la casse ? >>>>>> J'ai cru comprendre que tes DNS n'étaient pas la cible, donc ça doit le >>>>>> faire. >>>>>> >>>>>> Le 26 sept. 2017 à 22:08, Jeremy a écrit : >>>>>> >>>>>>> Bonjour, >>>>>>> >>>>>>> Depuis quelques jours, nous recevons de nombreuses attaques semblant >>>>>>> provenir d'un bot commandé (probablement un booter payant facturé à >>>>>>> l'heure). On a relevé énormément de routeurs Mikrotik pas à jour qui >>>>>>> sont commandés pour faire de l'amplification DNS avec spoofing. On >>>>>>> tourne autour de 40-60 Gb/s en continue. >>>>>>> >>>>>>> La particularité de l'attaque est que le mec s'amuse à faire une >>>>>>> rotation d'IP en piochant au pif dans les prefix qu'on annonce (on >>>>>>> annonce l'équivalent d'un /19). Ca a tendance à fortement saturer les >>>>>>> tuyaux (transport), et à faire sérieusement ramer notre infra Wanguard >>>>>>> qui a du mal à suivre (de toute façon, comme ça sature au dessus...). >>>>>>> J'ai l'idée de demander à Cogent (transitaire par lequel ça passe le >>>>>>> plus, logique...) de rajouter une ACL pour filtrer le port 53 mais quid >>>>>>> de notre capacité à résoudre les hostname depuis les root dns servers >>>>>>> ?! Je pense que si on fait ça, on peut dire adieux à notre indépendance >>>>>>> et bonjour à 8.8.8.8 partout (grosse galère en perspective). Pour le >>>>>>> moment, je garde cette option en solution ultime. >>>>>>> >>>>>>> Bref, comme j'en ai marre de jouer avec BGP depuis samedi pour limiter >>>>>>> la casse, je vais finir par rajouter un transitaire protégé le temps >>>>>>> que ça passe. L'idée d'un tunnel GRE permettant de nettoyer le trafic >>>>>>> avant d'arriver chez nous peut avoir du sens, ou alors un nouveau port >>>>>>> de transit en 10G sur lequel on nous livrerais du transit déjà nettoyé. >>>>>>> >>>>>>> Si certains d'entre-vous ont une solution technique efficace capable de >>>>>>> traiter très efficacement cette typologie, de mettre en place une >>>>>>> solution d'urgence pour nous filer un coup de main, et si possible sans >>>>>>> nous facturer les deux reins, ça serait très très apprécié. >>>>>>> >>>>>>> En MP si vous avez besoin de plus d'infos ! >>>>>>> Merci, >>>>>>> Jérémy >>>>>>> >>>>>>> >>>>>>> --------------------------- >>>>>>> Liste de diffusion du FRnOG >>>>>>> http://www.frnog.org/ >> >> --------------------------- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ >> > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
