Re: [FRnOG] [TECH] Attaques en série
Yop Jérémy, on a déjà eu ca … y a longtemps ;) tant que tu n’as pas la capa de transit pour absorber tout l’entrant, tu n’as pas bcp de choix … (la course à la plus grosse …) pour moi, dans ton cas, le plus simple/meilleur compromis c’est encore d’avoir un port de transit en entrant qui ne sert qu’à filtrer (ACLs à négocier avec le transitaire mais 53+123 c'est facile à avoir normalement) en temps normal tu annonces rien dessus, ton traff passe par tes ports habituels avec ce transitaire, si DDoS, tu annonces les IPs à filtrer sur ton port filtrant (les /32 en no-export, si les /32 sont autorisées -> ca se négocie, sinon le /24 si t’as pas le choix, tjrs en no-export pour que ca reste chez ce meme transit), ton transit de prod est pas touché comme ca, au pire ca sature ton port de nettoyage (et impact limité au préfixe annoncé donc) à priori, un port 1gb/s peut suffir pour faire ca (donc pas cher à faire et facile à négocier avec un transit existant normalement) (à dimensionner en fonction de la taille de préfixe que tu annonces, un /24 tu voudras p-e plus que 1gb/s par ex) soyons clairs, ca soulagera pas le client impacté, mais au moins ton infra résiste « globalement » et tu peux dormir un peu mieux a+ Mik PS: petite dédicace à Arbor pour le nb de mitigations simultanées ridicule qui se fait pawner par ce type d’attaques tournantes ;) (quand le licensing vient tuer le concept, c’est dommage ;) > Le 26 sept. 2017 à 22:08, Jeremy <li...@freeheberg.com> 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/ — Mickael Marchand, Responsable Equipe Réseau et Sécurité - Online.net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Nexus 3000 1U : ventilos à l'endroit ou à l'envers ?
> Le 24 mai 2017 à 18:38, Michel Py <mic...@arneill-py.sacramento.ca.us> a > écrit : > >> Olivier Vailleau a écrit : >> Je reste partisan de tout souffler dans le même sens, mais aussi d'avoir le >> brassage réseau à l'arrière. Pour moi, il faut donc que les switchs crachent >> leur air chaud à l'arrière du rack (bref, dans le même sens que les >> serveurs). > > Il semble que tout le monde soit d'accord, merci à tous. Front-to-back > airflow, port side exhaust. > > >> Jean-Daniel Pauget a écrit : >> Apres, les blocs alims et ventilos existent dans les deux sens de >> soufflerie, et il convient de prendre les bons au moment de l'achat ... > > C'est prohibitif de se tromper ou de changer d'avis, est-ce que quelqu'un a > déjà essayé de retourner les ventilos ? sur nexus 9k et fex 2xxx ca se fait à chaud, sans aucun problème (ca supporte de faire tourner les 2 sens en parallèle le temps du swap) sur n3k ca doit être la meme je pense. tu as meme une gamme d’alim/fan ou tu peux changer le sens via la config maintenant (mais faut reload par contre il me semble après) Mik > >> Aurélien a écrit : >> Et d’ailleurs, est-ce que vous savez si il existerait un genre de tunnel à >> air, de taille >> 1U en façade, en forme de tunnel sur la profondeur jusqu’au switch (donc un >> minimum >> ajustable) et qui guiderait le flux d’air froid aspiré en façade sur le U du >> switch ? >> Genre un truc comme ça, mais abordable, et adapté à l’intake par les PSU: >> http://www.interworldna.com/images/itwatchdogs/pdf/10001003_sa1-01001nb_brochure_1_ie.pdf > > J'ai vu quelques fois des bidouilles en carton avec du scotch, et j'avais > trouvé çà un peu nul, mais en y réfléchissant un peu plus c'est une bonne > idée, car la plupart des switchs sont nettement plus courts que le rack, et > effectivement ils vont aspirer l'air tiédasse du milieu du switch. > > Michel. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ -- Mickael Marchand, Responsable Equipe Réseau et Sécurité - Online.net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Pertes de paquets en UDP depuis SFR/NC vers ONLINE-DC3 depuis 1 semaine
Wrst StDev > 1.|-- box0.0%500.4 0.4 0.3 0.4 0.0 > 2.|-- ??? 100.0500.0 0.0 0.0 0.0 0.0 > 3.|-- pal1rj-ge-2-1-0.200.numer 0.0%506.9 8.0 6.7 11.3 1.0 > 4.|-- 172.19.132.118 0.0%50 clear 11.7 11.3 8.3 15.1 > 1.5 > 5.|-- numericable.bb1.dc3.poney 0.0%509.9 11.3 9.9 16.7 1.1 > 6.|-- 45x-s43-1-a9k1.dc3.poneyt 0.0%50 14.6 13.3 10.2 19.7 2.4 > 7.|-- 212.83.x.x 0.0%50 11.3 10.7 9.5 11.6 0.6 > > # mtr -c 50 -s 1300 -u --report 212.83.x.x # IP Online > HOST: firewall-bureau Loss% Snt Last Avg Best Wrst StDev > 1.|-- box0.0%500.4 0.4 0.4 0.9 0.1 > 2.|-- ??? 100.0500.0 0.0 0.0 0.0 0.0 > 3.|-- pal1rj-ge-2-1-0.200.numer 0.0%506.9 7.9 6.7 9.8 0.8 > * 4.|-- 172.19.132.118 0.0%50 12.3 11.5 9.1 17.8 > 1.6* > * 5.|-- numericable.bb1.dc3.poney 16.0%50 10.4 11.3 10.0 15.3 > 1.0* > 6.|-- 45x-s43-1-a9k1.dc3.poneyt 18.0%50 15.8 14.0 10.3 33.9 4.4 > 7.|-- ??? 100.0500.0 0.0 0.0 0.0 0.0 > > ONLINE => SFR: quasiment aucune perte sur ICMP et quasiment aucune perte sur > UDP # mtr -c 50 -s 1300 --report 109.12.x.x # IP SFR > HOST: serveur Loss% Snt Last Avg Best Wrst StDev > 1.|-- firewall-hebergeur 0.0%500.1 0.1 0.1 0.3 0.0 > 2.|-- 62-210-188-1.rev.poneytel 0.0%501.3 2.5 0.7 7.2 1.7 > 3.|-- a9k2-45x-s43-1.dc3.poneyt 0.0%500.7 0.8 0.7 2.0 0.3 > 4.|-- lag-online-2.dc3-2.rt.hop 0.0%500.3 0.4 0.3 1.3 0.1 > 5.|-- lag-pop-std-1.dc3-1.rt.ho 0.0%500.6 0.7 0.6 2.2 0.3 > 6.|-- sfr.std-1.rt.hopus.net 0.0%504.8 2.9 1.0 5.0 1.2 > 7.|-- 226.122.3.109.rev.sfr.net 0.0%505.2 5.4 3.5 7.6 1.1 > 8.|-- 241.122.3.109.rev.sfr.net 0.0%505.7 4.7 3.0 6.7 1.2 > 9.|-- 193.224.65.86.rev.sfr.net 0.0%503.3 3.4 3.1 4.6 0.2 > 10.|-- 195-132-10-228.rev.numeri 2.0%502.9 2.9 2.8 3.1 0.0 > 11.|-- ??? 100.0500.0 0.0 0.0 0.0 0.0 > > # mtr -c 50 -s 1300 -u --report 109.12.x.x # IP SFR > HOST: serveur Loss% Snt Last Avg Best Wrst StDev > 1.|-- firewall-hebergeur 0.0%500.2 0.1 0.1 0.2 0.0 > 2.|-- 62-210-188-1.rev.poneytel 0.0%505.0 3.4 0.7 15.3 3.2 > 3.|-- a9k2-45x-s43-1.dc3.poneyt 0.0%500.8 0.9 0.7 2.2 0.4 > 4.|-- lag-online-2.dc3-2.rt.hop 0.0%500.4 0.4 0.3 0.7 0.1 > 5.|-- lag-pop-std-1.dc3-1.rt.ho 0.0%500.8 0.8 0.6 2.9 0.5 > 6.|-- sfr.std-1.rt.hopus.net 0.0%503.0 2.9 0.9 5.2 1.2 > 7.|-- 226.122.3.109.rev.sfr.net 0.0%503.7 5.3 3.3 7.2 1.1 > 8.|-- 241.122.3.109.rev.sfr.net 0.0%504.7 4.8 2.8 6.8 1.2 > 9.|-- 193.224.65.86.rev.sfr.net 0.0%503.6 3.4 3.2 5.4 0.3 > 10.|-- 195-132-10-228.rev.numeri 2.0%503.0 2.9 2.8 3.0 0.1 > 11.|-- ??? 100.0500.0 0.0 0.0 0.0 0.0 > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ <http://www.frnog.org/> — Mickael Marchand, Responsable Equipe Réseau et Sécurité - Online.net --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [JOBS] Online.net DevOps Network Junior
Bonjour à tous, Online.net <http://online.net/> recrute un DevOps Network (profil Junior en network, moins Junior en DevOps ;) Au sein de l'équipe réseau, le DevOps aura à charge de moderniser et développer les systèmes d'automatisation, de tests, d'intégration, de sécurité et de monitoring des équipements réseaux au sein des SI de la société. Il aura ainsi à travailler au travers divers projets de développement pour intégrer les nouveaux outils, équipements et process réseaux dans les SI de la société et de participer aux tests, validations et à la mise en production des réseaux. ENVIRONNEMENT • Multiples Datacenters/POPs • Backbone Réseau de capacité de plusieurs Tb/s • Plusieurs milliers d'équipements réseaux (divers équipementiers et matériels totalement désignés en interne) • Travail en collaboration avec nos équipes de développement SI (API REST) COMPÉTENCES • Python / API REST / JSON • Shell • Notions de base du fonctionnement des réseaux (TCP/IP, IPv4/IPv6, Ethernet) • Des notions sur les protocoles de routages sont un plus (OSPF,BGP,VXLAN) • Notions de configurations d'équipements réseaux (Cisco, Juniper) • Linux OFFRE • Type de contrat : CDI, 35 heures • Lieu : Paris ( déplacements à prévoir en Ile de France ) • Rémunération : 35k+ (Suivant expérience) • Avantages : mutuelle, prévoyance, participation, tickets restaurants, promenades en poneys ... • Candidature à recrutement [at] online [dot] net sous la référence en objet : [ DevOps/Network Junior (H/F) ] N’hésitez pas à me contacter en privé si vous avez des questions, Mickael — Mickael Marchand, Responsable Equipe Réseau et Sécurité - Online.net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Problème quand session up sur RS FranceIX
tu as demandé aux amis du NOC FranceIX ? ca sent le VPLS en vacances/cache de MAC,arp,... Mik PS: ca marche depuis chez moi en direct sur le POP FranceIX DC3, essaye d'identifier vers quel POP FranceIX tu as des soucis p-e ... On Mon, Sep 14, 2015 at 07:43:48PM +, Julien OHAYON wrote: > Effectivement ça ne ping pas non plus, timemout depuis mon IP d'interco > FranceIX. > > Julien > > De : David Ponzone <david.ponz...@gmail.com> > Envoyé : lundi 14 septembre 2015 21:40 > À : Julien OHAYON > Cc : frnog-t...@frnog.org > Objet : Re: [FRnOG] [TECH] Problème quand session up sur RS FranceIX > > Tu as le problème aussi en faisant le ping depuis ton IP FranceIX ? > > Le 14 sept. 2015 à 20:29, Julien OHAYON <j.oha...@xoxo.fr> a écrit : > > > Salut David, > > > > Merci pour ce retour, non je ne peux même pas ping le serveur en face donc > > pas un problème de MTU. > > > > Julien > > > > De : David Ponzone <david.ponz...@gmail.com> > > Envoyé : lundi 14 septembre 2015 19:57 > > À : Julien OHAYON > > Cc : frnog-t...@frnog.org > > Objet : Re: [FRnOG] [TECH] Problème quand session up sur RS FranceIX > > > > Tu n’arrives pas à contacter = > > 1/ tu n’arrives pas à pinger ? > > 2/ le ping passe mais HTTP qui ne passe pas ou partiellement ? > > > > Si on est dans le cas 2, ça pourrait être une histoire de MTU. Regarde si > > un ping de 1500 octets passe avec et sans fragmentation. > > Et ensuite un paquet de 1501, avec et sans frag. > > > > Le 14 sept. 2015 à 18:34, Julien OHAYON <j.oha...@xoxo.fr> a écrit : > > > >> Bonjour, > >> > >> > >> J'ai un soucis que je n'arrive pas a résoudre et il faut des fois savoir > >> demandé de l'aide :) > >> > >> > >> Nous sommes présent sur FranceIX (sur les RS) et depuis environ 2 semaines > >> si ma session est UP je n'arrive pas à contacter certains réseaux. > >> > >> > >> Ex : > >> > >> - lemonde.fr > >> > >> - speedtest.net > >> > >> - certains serveurs de google par intermittence > >> > >> - etc... > >> > >> > >> Au début j'ai tenté s'exclure via les communautés BGP edgecast, ça a > >> résolu une partie du problème, car ce n'est pas le seul. > >> > >> Par exemple, Google ça fonctionne sans problème si via les communautés je > >> n'envoie aucune route sauf à eux la le traffic s'écoule bien. > >> > >> Hélas il y a beaucoup d'autres sites ou nous avons le problème. > >> > >> > >> EdgeCast ne me donne pas le chemin reverse donc impossible de voir avec > >> eux... > >> > >> Google ne trouve pas de problème... > >> > >> > >> Bref je désespère un peu, une idée pour faire avancer ma recherche ? > >> > >> > >> Si vous voulez voilà une IP d'un bloc que j'ai mis sur le RS afin de faire > >> mes recherches : 130.117.11.69 > >> > >> > >> Merci > >> > >> Julien OHAYON > >> > >> --- > >> Liste de diffusion du FRnOG > >> http://www.frnog.org/ > > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ -- Mickael Marchand, Ingénieur Réseau et Sécurité - Online.net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] [ps...@cisco.com: Cisco Security Advisory: Cisco IOS Software Crafted IPv6 Packet Denial of Service Vulnerability]
hello, On mer., mars 26, 2014 at 05:18:08 +0100, Stephane Bortzmeyer wrote: Six vulnérabilités qui permettent une DoS, d'un coup. C'est ça qui a planté la salle 103 du DC2 récemment ? à priori non, meme si y a des ressemblances sur les symptomes (mais bon les symptomes sont assez génériques dans le cas de oups ca rentre plus dans les tcams) vu la liste des versions impactées/non-impactées, ca ne colle pas avec nos tests en lab de notre bug Cisco avance ... doucement ... sur la reproduction du problème chez eux (*soupir*) Mik --- Liste de diffusion du FRnOG http://www.frnog.org/ Date: Wed, 26 Mar 2014 12:10:35 -0400 From: Cisco Systems Product Security Incident Response Team ps...@cisco.com To: sa...@sanog.org Subject: Cisco Security Advisory: Cisco IOS Software Crafted IPv6 Packet Denial of Service Vulnerability Reply-To: ps...@cisco.com -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco IOS Software Crafted IPv6 Packet Denial of Service Vulnerability Advisory ID: cisco-sa-20140326-ipv6 Revision 1.0 For Public Release 2014 March 26 16:00 UTC (GMT) Summary === A vulnerability in the implementation of the IP version 6 (IPv6) protocol stack in Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause I/O memory depletion on an affected device that has IPv6 enabled. The vulnerability is triggered when an affected device processes a malformed IPv6 packet. Cisco has released free software updates that address this vulnerability. There are no workarounds to mitigate this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140326-ipv6 Note: The March 26, 2014, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the March 2014 bundled publication. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTMeUtAAoJEIpI1I6i1Mx35GAP/jkk82q87zMnC9n9e2t9u1DD 7OHUYo7fuXu2L85+zDGgtE7LJ5c9mjZou12A87cjgx4v1B6xvDoemjtoIEmqWKQR LsSoI6oQL6E3PAqeDn70Lrr++kAV/4dCSzoFuiDWa5NLWO2NA1pxoRsF8f/KTENj PvPng8UPlF2WBDqNdTnjR2upDMqn1/jQOMxSSRmkMAOQ0Q3j+g9Pd+rb8ocqTJmg wCj5vXfB52E0HoGddT0UxjkxL1+CR9Jo262LeuRRtMGQsEpK94+L9d4kC/AhhclU RodAJztNC42KdFR4iE1jDHUA8HwhgnkdzuXlA12GIXeHB9EBQR5Te1hyzuAnxq5X x3IeqZnaufO2DmxAVpl3lfEDyKeyAipfCPDtFhEmDF/l12zBRlbMudEwA1Buwriq ayH4798ASI0bBumUiaMiiOyYKbqFL33ONdFMiQZv2lYam1QlYU0Ps3IMiZhD5YHX 9nOKcuWU1Uym+VjHiIKLg5/qQpndg9h+E6mNzZrQSXrpU1nYtwBCZiShBhR5+f4J WYLOVZu5LDpW6mQAhYyKC7ehugeqJZRaZQQX5oi94hlBxz1+4zin8GRVLn/Ibrtq GaeMGODALQjpolszEAt7a4QA5884m++h7Z4Crszr4s4E4j4bUdCEgDc9ynInmO80 OvU1rCkvg7QWSv3HfxI2 =nr53 -END PGP SIGNATURE- ___ sanog mailing list sa...@sanog.org https://lists.sanog.org/mailman/listinfo/sanog -- Mickael Marchand, Responsable Réseau et Sécurité - Online / Iliad Entreprises Tel: +33 (0)1 73 50 29 37, Fax: +33 (0)1 73 50 29 01 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Coupures chez Online cet après-midi
On mer., mars 19, 2014 at 12:20:07 +0100, Vincent Bernat wrote: ❦ 18 mars 2014 20:53 CET, Arnaud aberming...@online.net : C'est fini. Trois coupures en tout, la plus longue de 2h. http://stats.pingdom.com/p5a9jfqdd46c/852886 Un bug packet of death comme on aime en manger :-) impact 1 salle 13% du parc Le CR ici : http://forum.online.net/index.php?/topic/4270-dc2-salle-103-incident-r%C3%A9seau/ Possible de dévoiler quelques caractéristiques du paquet TCP en question ? Il est valide ? Il a des entêtes supplémentaires ? Il est petit ? Il est gros ? Il est malicieux ? yop, on etudie la chose avec cisco dans un premier temps avant de crier trop fort au loup, ca peut etre une configuration particulièrement spécifique chez nous ou un enchainement de circonstances, y a tjrs énormément de possibilités dans ce genre de cas. en tout cas, les symptomes techniques sont un écroulement de la CEF très rapide (quelques secondes après le boot et le up des ports) avec une 20aine de routes connected uniquement (ospf coupé, ospfv3 coupé, routes statiques intégralement supprimées) (donc aucun protocole de routage dynamique, aucune statique, il restait juste les connected) Mar 18 13:52:10 UTC: %C4K_L3HWFORWARDING-4-TCAMFULL: FLC Tcam full, packets will be forwarded in software at reduced rate. Failure due to: add tcam space failed Mar 18 13:52:10 UTC: %COMMON_FIB-3-HW_API: HW API failure for IPv4 CEF [0x11B6B660]: Out of Tcam resource (fatal) (0 subsequent failures ). moins de 30 lignes d'ACL, pas de qos (hors CoPP) mac address-table loin d'etre remplie, idem ARP et moins de 40 routes actives en FIB tout ca sur 2 sup6-E en SSO dans un 4507R-E (ie 256k routes, 55k mac, ... bref on est très loin de la saturation qu'on pourrait attendre sur ce genre de symptomes) (non c'est pas une sup6L-E, c bien des sup6-E ;) c'est d'autant plus étonnant que nos routeurs de rangee/salle ne font vraiment rien d'autre que des fonctions très basiques switch/routing (la plus grosse partie sécurité est déléguée sur les switchs de baie au plus près des serveurs) pdt le debug, Florian a pu identifier un indicateur précis du crash de la CEF sur le routeur ce qui nous a permis ensuite de remonter à l'émetteur progressivement (en testant baie par baie sur ce routeur, ce qui explique en partie la durée de l'intervention, en plus des tests de remplacement des SUP, etc etc puis la restauration complète de la conf ...) voilà à peu près les details qu'on peut donner actuellement, depuis hier on a réussi à reproduire en tout cas ce qui est déjà pas mal ;) Mik PS: et vive les console serie ;) -- Indent to show the logical structure of a program. - The Elements of Programming Style (Kernighan Plauger) --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Mickael Marchand, Responsable Réseau et Sécurité - Online / Iliad Entreprises Tel: +33 (0)1 73 50 29 37, Fax: +33 (0)1 73 50 29 01 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Dos depuis Online / Dedibox
Bonsoir, moue un gros ddos de ouf qui meritait bien d'etre traité ici ... bref... kouik ... a+ Mik PS: le traitement de l'abuse etait en cours, on coupe pas dans la seconde pour un abuse hein ... On Tue, Jan 10, 2012 at 09:26:27PM +0100, Jérémy Martin wrote: Bonjour, Y a quelqu'un sur cette liste qui aurait en contact une personne compétente pour pouvoir stopper un DOS provenant d'une dédibox ? 20:23:56.662781 IP 88.191.134.206.41584 91.229.20.130.9987: UDP, length 50 20:23:56.662787 IP 88.191.134.206.41584 91.229.20.130.9987: UDP, length 50 20:23:56.662791 IP 88.191.134.206.41584 91.229.20.130.9987: UDP, length 50 20:23:56.662797 IP 88.191.134.206.41584 91.229.20.130.9987: UDP, length 50 20:23:56.662802 IP 88.191.134.206.41584 91.229.20.130.9987: UDP, length 50 20:23:56.662809 IP 88.191.134.206.41584 91.229.20.130.9987: UDP, length 50 20:23:56.662845 IP 88.191.134.206.41584 91.229.20.130.9987: UDP, length 50 20:23:56.662850 IP 88.191.134.206.41584 91.229.20.130.9987: UDP, length 50 Le ticket abuse est ouvert : #16225 Merci. -- Cordialement, Jérémy Martin Directeur Technique FirstHeberg.com Contacts téléphoniques (Lun-Ven / 9h30-12h00 - 14h00-17h30) Standard : 09 72 125 539 (tarif local) Ligne directe : 03 66 72 03 42 Mail : j.martin AT freeheberg.com Web : http://www.firstheberg.com __ FreeHeberg.com : Osez l'hébergement gratuit de qualité professionnelle ! PHP + Mysql + Espace 2 à 20 Go --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Mickael Marchand, Online S.A.S. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Dos depuis Online / Dedibox
miam c'est trolldedi deja ? detail de l'abuse : Date de l'infraction 2012-01-10 20:25:00 on a coupe quand deja ? si on veut faire de l'hebergement on y met les moyens , un flood a 180Mb/s qui te paralyse tant que ca, y a un pbl dans la definition de ton archi je pense ... (et t'as pas fini de venir raler chez tout le monde ... mais bon courage ... je compatis...) end of transmission, Mik On Tue, Jan 10, 2012 at 10:51:13PM +0100, Jérémy Martin wrote: Bonjour Mickael, Votre réponse démontre bien le j'en-foutisme de Free concernant les attaques et les dégats que peuvent générer son réseau incontrôlé. Vous me prouvez encore une fois par votre réponse que vous n'avez rien à faire des petits opérateurs, et qu'on peut creuver sous l'écroulement de notre transitaire. C'est bien sympathique de se moquer, mais il faudra peut être un jour que vos équipes et certains autres présents sur cette liste comprennent que nous ne sommes pas tous égaux en matière de capacité, et qu'un dos de 150 Mb/s peut impacter autant qu'un DOS de 3 Gb/s. Pour la suite à donner, j'ai fait null-router l'ip chez notre transitaire, le sujet est clos jusqu'à la prochaine attaque provenant de votre réseau (demain ?). Cordialement, Jérémy Martin Directeur Technique FirstHeberg.com Contacts téléphoniques (Lun-Ven / 9h30-12h00 - 14h00-17h30) Standard : 09 72 125 539 (tarif local) Ligne directe : 03 66 72 03 42 Mail : j.martin AT freeheberg.com Web : http://www.firstheberg.com Le 10/01/2012 22:37, Mickael Marchand a écrit : Bonsoir, moue un gros ddos de ouf qui meritait bien d'etre traité ici ... bref... kouik ... a+ Mik PS: le traitement de l'abuse etait en cours, on coupe pas dans la seconde pour un abuse hein ... On Tue, Jan 10, 2012 at 09:26:27PM +0100, Jérémy Martin wrote: Bonjour, Y a quelqu'un sur cette liste qui aurait en contact une personne compétente pour pouvoir stopper un DOS provenant d'une dédibox ? 20:23:56.662781 IP 88.191.134.206.41584 91.229.20.130.9987: UDP, length 50 20:23:56.662787 IP 88.191.134.206.41584 91.229.20.130.9987: UDP, length 50 20:23:56.662791 IP 88.191.134.206.41584 91.229.20.130.9987: UDP, length 50 20:23:56.662797 IP 88.191.134.206.41584 91.229.20.130.9987: UDP, length 50 20:23:56.662802 IP 88.191.134.206.41584 91.229.20.130.9987: UDP, length 50 20:23:56.662809 IP 88.191.134.206.41584 91.229.20.130.9987: UDP, length 50 20:23:56.662845 IP 88.191.134.206.41584 91.229.20.130.9987: UDP, length 50 20:23:56.662850 IP 88.191.134.206.41584 91.229.20.130.9987: UDP, length 50 Le ticket abuse est ouvert : #16225 Merci. -- Cordialement, Jérémy Martin Directeur Technique FirstHeberg.com Contacts téléphoniques (Lun-Ven / 9h30-12h00 - 14h00-17h30) Standard : 09 72 125 539 (tarif local) Ligne directe : 03 66 72 03 42 Mail : j.martin AT freeheberg.com Web : http://www.firstheberg.com __ FreeHeberg.com : Osez l'hébergement gratuit de qualité professionnelle ! PHP + Mysql + Espace 2 à 20 Go --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Mickael Marchand, Ingénieur Réseau et Sécurité - Iliad Entreprises Tel: +33 (0)1 73 50 29 37, Fax: +33 (0)1 73 50 29 01 --- Liste de diffusion du FRnOG http://www.frnog.org/
