[FRnOG] [ALERT] Attaque en déni de service en cours
Bonjour, Le père Noël nous a gâté et nous subissons au Sénat une attaque par déni de service depuis dimanche matin 7h heure locale. La très grosse majorité des paquets est en udp/80 à destination de nos deux liens, completel (213.30.147.224/27) et global crossing (217.156.140.224/27) et aussi un peu en udp/53. Nous tentons d'établir une liste d'adresses sources mais vous vous doutez qu'elle varie beaucoup. Les supports des deux opérateurs sont bien sûr prévenus. Si en plus certains d'entre vous ont la possibilité de bloquer au moins le traffic en udp/80 qui passerait par vos réseaux vers chez nous, ceci nous pemettrait de respirer un peu. Tout avis en la matière sera le bienvenu. Je passe par cette adresse mail perso car pour l'instant nos accès sont saturés. Merci beaucoup et joyeux Noël à tous :-) Charles Delorme --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
Nous avons subi ce genre d'attaque également il y a quelques semaines, le firewall a saturé car les connexions étaient ouvertes très très vites à priori (peu de logs à cause de la saturation), en tout cas plus vite que ce que le firewall ne savait traiter. En bref, 150Mbits/s de trafic inopiné qui a suffit a saturer un équipement central de l'infrastructure. Après vérifications et captures, nous avons énormément d'énumérations DNS depuis des adresses IP chinoises (comme par hasard), nous avons baissé les timeouts des sessions TCP/UDP sur le firewall, et nous n'avons plus eu de problème depuis, même si parfois, nous constations des milliers de sessions sur le firewall en UDP depuis ces mêmes IPs chinoises. A suivre, mais je suis intéressé également par tout partage d'information. Bon courage pour le rétablissement. *Fabien VINCENT* --- Twitter : @beufanet Mail : fab...@beufa.net Mail : fabvinc...@gmail.com --- 2011/12/26 Charles Delorme fr...@suricat.net Bonjour, Le père Noël nous a gâté et nous subissons au Sénat une attaque par déni de service depuis dimanche matin 7h heure locale. La très grosse majorité des paquets est en udp/80 à destination de nos deux liens, completel ( 213.30.147.224/27) et global crossing (217.156.140.224/27) et aussi un peu en udp/53. Nous tentons d'établir une liste d'adresses sources mais vous vous doutez qu'elle varie beaucoup. Les supports des deux opérateurs sont bien sûr prévenus. Si en plus certains d'entre vous ont la possibilité de bloquer au moins le traffic en udp/80 qui passerait par vos réseaux vers chez nous, ceci nous pemettrait de respirer un peu. Tout avis en la matière sera le bienvenu. Je passe par cette adresse mail perso car pour l'instant nos accès sont saturés. Merci beaucoup et joyeux Noël à tous :-) Charles Delorme --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
On 12/26/11 12:04 PM, Charles Delorme wrote: Bonjour, Le père Noël nous a gâté et nous subissons au Sénat une attaque par déni de service depuis dimanche matin 7h heure locale. La très grosse majorité des paquets est en udp/80 à destination de nos deux liens, completel (213.30.147.224/27) et global crossing (217.156.140.224/27) et aussi un peu en udp/53. Nous tentons d'établir une liste d'adresses sources mais vous vous doutez qu'elle varie beaucoup. S'agissant d'UDP les IPs source sont très probablement spoofées. Je ne vois aucun intérêt à de l'UDP port 80 alors déjà tout ça vous pouvez dropper direct. Ensuite, pour du TCP vous pouvez activer sur vos firewalls du SYN Proxy, ça évitera à vos serveurs de backend d'essayer d'établir des sessions TCP avec des IPs spoofées qui ne répondront jamais à SYN_ACK. Les supports des deux opérateurs sont bien sûr prévenus. Si en plus certains d'entre vous ont la possibilité de bloquer au moins le traffic en udp/80 qui passerait par vos réseaux vers chez nous, ceci nous pemettrait de respirer un peu. Tout avis en la matière sera le bienvenu. Je passe par cette adresse mail perso car pour l'instant nos accès sont saturés. Merci beaucoup et joyeux Noël à tous :-) Charles Delorme --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
Bonjour, Un grand classique, surement déjà vécu par beaucoup ici. Et malheureusement peu d'options efficaces. Quelques techniques sont pourtant intéressantes à étudier, la plus intéressante étant celle du remote triggered black-hole pour peu que l'opérateur le supporte (http://tools.ietf.org/html/rfc5635). Cela peut permettre de désengorger ses liens et de ne pas impacter toute une plateforme. Bon courage. 2011/12/26 Charles Delorme fr...@suricat.net Bonjour, Le père Noël nous a gâté et nous subissons au Sénat une attaque par déni de service depuis dimanche matin 7h heure locale. La très grosse majorité des paquets est en udp/80 à destination de nos deux liens, completel ( 213.30.147.224/27) et global crossing (217.156.140.224/27) et aussi un peu en udp/53. Nous tentons d'établir une liste d'adresses sources mais vous vous doutez qu'elle varie beaucoup. Les supports des deux opérateurs sont bien sûr prévenus. Si en plus certains d'entre vous ont la possibilité de bloquer au moins le traffic en udp/80 qui passerait par vos réseaux vers chez nous, ceci nous pemettrait de respirer un peu. Tout avis en la matière sera le bienvenu. Je passe par cette adresse mail perso car pour l'instant nos accès sont saturés. Merci beaucoup et joyeux Noël à tous :-) Charles Delorme --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
S'agissant très probablement d'IPs spoofées, je le vois mal blackholer 200k /32 générées aléatoirement ? Nan parce qu'au bout d'un moment le routeur upstream va en avoir marre, déjà, et ensuite au bout d'un moment ça va bloquer des vrais clients légitimes qui auront eu la malchance que leur IP soit générée :o On 12/26/11 12:27 PM, Alexis Savin wrote: Bonjour, Un grand classique, surement déjà vécu par beaucoup ici. Et malheureusement peu d'options efficaces. Quelques techniques sont pourtant intéressantes à étudier, la plus intéressante étant celle du remote triggered black-hole pour peu que l'opérateur le supporte (http://tools.ietf.org/html/rfc5635). Cela peut permettre de désengorger ses liens et de ne pas impacter toute une plateforme. Bon courage. 2011/12/26 Charles Delorme fr...@suricat.net Bonjour, Le père Noël nous a gâté et nous subissons au Sénat une attaque par déni de service depuis dimanche matin 7h heure locale. La très grosse majorité des paquets est en udp/80 à destination de nos deux liens, completel ( 213.30.147.224/27) et global crossing (217.156.140.224/27) et aussi un peu en udp/53. Nous tentons d'établir une liste d'adresses sources mais vous vous doutez qu'elle varie beaucoup. Les supports des deux opérateurs sont bien sûr prévenus. Si en plus certains d'entre vous ont la possibilité de bloquer au moins le traffic en udp/80 qui passerait par vos réseaux vers chez nous, ceci nous pemettrait de respirer un peu. Tout avis en la matière sera le bienvenu. Je passe par cette adresse mail perso car pour l'instant nos accès sont saturés. Merci beaucoup et joyeux Noël à tous :-) Charles Delorme --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
Merci pour vos suggestions. Ma priorité est effectivement de bloquer le traffic udp/80 en amont de mes liens. Les équipements en tête de réseau supportent bien la charge mais ce sont les liens qui saturent. Damien Fleuriot m...@my.gd a écrit : Bah oui mais du coup il va se couper le service tout seul, certes seulement vers l'IP cible mais l'attaque aura réussi. Vu que la plupart du trafic semble être de l'UDP 80, est-ce qu'il aurait pas plus rapide de dropper ça par ses upstreams ? On 12/26/11 12:33 PM, Alexis Savin wrote: Il ne s'agit pas de bloquer les sources, mais le trafic à destination de l'ip attaquée, le temps que l'attaque cesse. La priorité lors d'une attaque comme celle-ci est de désengorger ses tuyaux pour rétablir le plus de services possible. 2011/12/26 Damien Fleuriot m...@my.gd mailto:m...@my.gd S'agissant très probablement d'IPs spoofées, je le vois mal blackholer 200k /32 générées aléatoirement ? Nan parce qu'au bout d'un moment le routeur upstream va en avoir marre, déjà, et ensuite au bout d'un moment ça va bloquer des vrais clients légitimes qui auront eu la malchance que leur IP soit générée :o On 12/26/11 12:27 PM, Alexis Savin wrote: Bonjour, Un grand classique, surement déjà vécu par beaucoup ici. Et malheureusement peu d'options efficaces. Quelques techniques sont pourtant intéressantes à étudier, la plus intéressante étant celle du remote triggered black-hole pour peu que l'opérateur le supporte (http://tools.ietf.org/html/rfc5635). Cela peut permettre de désengorger ses liens et de ne pas impacter toute une plateforme. Bon courage. 2011/12/26 Charles Delorme fr...@suricat.net mailto:fr...@suricat.net Bonjour, Le père Noël nous a gâté et nous subissons au Sénat une attaque par déni de service depuis dimanche matin 7h heure locale. La très grosse majorité des paquets est en udp/80 à destination de nos deux liens, completel ( 213.30.147.224/27 http://213.30.147.224/27;) et global crossing (217.156.140.224/27 http://217.156.140.224/27;) et aussi un peu en udp/53. Nous tentons d'établir une liste d'adresses sources mais vous vous doutez qu'elle varie beaucoup. Les supports des deux opérateurs sont bien sûr prévenus. Si en plus certains d'entre vous ont la possibilité de bloquer au moins le traffic en udp/80 qui passerait par vos réseaux vers chez nous, ceci nous pemettrait de respirer un peu. Tout avis en la matière sera le bienvenu. Je passe par cette adresse mail perso car pour l'instant nos accès sont saturés. Merci beaucoup et joyeux Noël à tous :-) Charles Delorme --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ -- -=HADESIS=- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité EPITA 2010 / Integra --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
Oui, il faut bien comprendre que de toute façon, le service est down mais que l'attaque impacte toute une plateforme, down elle aussi du coup. Ce qui inclus dans l'exemple, les services mail notamment qui pourtant ne sont pas visés initialement. Comme dit précédemment, la priorité est de désengorger les tuyaux, restaurer le maximum de service, puis enfin, voir comment stopper l'attaque, ou attendre la fin. 2011/12/26 Damien Fleuriot m...@my.gd Bah oui mais du coup il va se couper le service tout seul, certes seulement vers l'IP cible mais l'attaque aura réussi. Vu que la plupart du trafic semble être de l'UDP 80, est-ce qu'il aurait pas plus rapide de dropper ça par ses upstreams ? On 12/26/11 12:33 PM, Alexis Savin wrote: Il ne s'agit pas de bloquer les sources, mais le trafic à destination de l'ip attaquée, le temps que l'attaque cesse. La priorité lors d'une attaque comme celle-ci est de désengorger ses tuyaux pour rétablir le plus de services possible. 2011/12/26 Damien Fleuriot m...@my.gd mailto:m...@my.gd S'agissant très probablement d'IPs spoofées, je le vois mal blackholer 200k /32 générées aléatoirement ? Nan parce qu'au bout d'un moment le routeur upstream va en avoir marre, déjà, et ensuite au bout d'un moment ça va bloquer des vrais clients légitimes qui auront eu la malchance que leur IP soit générée :o On 12/26/11 12:27 PM, Alexis Savin wrote: Bonjour, Un grand classique, surement déjà vécu par beaucoup ici. Et malheureusement peu d'options efficaces. Quelques techniques sont pourtant intéressantes à étudier, la plus intéressante étant celle du remote triggered black-hole pour peu que l'opérateur le supporte (http://tools.ietf.org/html/rfc5635). Cela peut permettre de désengorger ses liens et de ne pas impacter toute une plateforme. Bon courage. 2011/12/26 Charles Delorme fr...@suricat.net mailto:fr...@suricat.net Bonjour, Le père Noël nous a gâté et nous subissons au Sénat une attaque par déni de service depuis dimanche matin 7h heure locale. La très grosse majorité des paquets est en udp/80 à destination de nos deux liens, completel ( 213.30.147.224/27 http://213.30.147.224/27) et global crossing (217.156.140.224/27 http://217.156.140.224/27) et aussi un peu en udp/53. Nous tentons d'établir une liste d'adresses sources mais vous vous doutez qu'elle varie beaucoup. Les supports des deux opérateurs sont bien sûr prévenus. Si en plus certains d'entre vous ont la possibilité de bloquer au moins le traffic en udp/80 qui passerait par vos réseaux vers chez nous, ceci nous pemettrait de respirer un peu. Tout avis en la matière sera le bienvenu. Je passe par cette adresse mail perso car pour l'instant nos accès sont saturés. Merci beaucoup et joyeux Noël à tous :-) Charles Delorme --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ -- -=HADESIS=- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité EPITA 2010 / Integra -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
IMHO, pour dropper 80/udp, le mieux que tu puisses faire c'est te rapprocher des NOCs de tes upstreams (completel / GBLX) et leur demander de le dropper à destination de tes supernets/subnets. On 12/26/11 12:47 PM, Charles Delorme wrote: Merci pour vos suggestions. Ma priorité est effectivement de bloquer le traffic udp/80 en amont de mes liens. Les équipements en tête de réseau supportent bien la charge mais ce sont les liens qui saturent. Damien Fleuriot m...@my.gd a écrit : Bah oui mais du coup il va se couper le service tout seul, certes seulement vers l'IP cible mais l'attaque aura réussi. Vu que la plupart du trafic semble être de l'UDP 80, est-ce qu'il aurait pas plus rapide de dropper ça par ses upstreams ? On 12/26/11 12:33 PM, Alexis Savin wrote: Il ne s'agit pas de bloquer les sources, mais le trafic à destination de l'ip attaquée, le temps que l'attaque cesse. La priorité lors d'une attaque comme celle-ci est de désengorger ses tuyaux pour rétablir le plus de services possible. 2011/12/26 Damien Fleuriot m...@my.gd mailto:m...@my.gd S'agissant très probablement d'IPs spoofées, je le vois mal blackholer 200k /32 générées aléatoirement ? Nan parce qu'au bout d'un moment le routeur upstream va en avoir marre, déjà, et ensuite au bout d'un moment ça va bloquer des vrais clients légitimes qui auront eu la malchance que leur IP soit générée :o On 12/26/11 12:27 PM, Alexis Savin wrote: Bonjour, Un grand classique, surement déjà vécu par beaucoup ici. Et malheureusement peu d'options efficaces. Quelques techniques sont pourtant intéressantes à étudier, la plus intéressante étant celle du remote triggered black-hole pour peu que l'opérateur le supporte (http://tools.ietf.org/html/rfc5635). Cela peut permettre de désengorger ses liens et de ne pas impacter toute une plateforme. Bon courage. 2011/12/26 Charles Delorme fr...@suricat.net mailto:fr...@suricat.net Bonjour, Le père Noël nous a gâté et nous subissons au Sénat une attaque par déni de service depuis dimanche matin 7h heure locale. La très grosse majorité des paquets est en udp/80 à destination de nos deux liens, completel ( 213.30.147.224/27 http://213.30.147.224/27;) et global crossing (217.156.140.224/27 http://217.156.140.224/27;) et aussi un peu en udp/53. Nous tentons d'établir une liste d'adresses sources mais vous vous doutez qu'elle varie beaucoup. Les supports des deux opérateurs sont bien sûr prévenus. Si en plus certains d'entre vous ont la possibilité de bloquer au moins le traffic en udp/80 qui passerait par vos réseaux vers chez nous, ceci nous pemettrait de respirer un peu. Tout avis en la matière sera le bienvenu. Je passe par cette adresse mail perso car pour l'instant nos accès sont saturés. Merci beaucoup et joyeux Noël à tous :-) Charles Delorme --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ -- -=HADESIS=- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité EPITA 2010 / Integra --- 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] [ALERT] Attaque en déni de service en cours
L'ideal de ce genre de situation serait d'avoir souscrit à un service de détection et de mitigation d'attaque auprès de ses fournisseurs d'accès Internet. Le blackhole BGP étant techniquement une approche valide mais donnant raison aux attaquants. BGP flow spec n'est applicable que rarement sur les attaques distribuées ou à base d'IP spoofées. Je n'ai bien peur que seul un boitier de mitigation placé dans l'infrastructure du carrier ne puisse vous sortir de cette situation sans casse. Cordialement, Matthieu. On Dec 26, 2011, at 1:29 PM, Thomas Mangin wrote: On 26 Dec 2011, at 11:27, Alexis Savin wrote: Quelques techniques sont pourtant intéressantes à étudier, la plus intéressante étant celle du remote triggered black-hole pour peu que l'opérateur le supporte (http://tools.ietf.org/html/rfc5635). Au cas ou vous auriez rate la présentation - puisque c'est d'actualité. http://perso.nautile.fr/prez/fgabut-flowspec-frnog-final.pdf Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/ Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
Le 26 décembre 2011 14:08, Texier, Matthieu mtex...@arbor.net a écrit :
BGP flow spec n'est applicable que rarement sur les attaques distribuées ou à
base d'IP spoofées. Je n'ai bien peur que seul un boitier de mitigation placé
dans l'infrastructure du carrier ne puisse vous sortir de cette situation
sans casse.
flow {
route optional-name-of-the-route {
match {
destination 192.168.0.1/27;
port =80;
destination-port =80;
protocol [ udp ];
}
then {
discard;
}
Ca marcherait très bien, ça...
--
Jérôme Nicolle
06 19 31 27 14
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
Oui c'est très bien. On Dec 26, 2011, at 2:08 PM, Texier, Matthieu wrote: L'ideal de ce genre de situation serait d'avoir souscrit à un service de détection et de mitigation d'attaque auprès de ses fournisseurs d'accès Internet. Le blackhole BGP étant techniquement une approche valide mais donnant raison aux attaquants. BGP flow spec n'est applicable que rarement sur les attaques distribuées ou à base d'IP spoofées. Je n'ai bien peur que seul un boitier de mitigation placé dans l'infrastructure du carrier ne puisse vous sortir de cette situation sans casse. Cordialement, Matthieu. On Dec 26, 2011, at 1:29 PM, Thomas Mangin wrote: On 26 Dec 2011, at 11:27, Alexis Savin wrote: Quelques techniques sont pourtant intéressantes à étudier, la plus intéressante étant celle du remote triggered black-hole pour peu que l'opérateur le supporte (http://tools.ietf.org/html/rfc5635). Au cas ou vous auriez rate la présentation - puisque c'est d'actualité. http://perso.nautile.fr/prez/fgabut-flowspec-frnog-final.pdf Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/ Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 --- Liste de diffusion du FRnOG http://www.frnog.org/ Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
Je rajoute ma pierre à l'édifice au lieu d'ouvrir un autre topic. Depuis le 23/12, c'est la déferlante, on a rarement vu ça depuis 5 ans qu'on existe. DDOS UDP hier sur port aléatoire, non saturé mais qui a bien pourrit les graph et les soirées de nos clients. Et aujourd'hui, du scan sévère à plus de 30 requêtes par secondes sur quasi tout notre parc : 217.115.199.40 www.mac0andgel.fr GET /index.php?option=com_propertiescontroller= ../../../../.. 217.115.199.40 ns11.freeheberg.com GET /index.php?option=com_jequoteformview= ../../../../../../. 217.115.199.40 www.ho0rse-brasses.com GET /index.php?option=com_realtynacontroller= ../../../../../. 217.115.199.40 www.gcf0is.fr GET /index.php?option=com_sectionexcontroller= ../../../../../ 217.115.199.40 www.hor0izon-vertical50.com GET /classes/adodbt/sql.php?classes_dir=../../../../../../../pr 217.115.199.40 www.glam-an0d-brown.com GET /index.php?option=com_sbsfilecontroller= ../../../../../.. 217.115.199.40 www.glam-and-bro0wn.com GET /calendar/setup/setupSQL.php?serverPath=../../../../../../. 217.115.199.40 www.dieti0miam.com GET /poll/admin/common.inc.php?base_path=../../../../../../../p 217.115.199.40 www.maca0ndgel.fr GET /calendar/functions/popup.php?serverPath=../../../../../../ 217.115.199.40 www.step0hanehome.com GET /index.php?option=com_s5clanrostercontroller= ../../../../ 217.115.199.40 www.coach-cend0rillon.fr GET /modules/public/date_format.php?baseDir=../../../../../../. 217.115.199.40 www.teleca0mpus.fr GET /default.php?page=../../../../../../../proc/self/environ%00 217.115.199.40 www.yak0ha.com GET /modules/admin/vw_usr_roles.php?baseDir=../../../../../../. 217.115.199.40 www.corpe0dia.fr GET /index.php?option=com_awdwallcontroller= ../../../../../.. 217.115.199.40 www.kli0cia.com GET /becommunity/community/index.php?pageurl=../../../../../../ Bref, surveillez bien vos infra, on a fait blacklister 25 serveurs chez OVH hier, et on vient de se faire blacklister un serveur à cause d'un open_socket qu'on a oublié de fermer sur un mutualisé et qui a floodé un bind en face. 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 26/12/2011 12:04, Charles Delorme a écrit : Bonjour, Le père Noël nous a gâté et nous subissons au Sénat une attaque par déni de service depuis dimanche matin 7h heure locale. La très grosse majorité des paquets est en udp/80 à destination de nos deux liens, completel (213.30.147.224/27) et global crossing (217.156.140.224/27) et aussi un peu en udp/53. Nous tentons d'établir une liste d'adresses sources mais vous vous doutez qu'elle varie beaucoup. Les supports des deux opérateurs sont bien sûr prévenus. Si en plus certains d'entre vous ont la possibilité de bloquer au moins le traffic en udp/80 qui passerait par vos réseaux vers chez nous, ceci nous pemettrait de respirer un peu. Tout avis en la matière sera le bienvenu. Je passe par cette adresse mail perso car pour l'instant nos accès sont saturés. Merci beaucoup et joyeux Noël à tous :-) Charles Delorme --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
Cela dépend surtout du profil de l'attaque. Pour un UDP flood sur un serveur web, un fournisseur qui peux ajouter un filtre flowspec sur ses connections EBGP ça aide surement beaucoup. Face a une attaque sur le L7 - la vie devient très dure ... Thomas On 26 Dec 2011, at 13:08, Texier, Matthieu wrote: L'ideal de ce genre de situation serait d'avoir souscrit à un service de détection et de mitigation d'attaque auprès de ses fournisseurs d'accès Internet. Le blackhole BGP étant techniquement une approche valide mais donnant raison aux attaquants. BGP flow spec n'est applicable que rarement sur les attaques distribuées ou à base d'IP spoofées. Je n'ai bien peur que seul un boitier de mitigation placé dans l'infrastructure du carrier ne puisse vous sortir de cette situation sans casse. Cordialement, Matthieu. On Dec 26, 2011, at 1:29 PM, Thomas Mangin wrote: On 26 Dec 2011, at 11:27, Alexis Savin wrote: Quelques techniques sont pourtant intéressantes à étudier, la plus intéressante étant celle du remote triggered black-hole pour peu que l'opérateur le supporte (http://tools.ietf.org/html/rfc5635). Au cas ou vous auriez rate la présentation - puisque c'est d'actualité. http://perso.nautile.fr/prez/fgabut-flowspec-frnog-final.pdf Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/ Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
Voila un réponse qui me semble faire preuve d'expérience :-) ! Sans compter que nos amis attaquants font souvent preuve d'une malice certaine et emmenant les administrateurs réseaux dans une direction afin de masquer une autre action mené en parallèle au niveau L7. Les attaques sont de plus en plus polymorphe. A bon entendeur ... Enfin, moi ce que je dis … je suis un peu vieux pour toutes ces choses la ! Du reste ma mémoire flanche un peu, je ne me rappelle plus bien comment activer flow spec sur tous les routeurs de nos chers industriels ? On Dec 26, 2011, at 2:35 PM, Thomas Mangin wrote: Cela dépend surtout du profil de l'attaque. Pour un UDP flood sur un serveur web, un fournisseur qui peux ajouter un filtre flowspec sur ses connections EBGP ça aide surement beaucoup. Face a une attaque sur le L7 - la vie devient très dure ... Thomas On 26 Dec 2011, at 13:08, Texier, Matthieu wrote: L'ideal de ce genre de situation serait d'avoir souscrit à un service de détection et de mitigation d'attaque auprès de ses fournisseurs d'accès Internet. Le blackhole BGP étant techniquement une approche valide mais donnant raison aux attaquants. BGP flow spec n'est applicable que rarement sur les attaques distribuées ou à base d'IP spoofées. Je n'ai bien peur que seul un boitier de mitigation placé dans l'infrastructure du carrier ne puisse vous sortir de cette situation sans casse. Cordialement, Matthieu. On Dec 26, 2011, at 1:29 PM, Thomas Mangin wrote: On 26 Dec 2011, at 11:27, Alexis Savin wrote: Quelques techniques sont pourtant intéressantes à étudier, la plus intéressante étant celle du remote triggered black-hole pour peu que l'opérateur le supporte (http://tools.ietf.org/html/rfc5635). Au cas ou vous auriez rate la présentation - puisque c'est d'actualité. http://perso.nautile.fr/prez/fgabut-flowspec-frnog-final.pdf Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/ Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
Flow spec, c'est bien beau, mais tant que le client ne peut pas activer seul le filtrage il est difficile de l'exploiter de façon efficace, les attaquant étant généralement très réactifs et les services opérateurs lents à la détente... Enfin, quels sont les opérateurs à l'exploiter réellement ? Et à le proposer à leurs clients ? 2011/12/26 Texier, Matthieu mtex...@arbor.net Voila un réponse qui me semble faire preuve d'expérience :-) ! Sans compter que nos amis attaquants font souvent preuve d'une malice certaine et emmenant les administrateurs réseaux dans une direction afin de masquer une autre action mené en parallèle au niveau L7. Les attaques sont de plus en plus polymorphe. A bon entendeur ... Enfin, moi ce que je dis … je suis un peu vieux pour toutes ces choses la ! Du reste ma mémoire flanche un peu, je ne me rappelle plus bien comment activer flow spec sur tous les routeurs de nos chers industriels ? On Dec 26, 2011, at 2:35 PM, Thomas Mangin wrote: Cela dépend surtout du profil de l'attaque. Pour un UDP flood sur un serveur web, un fournisseur qui peux ajouter un filtre flowspec sur ses connections EBGP ça aide surement beaucoup. Face a une attaque sur le L7 - la vie devient très dure ... Thomas On 26 Dec 2011, at 13:08, Texier, Matthieu wrote: L'ideal de ce genre de situation serait d'avoir souscrit à un service de détection et de mitigation d'attaque auprès de ses fournisseurs d'accès Internet. Le blackhole BGP étant techniquement une approche valide mais donnant raison aux attaquants. BGP flow spec n'est applicable que rarement sur les attaques distribuées ou à base d'IP spoofées. Je n'ai bien peur que seul un boitier de mitigation placé dans l'infrastructure du carrier ne puisse vous sortir de cette situation sans casse. Cordialement, Matthieu. On Dec 26, 2011, at 1:29 PM, Thomas Mangin wrote: On 26 Dec 2011, at 11:27, Alexis Savin wrote: Quelques techniques sont pourtant intéressantes à étudier, la plus intéressante étant celle du remote triggered black-hole pour peu que l'opérateur le supporte (http://tools.ietf.org/html/rfc5635). Au cas ou vous auriez rate la présentation - puisque c'est d'actualité. http://perso.nautile.fr/prez/fgabut-flowspec-frnog-final.pdf Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/ Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
C'est pour cela qu'il me semble sain de s'appuyer sur une offre de service opérateur spécialisé qui donne un engament de SLA associé. Des opérateurs proposent ce type de service et s'appuient pour cela sur une structure type SoC mettant à disposition des outils et des experts dans le domaine. Les outils sont toujours intéressants pour nourrir le débat technique … mais ils ne font pas tout … fort heureusement ! On Dec 26, 2011, at 2:58 PM, Alexis Savin wrote: Flow spec, c'est bien beau, mais tant que le client ne peut pas activer seul le filtrage il est difficile de l'exploiter de façon efficace, les attaquant étant généralement très réactifs et les services opérateurs lents à la détente... Enfin, quels sont les opérateurs à l'exploiter réellement ? Et à le proposer à leurs clients ? 2011/12/26 Texier, Matthieu mtex...@arbor.netmailto:mtex...@arbor.net Voila un réponse qui me semble faire preuve d'expérience :-) ! Sans compter que nos amis attaquants font souvent preuve d'une malice certaine et emmenant les administrateurs réseaux dans une direction afin de masquer une autre action mené en parallèle au niveau L7. Les attaques sont de plus en plus polymorphe. A bon entendeur ... Enfin, moi ce que je dis … je suis un peu vieux pour toutes ces choses la ! Du reste ma mémoire flanche un peu, je ne me rappelle plus bien comment activer flow spec sur tous les routeurs de nos chers industriels ? On Dec 26, 2011, at 2:35 PM, Thomas Mangin wrote: Cela dépend surtout du profil de l'attaque. Pour un UDP flood sur un serveur web, un fournisseur qui peux ajouter un filtre flowspec sur ses connections EBGP ça aide surement beaucoup. Face a une attaque sur le L7 - la vie devient très dure ... Thomas On 26 Dec 2011, at 13:08, Texier, Matthieu wrote: L'ideal de ce genre de situation serait d'avoir souscrit à un service de détection et de mitigation d'attaque auprès de ses fournisseurs d'accès Internet. Le blackhole BGP étant techniquement une approche valide mais donnant raison aux attaquants. BGP flow spec n'est applicable que rarement sur les attaques distribuées ou à base d'IP spoofées. Je n'ai bien peur que seul un boitier de mitigation placé dans l'infrastructure du carrier ne puisse vous sortir de cette situation sans casse. Cordialement, Matthieu. On Dec 26, 2011, at 1:29 PM, Thomas Mangin wrote: On 26 Dec 2011, at 11:27, Alexis Savin wrote: Quelques techniques sont pourtant intéressantes à étudier, la plus intéressante étant celle du remote triggered black-hole pour peu que l'opérateur le supporte (http://tools.ietf.org/html/rfc5635). Au cas ou vous auriez rate la présentation - puisque c'est d'actualité. http://perso.nautile.fr/prez/fgabut-flowspec-frnog-final.pdf Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/ Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.netmailto:mtex...@arbor.net +33 6 85 83 66 89tel:%2B33%206%2085%2083%2066%2089 Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.netmailto:mtex...@arbor.net +33 6 85 83 66 89tel:%2B33%206%2085%2083%2066%2089 -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.netmailto:mtex...@arbor.net +33 6 85 83 66 89 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
Si tu as des exemples à citer, je pense que nombre d'entre nous sera preneur, ne serait-ce qu'à titre informatif. 2011/12/26 Texier, Matthieu mtex...@arbor.net C'est pour cela qu'il me semble sain de s'appuyer sur une offre de service opérateur spécialisé qui donne un engament de SLA associé. Des opérateurs proposent ce type de service et s'appuient pour cela sur une structure type SoC mettant à disposition des outils et des experts dans le domaine. Les outils sont toujours intéressants pour nourrir le débat technique … mais ils ne font pas tout … fort heureusement ! On Dec 26, 2011, at 2:58 PM, Alexis Savin wrote: Flow spec, c'est bien beau, mais tant que le client ne peut pas activer seul le filtrage il est difficile de l'exploiter de façon efficace, les attaquant étant généralement très réactifs et les services opérateurs lents à la détente... Enfin, quels sont les opérateurs à l'exploiter réellement ? Et à le proposer à leurs clients ? 2011/12/26 Texier, Matthieu mtex...@arbor.net Voila un réponse qui me semble faire preuve d'expérience :-) ! Sans compter que nos amis attaquants font souvent preuve d'une malice certaine et emmenant les administrateurs réseaux dans une direction afin de masquer une autre action mené en parallèle au niveau L7. Les attaques sont de plus en plus polymorphe. A bon entendeur ... Enfin, moi ce que je dis … je suis un peu vieux pour toutes ces choses la ! Du reste ma mémoire flanche un peu, je ne me rappelle plus bien comment activer flow spec sur tous les routeurs de nos chers industriels ? On Dec 26, 2011, at 2:35 PM, Thomas Mangin wrote: Cela dépend surtout du profil de l'attaque. Pour un UDP flood sur un serveur web, un fournisseur qui peux ajouter un filtre flowspec sur ses connections EBGP ça aide surement beaucoup. Face a une attaque sur le L7 - la vie devient très dure ... Thomas On 26 Dec 2011, at 13:08, Texier, Matthieu wrote: L'ideal de ce genre de situation serait d'avoir souscrit à un service de détection et de mitigation d'attaque auprès de ses fournisseurs d'accès Internet. Le blackhole BGP étant techniquement une approche valide mais donnant raison aux attaquants. BGP flow spec n'est applicable que rarement sur les attaques distribuées ou à base d'IP spoofées. Je n'ai bien peur que seul un boitier de mitigation placé dans l'infrastructure du carrier ne puisse vous sortir de cette situation sans casse. Cordialement, Matthieu. On Dec 26, 2011, at 1:29 PM, Thomas Mangin wrote: On 26 Dec 2011, at 11:27, Alexis Savin wrote: Quelques techniques sont pourtant intéressantes à étudier, la plus intéressante étant celle du remote triggered black-hole pour peu que l'opérateur le supporte (http://tools.ietf.org/html/rfc5635). Au cas ou vous auriez rate la présentation - puisque c'est d'actualité. http://perso.nautile.fr/prez/fgabut-flowspec-frnog-final.pdf Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/ Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
Alexis, Une des societe specialise est Prolexic, Jay Coley parle souvent de ce qu'il voit comme attaques a LINX, EFP, GPF, ... Les informations présentées ne sont normalement pas publiques (Prolexic ne voit pas de raison de former l'industrie qu'ils combattent). Un peu d'info dans https://www.linx.net/files/hotlinx/hotlinx-25.pdf mais le seul moyen de voir la partie intéressante est d'être la pour la presentation :( Une idee pour un prochain FRnOG ? Il y a des FAI traditionnels offrent des service de protection en France, mais je ne vais pas faire de pub sur la liste. Thomas On 26 Dec 2011, at 14:21, Alexis Savin wrote: Si tu as des exemples à citer, je pense que nombre d'entre nous sera preneur, ne serait-ce qu'à titre informatif. 2011/12/26 Texier, Matthieu mtex...@arbor.net C'est pour cela qu'il me semble sain de s'appuyer sur une offre de service opérateur spécialisé qui donne un engament de SLA associé. Des opérateurs proposent ce type de service et s'appuient pour cela sur une structure type SoC mettant à disposition des outils et des experts dans le domaine. Les outils sont toujours intéressants pour nourrir le débat technique … mais ils ne font pas tout … fort heureusement ! On Dec 26, 2011, at 2:58 PM, Alexis Savin wrote: Flow spec, c'est bien beau, mais tant que le client ne peut pas activer seul le filtrage il est difficile de l'exploiter de façon efficace, les attaquant étant généralement très réactifs et les services opérateurs lents à la détente... Enfin, quels sont les opérateurs à l'exploiter réellement ? Et à le proposer à leurs clients ? 2011/12/26 Texier, Matthieu mtex...@arbor.net Voila un réponse qui me semble faire preuve d'expérience :-) ! Sans compter que nos amis attaquants font souvent preuve d'une malice certaine et emmenant les administrateurs réseaux dans une direction afin de masquer une autre action mené en parallèle au niveau L7. Les attaques sont de plus en plus polymorphe. A bon entendeur ... Enfin, moi ce que je dis … je suis un peu vieux pour toutes ces choses la ! Du reste ma mémoire flanche un peu, je ne me rappelle plus bien comment activer flow spec sur tous les routeurs de nos chers industriels ? On Dec 26, 2011, at 2:35 PM, Thomas Mangin wrote: Cela dépend surtout du profil de l'attaque. Pour un UDP flood sur un serveur web, un fournisseur qui peux ajouter un filtre flowspec sur ses connections EBGP ça aide surement beaucoup. Face a une attaque sur le L7 - la vie devient très dure ... Thomas On 26 Dec 2011, at 13:08, Texier, Matthieu wrote: L'ideal de ce genre de situation serait d'avoir souscrit à un service de détection et de mitigation d'attaque auprès de ses fournisseurs d'accès Internet. Le blackhole BGP étant techniquement une approche valide mais donnant raison aux attaquants. BGP flow spec n'est applicable que rarement sur les attaques distribuées ou à base d'IP spoofées. Je n'ai bien peur que seul un boitier de mitigation placé dans l'infrastructure du carrier ne puisse vous sortir de cette situation sans casse. Cordialement, Matthieu. On Dec 26, 2011, at 1:29 PM, Thomas Mangin wrote: On 26 Dec 2011, at 11:27, Alexis Savin wrote: Quelques techniques sont pourtant intéressantes à étudier, la plus intéressante étant celle du remote triggered black-hole pour peu que l'opérateur le supporte (http://tools.ietf.org/html/rfc5635). Au cas ou vous auriez rate la présentation - puisque c'est d'actualité. http://perso.nautile.fr/prez/fgabut-flowspec-frnog-final.pdf Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/ Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [ALERT] Attaque en déni de service en cours
A supposer qu'il existe une offre de firewall virtuel par abonné avec self-provisioning. Quels seraient les services à offrir (à part bien sûr le minimum syndical façon blocage de port) - blocage d'URL à destination de hosts, URI, paramètres invalides? - blocage d'AS? Pays ? François-Frédéric -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de Texier, Matthieu Envoyé : lundi 26 décembre 2011 15:10 À : Alexis Savin Cc : Thomas Mangin; Charles Delorme; frnog-al...@frnog.org; sys...@senat.fr Objet : Re: [FRnOG] [ALERT] Attaque en déni de service en cours C'est pour cela qu'il me semble sain de s'appuyer sur une offre de service opérateur spécialisé qui donne un engament de SLA associé. Des opérateurs proposent ce type de service et s'appuient pour cela sur une structure type SoC mettant à disposition des outils et des experts dans le domaine. Les outils sont toujours intéressants pour nourrir le débat technique mais ils ne font pas tout fort heureusement ! On Dec 26, 2011, at 2:58 PM, Alexis Savin wrote: Flow spec, c'est bien beau, mais tant que le client ne peut pas activer seul le filtrage il est difficile de l'exploiter de façon efficace, les attaquant étant généralement très réactifs et les services opérateurs lents à la détente... Enfin, quels sont les opérateurs à l'exploiter réellement ? Et à le proposer à leurs clients ? 2011/12/26 Texier, Matthieu mtex...@arbor.netmailto:mtex...@arbor.net Voila un réponse qui me semble faire preuve d'expérience :-) ! Sans compter que nos amis attaquants font souvent preuve d'une malice certaine et emmenant les administrateurs réseaux dans une direction afin de masquer une autre action mené en parallèle au niveau L7. Les attaques sont de plus en plus polymorphe. A bon entendeur ... Enfin, moi ce que je dis je suis un peu vieux pour toutes ces choses la ! Du reste ma mémoire flanche un peu, je ne me rappelle plus bien comment activer flow spec sur tous les routeurs de nos chers industriels ? On Dec 26, 2011, at 2:35 PM, Thomas Mangin wrote: Cela dépend surtout du profil de l'attaque. Pour un UDP flood sur un serveur web, un fournisseur qui peux ajouter un filtre flowspec sur ses connections EBGP ça aide surement beaucoup. Face a une attaque sur le L7 - la vie devient très dure ... Thomas On 26 Dec 2011, at 13:08, Texier, Matthieu wrote: L'ideal de ce genre de situation serait d'avoir souscrit à un service de détection et de mitigation d'attaque auprès de ses fournisseurs d'accès Internet. Le blackhole BGP étant techniquement une approche valide mais donnant raison aux attaquants. BGP flow spec n'est applicable que rarement sur les attaques distribuées ou à base d'IP spoofées. Je n'ai bien peur que seul un boitier de mitigation placé dans l'infrastructure du carrier ne puisse vous sortir de cette situation sans casse. Cordialement, Matthieu. On Dec 26, 2011, at 1:29 PM, Thomas Mangin wrote: On 26 Dec 2011, at 11:27, Alexis Savin wrote: Quelques techniques sont pourtant intéressantes à étudier, la plus intéressante étant celle du remote triggered black-hole pour peu que l'opérateur le supporte (http://tools.ietf.org/html/rfc5635). Au cas ou vous auriez rate la présentation - puisque c'est d'actualité. http://perso.nautile.fr/prez/fgabut-flowspec-frnog-final.pdf Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/ Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.netmailto:mtex...@arbor.net +33 6 85 83 66 89tel:%2B33%206%2085%2083%2066%2089 Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.netmailto:mtex...@arbor.net +33 6 85 83 66 89tel:%2B33%206%2085%2083%2066%2089 -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.netmailto:mtex...@arbor.net +33 6 85 83 66 89 --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
J ai une question qui peut sembler idiote car je ne sais pas quels sont les services impactés et quelles en sont les utilisations mais rendre les services down (eteindre tout par exemple, blacklister les ip turcs) ne me semble pas etre une option ayatolesque. Ensuite ce n est pas forcement une solution... Bonne journee et courage. Sent from Samsung Mobile Charles Delorme fr...@suricat.net wrote: Merci pour vos suggestions. Ma priorité est effectivement de bloquer le traffic udp/80 en amont de mes liens. Les équipements en tête de réseau supportent bien la charge mais ce sont les liens qui saturent. Damien Fleuriot m...@my.gd a écrit : Bah oui mais du coup il va se couper le service tout seul, certes seulement vers l'IP cible mais l'attaque aura réussi. Vu que la plupart du trafic semble être de l'UDP 80, est-ce qu'il aurait pas plus rapide de dropper ça par ses upstreams ? On 12/26/11 12:33 PM, Alexis Savin wrote: Il ne s'agit pas de bloquer les sources, mais le trafic à destination de l'ip attaquée, le temps que l'attaque cesse. La priorité lors d'une attaque comme celle-ci est de désengorger ses tuyaux pour rétablir le plus de services possible. 2011/12/26 Damien Fleuriot m...@my.gd mailto:m...@my.gd S'agissant très probablement d'IPs spoofées, je le vois mal blackholer 200k /32 générées aléatoirement ? Nan parce qu'au bout d'un moment le routeur upstream va en avoir marre, déjà, et ensuite au bout d'un moment ça va bloquer des vrais clients légitimes qui auront eu la malchance que leur IP soit générée :o On 12/26/11 12:27 PM, Alexis Savin wrote: Bonjour, Un grand classique, surement déjà vécu par beaucoup ici. Et malheureusement peu d'options efficaces. Quelques techniques sont pourtant intéressantes à étudier, la plus intéressante étant celle du remote triggered black-hole pour peu que l'opérateur le supporte (http://tools.ietf.org/html/rfc5635). Cela peut permettre de désengorger ses liens et de ne pas impacter toute une plateforme. Bon courage. 2011/12/26 Charles Delorme fr...@suricat.net mailto:fr...@suricat.net Bonjour, Le père Noël nous a gâté et nous subissons au Sénat une attaque par déni de service depuis dimanche matin 7h heure locale. La très grosse majorité des paquets est en udp/80 à destination de nos deux liens, completel ( 213.30.147.224/27 http://213.30.147.224/27;) et global crossing (217.156.140.224/27 http://217.156.140.224/27;) et aussi un peu en udp/53. Nous tentons d'établir une liste d'adresses sources mais vous vous doutez qu'elle varie beaucoup. Les supports des deux opérateurs sont bien sûr prévenus. Si en plus certains d'entre vous ont la possibilité de bloquer au moins le traffic en udp/80 qui passerait par vos réseaux vers chez nous, ceci nous pemettrait de respirer un peu. Tout avis en la matière sera le bienvenu. Je passe par cette adresse mail perso car pour l'instant nos accès sont saturés. Merci beaucoup et joyeux Noël à tous :-) Charles Delorme --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ -- -=HADESIS=- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité EPITA 2010 / Integra --- 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] [ALERT] Attaque en déni de service en cours
J'avais vaguement entendu parler de ce genre d'offre, il me semble d'ailleurs qu'il existe d'autres acteurs que Prolexic. Cependant, je trouve dommage de devoir re-router son trafic vers un tiers (de confiance ?) jouant le rôle d'intermédiaire. Implémenter une solution plus ou moins automatisée à base de flow spec et de remote black-hole ne serait pas bien complexe. Malheureusement, les opérateurs n'offrent pas, ou trop peu, les interfaçages nécessaires (certes, bien plus complexes à implémenter de façon sécurisée de leur côté). Reste que cela est bien dommage, les ddos impactant toute la chaine, travailler de concert serait, me parait-il, plus opportun que de confier notre trafic à d'autres. 2011/12/26 Breton, Oliver olivier.bre...@level3.com Bonjour, Je publie très rarement sur la liste mais pour répondre à la question d'Alexis, sachez que Level 3 propose une solution de protection DDoS très efficace puisque c'est celle de notre partenaire Prolexic. Il y a deux types d'offres : reroutage DNS en urgence (lors d'une activation en cours d'attaque) ou une solution pérenne de mitigation des flux au travers des tunnels GRE des routeurs client. Ne souhaitant pas me faire taxer de pub commerciale sur la liste, je ne m'étendrais pas mais n'hésitez pas à me consulter hors liste pour toute info complémentaire ou présentation du service. Olivier BRETON Envoyé de mon iPad2 Le 26 déc. 2011 à 15:22, Alexis Savin alexis.sa...@gmail.com a écrit : Si tu as des exemples à citer, je pense que nombre d'entre nous sera preneur, ne serait-ce qu'à titre informatif. 2011/12/26 Texier, Matthieu mtex...@arbor.net C'est pour cela qu'il me semble sain de s'appuyer sur une offre de service opérateur spécialisé qui donne un engament de SLA associé. Des opérateurs proposent ce type de service et s'appuient pour cela sur une structure type SoC mettant à disposition des outils et des experts dans le domaine. Les outils sont toujours intéressants pour nourrir le débat technique … mais ils ne font pas tout … fort heureusement ! On Dec 26, 2011, at 2:58 PM, Alexis Savin wrote: Flow spec, c'est bien beau, mais tant que le client ne peut pas activer seul le filtrage il est difficile de l'exploiter de façon efficace, les attaquant étant généralement très réactifs et les services opérateurs lents à la détente... Enfin, quels sont les opérateurs à l'exploiter réellement ? Et à le proposer à leurs clients ? 2011/12/26 Texier, Matthieu mtex...@arbor.net Voila un réponse qui me semble faire preuve d'expérience :-) ! Sans compter que nos amis attaquants font souvent preuve d'une malice certaine et emmenant les administrateurs réseaux dans une direction afin de masquer une autre action mené en parallèle au niveau L7. Les attaques sont de plus en plus polymorphe. A bon entendeur ... Enfin, moi ce que je dis … je suis un peu vieux pour toutes ces choses la ! Du reste ma mémoire flanche un peu, je ne me rappelle plus bien comment activer flow spec sur tous les routeurs de nos chers industriels ? On Dec 26, 2011, at 2:35 PM, Thomas Mangin wrote: Cela dépend surtout du profil de l'attaque. Pour un UDP flood sur un serveur web, un fournisseur qui peux ajouter un filtre flowspec sur ses connections EBGP ça aide surement beaucoup. Face a une attaque sur le L7 - la vie devient très dure ... Thomas On 26 Dec 2011, at 13:08, Texier, Matthieu wrote: L'ideal de ce genre de situation serait d'avoir souscrit à un service de détection et de mitigation d'attaque auprès de ses fournisseurs d'accès Internet. Le blackhole BGP étant techniquement une approche valide mais donnant raison aux attaquants. BGP flow spec n'est applicable que rarement sur les attaques distribuées ou à base d'IP spoofées. Je n'ai bien peur que seul un boitier de mitigation placé dans l'infrastructure du carrier ne puisse vous sortir de cette situation sans casse. Cordialement, Matthieu. On Dec 26, 2011, at 1:29 PM, Thomas Mangin wrote: On 26 Dec 2011, at 11:27, Alexis Savin wrote: Quelques techniques sont pourtant intéressantes à étudier, la plus intéressante étant celle du remote triggered black-hole pour peu que l'opérateur le supporte (http://tools.ietf.org/html/rfc5635). Au cas ou vous auriez rate la présentation - puisque c'est d'actualité. http://perso.nautile.fr/prez/fgabut-flowspec-frnog-final.pdf Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/ Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 -- Alexis
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
Argument tout a fait recevable et même, pour ce qui est la législation Française, juridiquement recevable … sauf erreur de ma part, un trafic entré en France n'est pas sensé aller faire un petit tour aux US ou ailleurs et revenir… Si il y a des juristes dans cette liste de diffusion, ils pourront nous donner la loi/réglementation en vigueur, je doit avouer que je n'ai pas plus de détail sur ce point. On Dec 26, 2011, at 5:19 PM, Alexis Savin wrote: J'avais vaguement entendu parler de ce genre d'offre, il me semble d'ailleurs qu'il existe d'autres acteurs que Prolexic. Cependant, je trouve dommage de devoir re-router son trafic vers un tiers (de confiance ?) jouant le rôle d'intermédiaire. Implémenter une solution plus ou moins automatisée à base de flow spec et de remote black-hole ne serait pas bien complexe. Malheureusement, les opérateurs n'offrent pas, ou trop peu, les interfaçages nécessaires (certes, bien plus complexes à implémenter de façon sécurisée de leur côté). Reste que cela est bien dommage, les ddos impactant toute la chaine, travailler de concert serait, me parait-il, plus opportun que de confier notre trafic à d'autres. 2011/12/26 Breton, Oliver olivier.bre...@level3.commailto:olivier.bre...@level3.com Bonjour, Je publie très rarement sur la liste mais pour répondre à la question d'Alexis, sachez que Level 3 propose une solution de protection DDoS très efficace puisque c'est celle de notre partenaire Prolexic. Il y a deux types d'offres : reroutage DNS en urgence (lors d'une activation en cours d'attaque) ou une solution pérenne de mitigation des flux au travers des tunnels GRE des routeurs client. Ne souhaitant pas me faire taxer de pub commerciale sur la liste, je ne m'étendrais pas mais n'hésitez pas à me consulter hors liste pour toute info complémentaire ou présentation du service. Olivier BRETON Envoyé de mon iPad2 Le 26 déc. 2011 à 15:22, Alexis Savin alexis.sa...@gmail.commailto:alexis.sa...@gmail.com a écrit : Si tu as des exemples à citer, je pense que nombre d'entre nous sera preneur, ne serait-ce qu'à titre informatif. 2011/12/26 Texier, Matthieu mtex...@arbor.netmailto:mtex...@arbor.net C'est pour cela qu'il me semble sain de s'appuyer sur une offre de service opérateur spécialisé qui donne un engament de SLA associé. Des opérateurs proposent ce type de service et s'appuient pour cela sur une structure type SoC mettant à disposition des outils et des experts dans le domaine. Les outils sont toujours intéressants pour nourrir le débat technique … mais ils ne font pas tout … fort heureusement ! On Dec 26, 2011, at 2:58 PM, Alexis Savin wrote: Flow spec, c'est bien beau, mais tant que le client ne peut pas activer seul le filtrage il est difficile de l'exploiter de façon efficace, les attaquant étant généralement très réactifs et les services opérateurs lents à la détente... Enfin, quels sont les opérateurs à l'exploiter réellement ? Et à le proposer à leurs clients ? 2011/12/26 Texier, Matthieu mtex...@arbor.netmailto:mtex...@arbor.net Voila un réponse qui me semble faire preuve d'expérience :-) ! Sans compter que nos amis attaquants font souvent preuve d'une malice certaine et emmenant les administrateurs réseaux dans une direction afin de masquer une autre action mené en parallèle au niveau L7. Les attaques sont de plus en plus polymorphe. A bon entendeur ... Enfin, moi ce que je dis … je suis un peu vieux pour toutes ces choses la ! Du reste ma mémoire flanche un peu, je ne me rappelle plus bien comment activer flow spec sur tous les routeurs de nos chers industriels ? On Dec 26, 2011, at 2:35 PM, Thomas Mangin wrote: Cela dépend surtout du profil de l'attaque. Pour un UDP flood sur un serveur web, un fournisseur qui peux ajouter un filtre flowspec sur ses connections EBGP ça aide surement beaucoup. Face a une attaque sur le L7 - la vie devient très dure ... Thomas On 26 Dec 2011, at 13:08, Texier, Matthieu wrote: L'ideal de ce genre de situation serait d'avoir souscrit à un service de détection et de mitigation d'attaque auprès de ses fournisseurs d'accès Internet. Le blackhole BGP étant techniquement une approche valide mais donnant raison aux attaquants. BGP flow spec n'est applicable que rarement sur les attaques distribuées ou à base d'IP spoofées. Je n'ai bien peur que seul un boitier de mitigation placé dans l'infrastructure du carrier ne puisse vous sortir de cette situation sans casse. Cordialement, Matthieu. On Dec 26, 2011, at 1:29 PM, Thomas Mangin wrote: On 26 Dec 2011, at 11:27, Alexis Savin wrote: Quelques techniques sont pourtant intéressantes à étudier, la plus intéressante étant celle du remote triggered black-hole pour peu que l'opérateur le supporte (http://tools.ietf.org/html/rfc5635). Au cas ou vous auriez rate la présentation - puisque c'est d'actualité. http://perso.nautile.fr/prez/fgabut-flowspec-frnog-final.pdf Thomas
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
Hello, Le 26 décembre 2011 16:44, François-Frédéric Ozog f...@ozog.com a écrit : A supposer qu'il existe une offre de firewall virtuel par abonné avec self-provisioning. Quels seraient les services à offrir (à part bien sûr le minimum syndical façon blocage de port) - blocage d'URL à destination de hosts, URI, paramètres invalides? - blocage d'AS? Pays ? François-Frédéric Elle existe. URL, certains paramètres de cet dernière, body inspection, type de requête (GET, POST etc), cookie, header HTTP, regexp sur tous ces critères. etc.. Info geo aussi donc effectivement AS, Pays. Comme le dis Alexis, ça oblige à rerouter le trafic mais dépendamment de l'étendue des dégâts c'est parfois la solution la plus rapide pour mitiger l'attaque. Antoine --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
'soir, Le 26 décembre 2011 17:35, Texier, Matthieu mtex...@arbor.net a écrit : Argument tout a fait recevable et même, pour ce qui est la législation Française, juridiquement recevable … sauf erreur de ma part, un trafic entré en France n'est pas sensé aller faire un petit tour aux US ou ailleurs et revenir… D'un point de vue technique ça n'a pas bcp de sens effectivement. D'un point de vue éthique, ça veut dire qu'on mettrait des postes de douane à chaque tuyaux qui sort du territoire. Il faut pas imaginer des trucs comme ça :-) Si il y a des juristes dans cette liste de diffusion, ils pourront nous donner la loi/réglementation en vigueur, je doit avouer que je n'ai pas plus de détail sur ce point. A ma connaissance ça se fait... en Chine ! Antoine --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
On 12/26/11 12:04 PM, Charles Delorme wrote: Bonjour, Le père Noël nous a gâté et nous subissons au Sénat une attaque par déni de service depuis dimanche matin 7h heure locale. La très grosse majorité des paquets est en udp/80 à destination de nos deux liens, completel (213.30.147.224/27) et global crossing (217.156.140.224/27) et aussi un peu en udp/53. Nous tentons d'établir une liste d'adresses sources mais vous vous doutez qu'elle varie beaucoup. Les supports des deux opérateurs sont bien sûr prévenus. Si en plus certains d'entre vous ont la possibilité de bloquer au moins le traffic en udp/80 qui passerait par vos réseaux vers chez nous, ceci nous pemettrait de respirer un peu. Tout avis en la matière sera le bienvenu. Je passe par cette adresse mail perso car pour l'instant nos accès sont saturés. Merci beaucoup et joyeux Noël à tous :-) Charles Delorme http://www.leparisien.fr/flash-actualite-politique/loi-sur-les-genocide-les-menaces-contre-la-deputee-boyer-suscitent-l-indignation-26-12-2011-1784329.php --- Le site de la députée restait inactif lundi. Quant à celui du Sénat, il était régulièrement inaccessible depuis dimanche à cause d'une opération de saturation du site orchestrée par des éléments extérieurs, pour l'heure non identifiés, selon le service de communication de la Haute assemblée. --- On parle de vous tiens. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
Ca se discute. Ici, l'OP n'a pas précisé quels liens étaient saturés. J'assume qu'il parlait de ses propres liens à lui (l'uplink avec ses 2 upstreams) et non pas les liens de ses opérateurs upstream, qui doivent être un peu plus costauds. Ainsi, s'il fait dropper par ses upstreams le trafic 80/udp, ça va très largement l'aider. Evidemment et comme soulevé maintes fois déjà, c'est une solution qui présente des contraintes, notamment le temps de réaction des transitaires. On 12/26/11 5:46 PM, Guillaume Esnault wrote: Bonjour à tous et bonnes fêtes, Quand l'attaque est à la vitesse des liens, il n'est plus possible de filtrer avec quoi que ce soit. La cible doit être null routée au niveau des opérateurs (via une communauté BGP spéciale). La seule solution qui reste est d'utiliser un CDN couplé à des serveurs de nom spéciaux permettant de distribuer la charge intelligemment. Des acteurs majeurs comme Microsoft/Google on vu leur réseau mis à plat par des dénis de services et n'ont eu d'autre choix que de passer par un CDN (Akamai en l'occurrence). Internet'ment vôtre, Guillaume Esnault Digicube sas Le lundi 26 décembre 2011 à 12:04 +0100, Charles Delorme a écrit : Bonjour, Le père Noël nous a gâté et nous subissons au Sénat une attaque par déni de service depuis dimanche matin 7h heure locale. La très grosse majorité des paquets est en udp/80 à destination de nos deux liens, completel (213.30.147.224/27) et global crossing (217.156.140.224/27) et aussi un peu en udp/53. Nous tentons d'établir une liste d'adresses sources mais vous vous doutez qu'elle varie beaucoup. Les supports des deux opérateurs sont bien sûr prévenus. Si en plus certains d'entre vous ont la possibilité de bloquer au moins le traffic en udp/80 qui passerait par vos réseaux vers chez nous, ceci nous pemettrait de respirer un peu. Tout avis en la matière sera le bienvenu. Je passe par cette adresse mail perso car pour l'instant nos accès sont saturés. Merci beaucoup et joyeux Noël à tous :-) Charles Delorme --- 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] [ALERT] Attaque en déni de service en cours
Bonsoir Antoine, Vous êtes juriste ? Chinois peut-être :-) ? Si l'on prend un exemple d'une entreprise ayant des échanges commerciaux ou à caractères confidentiels, je pense qu'elle n'aimerait pas trop que son trafic fasse un petit tour sur un plate-forme prenant des engagements vagues ou dépendant d'une législation non maitrisé pour finalement revenir sur le pays du béret, camembert et bouteille de bordeaux sous le bras… Il me semble (même si on peut le déplorer) que l'époque Internet Oui-Oui au pays de Bisounours n'est plus d'actualité. Maintenant, vive l'Internet libre :-) ! Matthieu. On Dec 26, 2011, at 5:46 PM, Antoine Drochon wrote: 'soir, Le 26 décembre 2011 17:35, Texier, Matthieu mtex...@arbor.netmailto:mtex...@arbor.net a écrit : Argument tout a fait recevable et même, pour ce qui est la législation Française, juridiquement recevable … sauf erreur de ma part, un trafic entré en France n'est pas sensé aller faire un petit tour aux US ou ailleurs et revenir… D'un point de vue technique ça n'a pas bcp de sens effectivement. D'un point de vue éthique, ça veut dire qu'on mettrait des postes de douane à chaque tuyaux qui sort du territoire. Il faut pas imaginer des trucs comme ça :-) Si il y a des juristes dans cette liste de diffusion, ils pourront nous donner la loi/réglementation en vigueur, je doit avouer que je n'ai pas plus de détail sur ce point. A ma connaissance ça se fait... en Chine ! Antoine Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.netmailto:mtex...@arbor.net +33 6 85 83 66 89 --- Liste de diffusion du FRnOG http://www.frnog.org/
[TECH] Re: [FRnOG] [ALERT] Attaque en déni de service en cours
Hello, D'un point de vu plus pratique, un opérateur de transit ne propose pas ce genre de service en standard. Nous fournissons des communautés de blackhole ou nous blackholons le trafic lorsque cela est vraiment ultra justifié. Le blackhole sur un réseau opérateur impacte l'ensemble de ses autres clients. Meme si pour des raisons légitime, un client se fait flooder, nous n'allons pas rentre indisponible une destination pour juste 1 client. Si on regarde le soucis qu'il y a eu sur le bug de la mort qui tue sur les routeurs Ericsson, je ne vais pas bloquer des routes ( de l'opérateur à l'origine des updates pourries ) juste parce que 4 ou 5 clients sur 500 ont des problèmes. ( heureusement que ce n'est pas super répandu comme routeur ). En tant qu'opérateur, on laisse passer l'attaque, car : - Notre métier c'est de fournir de la BP - Notre métier ce n'est pas pas filtrer la BP Si le client souscrit à un service de protection D/DOS ( de plus en plus d'opérateurs le mettent en place ), le noc de l'opérateur est en mesure sur demande de filtrer les attaques ( et uniquement sur demande / validation du client ). Les protections de type flowspec, sont d'une propriétaire, et de deux consomment des ressources sur les routeurs backbones. Les vrais solutions ( comme Arbor ) sont nettement plus performante, mais coutent de l'argent avec le Noc compétent, les ingénieurs qui maitrisent ! Le hardware coute aussi, mais ce n'est pas le plus important dans la solution ! Le monde des bisounours ou tout est gratuit ça n'existe pas. Un opérateur doit maintenant être en mesure de proposer une solution de ce type, mais n'en est pas obligé -- Raphaël Maunier NEO TELECOMS CTO / Directeur Ingénierie AS8218 On 12/26/11 5:56 PM, Texier, Matthieu mtex...@arbor.net wrote: Bonsoir Antoine, Vous êtes juriste ? Chinois peut-être :-) ? Si l'on prend un exemple d'une entreprise ayant des échanges commerciaux ou à caractères confidentiels, je pense qu'elle n'aimerait pas trop que son trafic fasse un petit tour sur un plate-forme prenant des engagements vagues ou dépendant d'une législation non maitrisé pour finalement revenir sur le pays du béret, camembert et bouteille de bordeaux sous le brasŠ Il me semble (même si on peut le déplorer) que l'époque Internet Oui-Oui au pays de Bisounours n'est plus d'actualité. Maintenant, vive l'Internet libre :-) ! Matthieu. On Dec 26, 2011, at 5:46 PM, Antoine Drochon wrote: 'soir, Le 26 décembre 2011 17:35, Texier, Matthieu mtex...@arbor.netmailto:mtex...@arbor.net a écrit : Argument tout a fait recevable et même, pour ce qui est la législation Française, juridiquement recevable Š sauf erreur de ma part, un trafic entré en France n'est pas sensé aller faire un petit tour aux US ou ailleurs et revenirŠ D'un point de vue technique ça n'a pas bcp de sens effectivement. D'un point de vue éthique, ça veut dire qu'on mettrait des postes de douane à chaque tuyaux qui sort du territoire. Il faut pas imaginer des trucs comme ça :-) Si il y a des juristes dans cette liste de diffusion, ils pourront nous donner la loi/réglementation en vigueur, je doit avouer que je n'ai pas plus de détail sur ce point. A ma connaissance ça se fait... en Chine ! Antoine Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.netmailto:mtex...@arbor.net +33 6 85 83 66 89 --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
