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.frn
[FRnOG] [JOBS] Recherche Alternance Systèmes et Réseaux - Lyon
Bonjour, je suis actuellement à la recherche d'une alternance (contrat de professionnalisation) pour faire un Titre Administrateur Systèmes et Réseaux (BAC+4) en deux ans à l'école It-Akademy ; j'ai actuellement un BTS Services Informatiques aux Organisations ainsi qu'une Licence Professionnelle de Réseaux Industriels et Informatiques. Je n'ai pour le moment qu'une année d’expérience, en alternance en tant que technicien réseaux LAN mais je souhaiterais vraiment reprendre de l'alternance avant de commencer à travailler définitivement. Je recherche une alternance en Administration (en support ou en projet), en tant qu'admin ou que technicien, ou encore en support (préférence sur site). Je suis disponible à partir du 2 Octobre 2017, sur Lyon, véhiculé. Si quelqu'un a une entreprise/personne à me recommander, j'accepterais volontiers, je crois avoir fait le tour des candidatures spontanées sur mon secteur Bonne fin de journée :) Cordialement MADRU Grégory --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Attaques en série
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/
Re: [FRnOG] [TECH] Attaques en série
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/
Re: [FRnOG] [TECH] Attaques en série
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/
Re: [FRnOG] [TECH] Attaques en série
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/
Re: [FRnOG] [BIZ] Refonte infrastructure
On 26/09/2017 15:30, Sébastien FOUTREL wrote: Pour relativiser le propos, il faut faire la différence entre les infras que tu opères pour toi et celles que tu opères pour les autres. Oui complètement. Pour moi, dans mon coin faire du Docker/k8s pourquoi pas. Si ça pète c'est moi que ça regarde. Mais quand je dois opérer pour un autre avec des SLA et des avocats et que je lui dit que mes contraintes ne vont pas avec son contrat et ses SLA qu'il veut c'est plus pareil. On est d'accord. Et sur l'idée même du conteneur fait par et pour les devs (alors que PXE install, Debian et [Ansible,Chef,Puppet] ça marche tres bien et vite) je dirai que si on en est au point de ne pas savoir faire causer les gens du dev et du systeme on a pas des problèmes de technologies mais des problèmes de communication interne. Je crois que l'on dit la même chose. La technologie ne peut et ne dois jamais remplacer la communication. Encore une fois ce ne sont que des outils. Chacun utilise ce qu'il juge le plus opportun. Et pour finir je citerai un philosophe : "YOU BUILD IT, YOU RUN IT" Oula c'est très devops çà :) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Attaques en série
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/
Re: [FRnOG] [TECH] Attaques en série
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/
[FRnOG] [TECH] Attaques en série
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/
Re: [FRnOG] [TECH] EFM et synchro lonnnnguuue
Bonsoir J ais déjà eu une bi paire à 10mn qui était stable pendant plusieurs heures et avoir de très fortes perturbations très aléatoires Richard Envoyé de mon BP2 ( silent circle inside ) > Le 26 sept. 2017 à 17:59, David Ponzone a écrit : > > Quelqu'un a déjà vu un EFM (4Mbps 1 paire donc SHDSL.bis) mettre 30 minutes > au total pour que toutes les paires se synchronisent sans erreurs ? > > En gros: > -au boot: 1 paire UP seulement, une autre qui bagote, 2 DOWN > -5/10 min après: 3 paires UP et 1 qui bagote > -environ 25/30 min après le boot: les 4 UP > > J'avais déjà eu du 5 min mais jamais un comportement aussi délirant. > > Ca fait maintenant 5h que c'est up et pas un CRC, ni rien. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] EFM et synchro lonnnnguuue
Quelqu'un a déjà vu un EFM (4Mbps 1 paire donc SHDSL.bis) mettre 30 minutes au total pour que toutes les paires se synchronisent sans erreurs ? En gros: -au boot: 1 paire UP seulement, une autre qui bagote, 2 DOWN -5/10 min après: 3 paires UP et 1 qui bagote -environ 25/30 min après le boot: les 4 UP J'avais déjà eu du 5 min mais jamais un comportement aussi délirant. Ca fait maintenant 5h que c'est up et pas un CRC, ni rien. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [JOBS] Marketing Intelligence
Bonjour à tous, OUTSCALE recrute toujours ! Fort de 140 collaborateurs dans le monde, notre activité s'étend de plus et j'ai besoin de vous pour notre activité MARKETING. Oui, vous avez bien lu, je post sur FRNOG un job pour marketeux. Mais pas n'importe lequel, je suis à la recherche du 007 du Cloud ! Il s'agit d'un poste de Marketing Intelligence, il faut tester les offres disponibles potentiellement en compétition avec les nôtres, les étudier et aider les responsables produits à proposer des alternatives tout en étant concurrentiel. C'est un job à la fois technique et marketing, dans le sens de l'étude du marché et non de la symphonie de flutes, qui demande des compétences fortes pour mettre en oeuvre les solutions concurrentes QUI FONCTIONNENT ! En plus des compétences techniques, il faut être capable de rédiger des specs et de construire des matrices de fonctionnalités/compatibilités mais globalement les compétences nécessaires sont celles d'un admin sys avec si possible des connaissances AWS, Azure, VMWare, etc. (mais il peut apprendre sur le tas). Si cela vous intéresse, le poste est basé sur Saint Cloud et le salaire varie entre 40-50k€ selon l'expérience. Merci pour vos candidatures. D'autres offres d'emploi sont disponibles sur : https://fr.outscale.com/carrieres/#joblist Laurent Seror. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Refonte infrastructure
Pour relativiser le propos, il faut faire la différence entre les infras que tu opères pour toi et celles que tu opères pour les autres. Pour moi, dans mon coin faire du Docker/k8s pourquoi pas. Si ça pète c'est moi que ça regarde. Mais quand je dois opérer pour un autre avec des SLA et des avocats et que je lui dit que mes contraintes ne vont pas avec son contrat et ses SLA qu'il veut c'est plus pareil. Et sur l'idée même du conteneur fait par et pour les devs (alors que PXE install, Debian et [Ansible,Chef,Puppet] ça marche tres bien et vite) je dirai que si on en est au point de ne pas savoir faire causer les gens du dev et du systeme on a pas des problèmes de technologies mais des problèmes de communication interne. Et pour finir je citerai un philosophe : "YOU BUILD IT, YOU RUN IT" Cordialement Le 22 septembre 2017 à 10:39, Kirth Gersen a écrit : > Docker c'est relativement 'bas niveau' par rapport au besoin exprimé. > je partirai plutôt sur du Kubernetes (abrégé en k8s) ou au dessus > (OpenShift, Tectonic, etc). > Les 3 gros cloud providers du moment (Google GCP, Amazon AWS , Microsoft > Azure) ont des solutions k8s avec un net avantage a Google pour docker/k8s > (c'est la techno interne utilisé chez Google donc en terme de 'ca marche en > prod' c'est plus rassurant que chez Microsoft par exemple) > > Mais être 'provider' agnostic ca ne va pas être forcement simple et > introduite une complexité plus grande que de modif le code en cas de > changement de provider. C'est l'avantage de k8s: c'est juste des fichiers > de conf a changer pour passer du stockage Google au stockage AWS par > exemple, le 'driver' de k8s s'occupe du reste. Avec la notion de namespace > (prod, preprod, dev) çà rejoint un peu le 'rêve' exprimé par l'OP. > > Et pour ce qui est des anti-Docker en prod, ils sont soient resté bloqués > quelques années en arrière soit leur job est menacé par ce genre de techno > donc leur propos sont a relativiser fortement :) > > > > Le ven. 22 sept. 2017 à 08:35, Stéphane Cottin mailto:noc@ > vixns.net>> a écrit : > Bonjour Gaël, > > Je peux te faire un retour d'expérience sur du docker en prod, ça > fonctionne très bien ... si tu n'utilises pas docker ( ça c pour > trolldi ) > > J'ai monté plusieurs archis avec Apache Mesos, qui te permet > d'instancier des containers à partir d'images docker sans avoir a > installer aucun outil docker. > Par rapport à la génération précédente (Mesos < 1.0) qui utilisait > le daemon docker, cela n'a plus rien à voir en terme de stabilité / > fluidité (plus de GC, tout est en c++) / consommation CPU "à vide" / > heures de support. > > ArangoDB dispose d'un framework Mesos, cela peut être une bonne > solution pour ton besoin. > > Stéphane > > On 21 Sep 2017, at 23:04, Gaël Demette wrote: > > > Bonsoir la liste, > > > > Aujourd'hui se pose la question de modifier notre infrastructure, > > actuellement exclusivement chez AWS (Ireland), en effet notre stack à > > la base assez simple commence à se complexifier avec nos évolutions > > à venir. Du coup, Elastic Beanstalk commence à ne plus être > > suffisant. On voudrait surtout en profiter pour abstraire le > > fournisseur de Cloud. Malheureusement, notre petite startup n'a pas le > > temps de faire tout cela, et souhaiterait étudier la possibilité > > d'externaliser ces évolutions. > > > > J'avais en tête de tout passer sur Docker. Il faudrait donc faire > > cette prestation, ainsi que nous former sur le fonctionnement de > > l'infrastructure faite. > > > > Stack actuel : > > > > * S3 pour deux applications EmberJS (SPA) > > * AWS Elastic Beanstalk (Avec nginx + NodeJS) -> Deux environnements, > > le premier l'API (REST et websockets), le second une app NuxtJS (SPA > > avec server-side rendering) > > * AWS ElastiCache (Redis) > > * Simple replicaset MongoDB (sur des EC2) > > > > Stack cible : > > > > * ArangoDB > > * RabbitMQ (non fixé, si vous avez des suggestions sur des > > alternatives, on est ouvert) > > * MongoDB (On ne souhaite pas tout migrer sur ArangoDB d'un coup sans > > plus de feedbacks) > > * Plus de EmberJS > > * Probablement plus de Redis (Pub/Sub couverte par RabbitMQ, key-value > > storage couvert par ArangoDB), ça ne me gène pas de rester sur > > ElastiCache le temps que nos devs fassent le nécessaire ;) > > * Trois environnements "AWS Elastic Beanstalk like", API + Website > > (NuxtJS) + Backoffice (Anciennement les deux apps EmberJS, > > nouvellement NuxtJS avec Server side rendering) > > > > Mon rêve serait d'avoir une infra qu'on puisse utiliser tant pour > > mettre en place des environnements à la volée, identiques à la > > prod, et ce de manière agnostique du fournisseur de serveurs / cloud, > > Docker semblait faire sens ici. "Plus qu'à" ajouter un système > > permettant de scale, monitor, et self heal et on est bon. > > > > Il me faudrait des propositions commerciales pour ce genre de > > prestation, n'hésitez pas à me contacter en privé, avec un ordre de > > prix. Et en me deman
Re: [FRnOG] [BIZ] Refonte infrastructure
Le 25/09/2017 à 21:57, Raphael Mazelier a écrit : > > > On 25/09/2017 12:24, Wallace wrote: >> Bien résumé Eric et pour avoir tenu un discours comme celui de Raphael à >> des boites qui faisaient n'importe quoi en conteneur, la réponse est ha >> oui mais c'est super compliqué et trop abstrait de faire comme cela. En >> gros le côté éphémère leur fait super peur et c'est complètement >> abstrait = risque +++ pour les directions donc ils ne font pas. >> > > OK donc tu critiques la mauvaise mise en place des containers pas les > containers en tant que tel. Mais c'est exactement pareil sinon pire de > multiplier plein de petite vm(s) en terme de sécurité. > Un container ne devrait être vu que comme une instance (dans le vrai > sens instanciation objet) d'une application/service. Je répond sous le paragraphe suivant puisque c'est lié. > >> Après même avec une superbe archi conteneur, si tu fais toutes tes >> images pour être iso27001, pcidss et HDS le côté éphémère complexifie >> grandement le traitement des métriques / logs et le suivi qualité. >> > > Non c'est l'inverse. Évidement il faut prendre cela en compte dès la > création du container. Par exemple chez nous toutes les applications > "dockerisé" ont obligation d'envoyer leurs logs de manière structuré à > un système de log central (graylog en l’occurrence). > > Au final j'ai l'impression que l'on parle de deux choses différentes. > Remplacer des vm(s) par des containers n'a aucun sens en effet. > > Développer une nouvelle stack/SI dans un environnement container est > une grande opportunité. La où je te rejoins c'est qu'il y a une grande > courbe d'apprentissage que ce soit coté dev ou coté ops. Et là on reboucle sur le sujet, les conteneurs c'est super si on les fait soit même, on met ce que l'on veut : la sécurité, le déport de métriques / logs, les mises à jour, ... mais cela implique de faire ses images. Ca ne va clairement pas dans le sens des dirigeants qui y voient le gain financier temps / emmerdement à cours terme. Le pire ce sont les images officielles des applications, c'est officiel donc ça ne peut pas être foncièrement mauvais dixit des DSI et de DT. > >> Faut penser aussi aux audits externes qui peuvent être imposés genre >> suite à une fuite de données, la CNIL / ANSI qui vient auditer. Aucune >> des boites que j'ai vu faire du conteneur n'est apte à répondre à la >> moindre question d'extraction de donnée. Et quand on pense aux données >> que ces boites voient transiter c'est pas du tout rassurant pour nos >> profils persos. >> > > Parce c'est différent dans un environnement classique ? On reboucle sur le souci des images stock ou custom, en stock oui y a une différence parce qu'en VM l'OS peut être modifié facilement (à la main, script, automate) en conteneur c'est trop complexe pour les équipes qu'on croise. Du coup l'option de facilité c'est de dire ces mesures de sécurité, ces conformité c'est pas bien grave on relancera l'instance en cas de soucis ... > >> C'est aussi ça le rôle d'un hébergeur infogéreur, être sûr que son >> client soit apte à répondre à la loi en cas de besoin. >> >> Je trouve qu'une solution Ansible telle qu'on l'a monté chez nous qui >> permet de faire du on demand sur différents hosteurs c'est tout aussi >> souple. L'intégration d'une VM ça prend 5 min max avec le déroulé >> Ansible mettant tout aux normes. Avantage on peut aussi commander des >> baremetal et avoir des ressources bien différentes qui s'intègrent en >> 10/15 min max si le hosteur livre rapidement. >> > > Je ne vois toujours pas en quoi cela serait plus difficile dans un > environnement container. Ne pas oublier qu'un container n'est rien de > plus qu'un ensemble de process un peu isolé. Donc sécuriser n'importe > quelle application ou un container c'est pareil. Ca implique toujours une image conteneur custom. Sinon lancer un outil automate dans un OS conteneur qui est censé se regénérer toutes les x minutes / heures n'a que peu de sens. > >> Et là aussi même constat dans tous les boites et mêmes administrations >> qui utilisent Amazon ou Azur j'ai jamais vu une seule donnée chiffrée. >> C'est complètement irresponsable. J'ai vu des données santé brutes >> (image IRM, doc rapport du médecin, fichier txt avec le mot de passe par >> défaut 12345 pour en faire un mémo, nom des patients dans le nom de >> fichier, ...) aller chez Amazon et Azur pour le PRA. A titre personnel >> ça ne me donne même plus envie d'aller voir des médecins qui ont du >> matériel connecté. Et quand on fait réagir le client sur ce point, ha >> mais les médecins on peut rien leur demander, c'est les maîtres ici, >> 12345 c'est déjà trop compliqué pour eux comme mot de passe ils >> appellent le support quand le verr num n'est pas activé ... Et le cloud >> public c'est pratique on a pas d'infra à mettre en place et à gérer. >> > > Là encore tu critiques des mauvaises pratiques. Je ne penses pas que > les gros encouragent ce genre de choses. D'ailleurs Amazon (pour ne > citer q
Re: [FRnOG] [BIZ] Refonte infrastructure
Le 25/09/2017 à 23:26, Colin J. Brigato a écrit : > « Les containers c’est mauvais – la preuve en est : regardez toute la merde > que les gens en font » C'est sans doute pas assez mis en avant mais on fait des conteneurs juste qu'on le fait dans le contexte qui nous parait être le plus approprié pour ne pas négliger la sécurité et les remontées nécessaires aux équipes OPS et à la loi. Par contre oui on refuse de faire du conteneur comme on le voit lors de nos audits. signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] Manger de la soupe ?
Bonjour, Je pense que l'aspect sécurité doit être géré comme pour toute intervention en milieu industriel. L'entreprise utilisatrice et l'entreprise extérieure doivent rédiger un plan de prévention : https://www.legifrance.gouv.fr/affichCode.do?idSectionTA=LEGISCTA18529787&cidTexte=LEGITEXT06072050&dateTexte=20110627 - Un sous-traitant peut-il refuser de dépanner s'il n'a pas un accès sécurisé à la baie ? Oui. Cela doit être prévu et analysé par les deux parties AVANT intervention. - Qui est responsable s'il tombe et tue deux clients au passage ? Dans ce cas précis, probablement l'entreprise utilisatrice : elle aurait du prévoir ça dans le plan de prévention et prendre les mesures adaptées pour éviter ce risque. - Que dirait un inspecteur du travail s'il voyait un mec jouer à Tarzan ou à Indiana Jones avec un escabeau sur une palette en haut d'un Clark sans harnais ? Jocker. - Sachant qu'il est impossible actuellement de positionner une nacelle en position de travail devant la baie, en tant que sous-traitant, quelle est ma responsabilité (et de quoi ai-je besoin pour me couvrir) si je dois tout de même intervenir sur une telle installation ? Il faut ici une nacelle adaptée pour atteindre la zone. Si c'est impossible, l'enterprise utilisatrice doit prendre des mesures adaptées. Si il y a une intervention, les deux entreprises seront responsables. Ronan 2017-09-26 10:24 GMT+02:00 Toussaint OTTAVI : > > Le 26/09/2017 à 07:30, Ducassou Laurent a écrit : > >> C'est dans des cas comme ça où tu te dis que un réseau "tout FTTx" même >> en LAN est le bien... Car adieu les contraintes de distances de 100m >> > > Le problème du tout FTTx, c'est que les équipements terminaux sont tous en > connectique RJ45 cuivre, et donc qu'il faut rajouter des switches ou des > convertisseurs. Moi, c'est ce que j'aurais fait : des mini-coffrets avec > des switches au plus près de l'utilisation, intégrés dans le mobilier. > > -- > > Pas de commentaires sur l'aspect sécurité ? > > - Un sous-traitant peut-il refuser de dépanner s'il n'a pas un accès > sécurisé à la baie ? > - Qui est responsable s'il tombe et tue deux clients au passage ? > - Que dirait un inspecteur du travail s'il voyait un mec jouer à Tarzan ou > à Indiana Jones avec un escabeau sur une palette en haut d'un Clark sans > harnais ? > - Sachant qu'il est impossible actuellement de positionner une nacelle en > position de travail devant la baie, en tant que sous-traitant, quelle est > ma responsabilité (et de quoi ai-je besoin pour me couvrir) si je dois tout > de même intervenir sur une telle installation ? > > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [SPAM] RE: [FRnOG] [MISC] Manger de la soupe ?
Le 26/09/2017 à 07:36, br...@skiwebcenter.fr a écrit : Et là tu penses à la bêtise des nouveaux réseaux FTTH avec les boitiers sur les poteaux à 1M70 du sol... à la portée du premier gamin venu qui va arracher les épissures :/ On a pareil sur le cuivre dans le rural par chez nous. Les nouveaux PC sont systématiquement installés à hauteur d'homme. Cà permet aux techniciens cuivre/xDSL d'intervenir immédiatement, là ou avant, il fallait des habilitations pour grimper aux poteaux (que plus personne n'a) ou des nacelles, ce qui rajoutait un ou deux jours pour la réparation. A moins que cela ne soit parce que la très grande majorité des poteaux sont vétustes, et que d'y clouer une étiquette jaune "Montée interdite" coûte moins cher que de tous les remplacer ;-) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Manger de la soupe ?
Le 26/09/2017 à 07:30, Ducassou Laurent a écrit : C'est dans des cas comme ça où tu te dis que un réseau "tout FTTx" même en LAN est le bien... Car adieu les contraintes de distances de 100m Le problème du tout FTTx, c'est que les équipements terminaux sont tous en connectique RJ45 cuivre, et donc qu'il faut rajouter des switches ou des convertisseurs. Moi, c'est ce que j'aurais fait : des mini-coffrets avec des switches au plus près de l'utilisation, intégrés dans le mobilier. -- Pas de commentaires sur l'aspect sécurité ? - Un sous-traitant peut-il refuser de dépanner s'il n'a pas un accès sécurisé à la baie ? - Qui est responsable s'il tombe et tue deux clients au passage ? - Que dirait un inspecteur du travail s'il voyait un mec jouer à Tarzan ou à Indiana Jones avec un escabeau sur une palette en haut d'un Clark sans harnais ? - Sachant qu'il est impossible actuellement de positionner une nacelle en position de travail devant la baie, en tant que sous-traitant, quelle est ma responsabilité (et de quoi ai-je besoin pour me couvrir) si je dois tout de même intervenir sur une telle installation ? --- Liste de diffusion du FRnOG http://www.frnog.org/