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/

Répondre à