Yep c'est une technique. (et cogent doit faire).
Ceci dit il faut que ton trafic in passe déjà naturellement par le transitaire qui te fournit le port poubelle. Si n'est pas le cas tu es obligé de désagréger, ce qui est pénible si le ddoseur s'amuse à faire du random.

Sinon vu que tu te fais quand même attaquer souvent je pense que prendre un transit qui propose une vrai solution de filtrage anti ddos sera un bon investissement.

--
Raphael Mazelier



On 27/09/2017 15:54, Mickael Marchand wrote:
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/



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

Répondre à