Franchement, c’est un problème avec Mikrotik.
Parce qu’entre les changements de syntaxe être R6 et R7, et les changements de 
syntaxe sur la partie wifi (wireless puis wifiwave2 puis à nouveau wireless)…..

Et pousser un squelette, c’est pas le problème (perso, j’ai un générateur de 
conf en Jinja2).
Le problème c’est conserver l’homogénéité sur la flotte déjà déployée, mais je 
pense que c’est un cauchemar pour tout CPE.

J’avais pensé à inclure dans la conf de chaque CPE un script qui interroge un 
webservice en lui passant le nom du CPE ou sa MAC eth1, qui lui renvoie soit 
une série d’URL par défaut pour récupérer les morceaux de conf standard qui 
peuvent changer (ACL par défaut, etc….) ou des confs spécifiques nécessaires.
Un peu de dev, pas méchant, faut juste pas se foirer :)

David

> Le 10 juil. 2024 à 10:49, Laurent-Charles FABRE <lc.fa...@gmail.com> a écrit :
> 
> Hello,
> 
> Merci pour les explications
> On converge donc sur une misconfig.
> Ça me rassure vu que je commence à en avoir pas mal dans la nature.
> 
> Pour le fait que ça sorte bien de la chine je n'irai pas jusqu'à suggérer que 
> c'est intentionnel ;-)
> CF l'article de l'Etic Hacker qui a suivi un réseau de Windows compromis 
> utilisé par une école Informatique chinoise en hack Demo !
> 
> Pour le hacking via le lan, il y a aussi le fait qu'on puisse accéder un 
> MKtik en L2.
> Et là, pas de filtrage IP...
> 
> Pour les autres remarques,
> on râle que MKtik ca rame en convergence BGP
> On ne va pas maintenant râler que ce compute trop vite ;-)
> Perso, je regarde du côté de la perf cpu pour VxLan vu que ce n'est pas 
> (encore ?)  L3HW
> Vu le prix des CCR2004 & CCR2116, je ne trouve rien de mieux comme VTEP si ça 
> tient le débit.
> (et que ce n'est pas troué en sécu :-)
> 
> Ça m'amène une autre question ;
> comment faites vous pour gérer la conformité en masse sur une flotte de 
> Mikrotik ?
> Je pousse bêtement un squelette de conf via la console mais il y a peut être 
> plus malin ?
> Un soft qui utiliserai l'API native,
> Ou mieux, un soft agnostique qui fait ça sur toute boîte avec un CLI ?
> 
> Joyeux mercredi :-)
> Laurent FABRE
> 
> 
> 
> Le mar. 9 juil. 2024 à 22:09, Jérôme Marteaux <jer...@dedwen.info 
> <mailto:jer...@dedwen.info>> a écrit :
> Le 09/07/2024 à 18:00, Laurent-Charles FABRE a écrit :
> > Bonjour la liste,
> > 
> > l'article doit exister en français mais je suis tombé sur la version
> > Britonne
> > 
> > https://blog.ovhcloud.com/the-rise-of-packet-rate-attacks-when-core-routers-turn-evil/
> >  
> > <https://blog.ovhcloud.com/the-rise-of-packet-rate-attacks-when-core-routers-turn-evil/>
> > 
> > De votre compréhension, c'est un gros trou dans RouteurOS ou une misconfig
> > basique avec MdP troué ?
> > 
> 
> SNMP n'est pas activé par défaut sur mikrotik:
> v6: https://wiki.mikrotik.com/wiki/Manual:SNMP 
> <https://wiki.mikrotik.com/wiki/Manual:SNMP>
> v7: https://help.mikrotik.com/docs/display/ROS/SNMP 
> <https://help.mikrotik.com/docs/display/ROS/SNMP>
> 
> Il y a de (très) fortes chances que ce soit un SNMP qui soit ouvert.
> La mode est d'utiliser de l'amplification (reflexion), SNMP se prête 
> bien à ce jeu, à partir d'une requête de 68 octets, la réponse peut 
> aller jusqu'à 30 Ko, j'ai lu qu'en moyenne il était observé un rapport 
> de 1:25 en faveur de l'attaquant. (si l'attaquant dispose de 100 Mbps de 
> bande passante, il va pouvoir envoyer 2,5 Gbps de réponses SNMP sur l'IP 
> ciblée)
> Pour en savoir plus: https://www.bortzmeyer.org/attaques-reflexion.html 
> <https://www.bortzmeyer.org/attaques-reflexion.html>
> 
> Si l'attaque est faite via SNMP qui donc est ouvert, c'est alors tout 
> simple de faire une requête pour afficher le modèle et sa version.
> 
> Quant aux routeurs dont le SNMP n'est pas ouvert en public, il reste 
> possible que ces routeurs aient une ACL qui limite l'accès à SNMP au LAN 
> mais si les machines derrières sont compromises, il est aisé de faire de 
> l'amplification SNMP et renvoyer le trafic sur le WAN, en plus comme 
> c'est le routeur qui émet le trafic ça bypass les règles de firewall car 
> en général le trafic émit par le firewall est toujours autorisés (au 
> moins sur les mikrotik, chaîne output en default policy accept versus 
> forward dont la bonne pratique doit être default deny).
> 
> 
> Par contre, j'ai un doute avec le contenu du dernier paragraphe "Let’s 
> do some math" car ça m'étonnerait qu'un mikrotik (ou tout autre 
> équipement) ai un service SNMP qui soit capable de sortir autant de pps 
> qu'en routage pur. (Multi-threadé ? Sur tous les core ? Avec 1 seule IP 
> de sortie ?)
> 
> Haaaa on n'avait pas ce genre de problème avec des SUP720 ou des ISR 
> avec des CPU anémiques ! C'était mieux avant !
> 
> Maintenant avec des tp-link, mikrotik et compagnie qui ont des CPU 
> surpuissants (comme nos téléphones), tout est possible !
> 
> > Par contre, j'en retire au moins ça :
> > - les CCR poussent quand même pas mal
> 
> Le rapport perf/prix est imbattable !
> 
> > - ils en vendent pas mal en chine...
> > 
> 
> Mais que fait le great firewall chinois ?? Depuis internet vers la chine 
> ça à l'air efficace mais en sortie tout est permis !
> 
> 
> Jérôme
> 
> -- 
> Jérôme Marteaux
> 
> 
> ---------------------------
> Liste de diffusion du FRnOG
> http://www.frnog.org/ <http://www.frnog.org/>


---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/

Répondre à