Il n'est pas recommandé aussi de demander à ses fournisseurs de mettre en place une communauté BGP permettant d'envoyer un /32 dans un blackhole avant que ça arrive sur ton lien ? Si ça évite de doubler ta capacité de transit (dont l'efficacité est partielle), ça fait une belle économie.
David Ponzone > Le 24 nov. 2016 à 01:17, Jeremy <li...@freeheberg.com> a écrit : > > Salut, > > Tu as trois solutions qui vont dépendre de ton budget et de tes compétences > en interne : > 1) Soit tu vas voir des mecs comme Arbor, Fortiner, ou autre fournisseur de > firewall qui ont des gammes spécifiques pour gérer les attaques a forte > amplitude comme les amplifications. Le point négatif, c'est que c'est très > élevé en terme de prix, à l'achat, et en support. C'est une approche qui > plait souvent aux DSI même si elle coute cher, tu renvoit la responsabilité à > l'éditeur de la solution qui doit se démerder (si tu prend le support qui va > bien). > > 2) Soit tu développe une solution interne basée sur des cluster réseaux avec > beaucoup de CPU, de RAM et de ports SFP+ 10G. Tu met des solutions > logicielles dessus (par exemple, Wanguard, entre plein d'autres), et tu > configure le bouzin (c'est le plus lourd à faire). Ensuite, une session BGP > avec tous tes routeurs de bordure pour amener les attaques à lui quand elles > sont détectés (via un serveur qui analyse le sflow de tes routeurs, qui doit > avoir sa propre licence Wanguard sensor). > L'application a un mode apprentissage, et une complexité de règles assez > étendu puisque la solution est basée sur iptables en partie. Ca fait aussi le > taf de supervision. L'aspect négatif, c'est que c'est lourd a déployer en > ressources internes. Le positif c'est qu'à long terme, les licences sont > beaucoup moins cher que les solutions full hardware, et ça fait aussi bien le > taf quand c'est bien configuré. > > 3) Tu demande à tes transitaire de te protéger en amont, ce sont des > solutions souvent pertinentes en terme de cout, mais tu as moins la maitrise > du trafic et des réglages fin qui sont parfois necessaire pour stopper > efficacement une attaque. > > Sans oublier bien sur qu'il faut avoir un plan global d'augmentation de la > capacité d'entrée dans l'AS, donc multiplier les ports 10G (ou plus) vers tes > transitaires et points de peering. Si l'attaque n'est pas capable de passer, > ça sert à rien d'aller la filtrer plus loin dans le réseau. Le mieux étant > d'avoir une infra à chaque routeur de bordure (protégeant ainsi le LAN > quelqu'il soit derrière). > > Cumulé a quelques règles ACL de type rate-limit en bordure du réseau, ça > permet de faire un truc qui tient la route et qui répond a 95 % des besoins. > > > Pour exemple, OVH. Leur stratégie est simple : > 1) Un max d'interconnexion (ils sont à 1.5 Tb/s je crois vers internet ?) > 2) Une infra interne soit soft, soit hard qui peut traiter tout le volume > (prévoir de manière intelligente le nombre de ports 10G/b et avoir la > capacité de transporter ce flux de la bordure de l'AS à cette infra). > 3) Renvoyer le trafic nettoyé au routeur de salle (OSPF de mémoire) pour > réinjecter le trafic vers le serveur proprement. > Leur solution est basée sur 3 systèmes différents : Arbor, Tilera et scripts > internes. Les 3 cumulés ont une bonne efficacité avec un mixte de solutions > cher et de solutions plus accessibles. > > Jérémy > > > > >> Le 24/11/2016 à 00:38, Gabriel dacko a écrit : >> Bonsoir Chers tous , >> >> Du fait des récentes attaques sur Dyn , OVH , Krebs , Liberia etc. Dans >> certaines entreprises , l'heure est a la ré-evaluation des solutions >> et plans mis en place pour mitiger les attaques DDoS. C'est notre cas en >> tout cas . >> >> J'aimerai avoir votre retour d’expérience sur les solutions existantes ou >> plan réponse qui font leurs preuves. >> >> Merci d'avance de vos retours/ >> > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
