Juste pour faire un retour sur les perfs : J'ai appliqué l'ACL suivante sur plusieurs interfaces (transitaires + GIX) du routeur CISCO :
ip access-list extended INTERNET_TRANSIT_IN deny udp any eq ntp host A.B.C.D permit ip any any Pour un trafic équivalent à hier, le CPU a pris un bon 5% mais ça reste tout à fait correct, je suis à 70% environ Le mer. 8 janv. 2020 à 13:08, David Ponzone <david.ponz...@gmail.com> a écrit : > Ben ouais quand même, faut bien filtrer des petits trucs :) > Sur un Cisco, c’est pas géré par le CPU normalement, depuis quelques > années maintenant. > > > Le 8 janv. 2020 à 12:47, Fabien H <frnog.fab...@gmail.com> a écrit : > > > > Bonne remarque ! > > > > Pendant l'attaque, je n'ai pas eu l'idée de regarder, j'ai préférer > > vérifier le RTBH. Je ferais la prochaine fois.. > > > > La question est juste de savoir si c'est une pratique qui se fait > > régulièrement sur un routeur de bordure de mettre une ACL extended sur > les > > interfaces des transitaires ou alors si c'est pas conseillé.. > > > > Merci > > > > Le mer. 8 janv. 2020 à 12:35, David Ponzone <david.ponz...@gmail.com> a > > écrit : > > > >> Ca donne quoi un sh proc c ? > >> > >>> Le 8 janv. 2020 à 12:27, Fabien H <frnog.fab...@gmail.com> a écrit : > >>> > >>> Bonjour, > >>> bonne année à la communauté FRNOG :-) > >>> > >>> Je suis toujours sur mes histoires de DDOS : Le RTBH fonctionne, mais > je > >>> trouve que mes routeurs de bordure montent un peu trop en CPU à mon > gout > >>> (encore pas mal de pertes de paquets sur les paquets traversant). > >>> > >>> Je voulais juste savoir sur du CISCO, s'il est judicieux de mettre un > ACL > >>> IN (étendue) sur les interfaces des transitaires du style : > >>> > >>> deny udp port source 123 ip dest A.B.C.D > >>> permit any any > >>> > >>> Est-ce que c'est mieux d'un point de vue performance et mitigation vu > que > >>> le paquet est droppé en entrée par rapport à une route Null 0 ? Ou > alors > >> à > >>> l'inverse l'ACL va entrainer une surcharge CPU qui va le faire > >> s'effondrer ? > >>> > >>> Merci, > >>> > >>> Fabien > >>> > >>> > >>> > >>> > >>> Le mar. 24 déc. 2019 à 07:41, Michel Py < > >> mic...@arneill-py.sacramento.ca.us> > >>> a écrit : > >>> > >>>>>>> Alarig Le Lay a écrit : > >>>>>>> Dans ce cas je préfère faire du flowspec, je trouve ça plus propre. > >>>> > >>>>>> Moi aussi, mais à part le problème d'avoir le matos récent qui le > >> fait, > >>>> va donc trouver un transitaire qui ferait > >>>>>> çà en amont pour toi :-( Déjà en trouver qui connaissent quelque > >>>> choses aux communautés c'est pas évident. > >>>> > >>>>> Yannis Aribaud a écrit : > >>>>> Hurricane Electric propose le support de flowspec en option sur leurs > >>>> offres de transit. Mais ça coûte une blinde ! > >>>> > >>>> C'est bon à savoir que quelqu'un le propose, mais malheureusement > c'est > >> le > >>>> genre de chose qui ne vaut le coup de déployer que si tout le monde ou > >>>> presque le propose. C'est lamentable, mais çà ne vaut pas la peine de > >> payer > >>>> si on a 4 ou 5 transits et que HE est le seul à proposer l'option :-( > >>>> Intellectuellement, HE a mon support. > >>>> > >>>> Malheureusement, flowspec c'est quelque chose que j'aimerais bien > >>>> implémenter mais que je n'ai pas le pognon de le faire. > >>>> Encore une fois : ROI = zéro. > >>>> En plus, avec les vendeurs qui demandent une license extra pour le > >> faire... > >>>> Bientôt, il faudra avoir une license pour aller pisser quand on > >> configure > >>>> un routeur. > >>>> > >>>> Michel. > >>>> > >>>> > >>>> --------------------------- > >>>> 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/
