Slow Loris est tout sauf un D(pour Distributed)DOS justement ... C'est un DOS, mais dont le but est d'être lancé en solitaire depuis une machine peu puissante.
C'est une attaque de couche 7, donc il faut un équipement capable de lire la couche 7. La CPU est le premier truc qui vient à l'esprit car assez agile pour adapter un code pour lire la couche 7, alors qu'un FPGA sera forcément spécialisé dans ce seul pattern d'attaque (et du coup pas utilisable pour d'autres attaques). Le 14 octobre 2013 23:47, Fabien Delmotte <fdelmot...@mac.com> a écrit : > Bonsoir, > > DDOS oui mais de quoi parlons nous ? > Syn flood est un DDOS et un FPGA peut le contrer .. > Slow loris est un DDOS et il faut une CPU (je crois).. > > Tout cela pour dire qu'en fonction des tuyaux (taille) et des fonctions > DDOS que l'on veut mettre en oeuvre, la solution PC open Source peut être > valide et pour certain cas l'assistance d'un hardware est indispensable. > Donc il n'y a pas de solution miracle. Que le client exprime correctement > ses besoins et les ingénieurs pourront proposer des solutions > > Mes 2 cents. > > Cordialement > > Fabien > > Le 14 oct. 2013 à 23:36, Kavé Salamatian <kave.salamat...@univ-savoie.fr> > a écrit : > > > +1 > > > > C'est aussi mon propos. > > > > Kavé > > Le 14 oct. 2013 à 23:32, Frederic Dhieux <frede...@syn.fr> a écrit : > > > >> Le 10/14/13 10:44 PM, Kavé Salamatian a écrit : > >>> > >>> > >>> La différence c'est qu'on peut pas craner sur le montant du cheque à 6 > chiffre qu'on a payé pour sa solution pro, et puis tout le monde à oublié > le credo de l'ingénieur qui est de trouver la solution la moins couteuse > qui répond au besoin … Aujourd'hui c'est la solution qui réduit le plus le > cout récurrent ( le salaire des personnes) quitte à faire exploser le cout > du matériel (qui va fréquemment dans la colonne investissement) qui a le > vent en poupe. La solution d'ingénieur brillante qui répond au besoin à > moindre cout quitte à avoir besoin d'être configuré en CLI est vue comme du > "bricolage" avec tout le mépris de pseudo-ingénieurs "commerciaux" … alors > que la solution qui coute bonbon fait "pro". > >>> > >>> > >> > >> C'est assez triste de voir 2 extrêmes s'affronter sans nuance. OK les > >> solutions commerciales sont parfois scandaleuses (les load balancers > >> sont le premier exemple qui me vient en tête avant un certain volume et > >> certaines fonctionnalités), mais il faut arrêter aussi de croire qu'avec > >> un Linux/BSD on peut atteindre les niveaux de traitement d'une solution > >> pure hardware. > >> > >> Déjà il faut bien séparer une solution hardware basée sur une > >> architecture PC rebrandée et une vraie archi hardware avec ses > >> processeurs spécialisés, ses puces dédiées, etc. > >> > >> Aussi les serveurs actuels sont parfois assez puissants pour faire des > >> choses, parfois les gens documentent mieux que le petit ingénieur > >> surdoué et permettent un suivi, mais il faut l'admettre, pour certaines > >> fonctions les solutions hardware tiennent bien mieux. > >> > >> Quand on parle d'attaques, on parle en général de flux dont l'objectif > >> est d'atteindre une saturation (de tuyaux, de connexions, de slots du > >> services, ...). Dans ce cas avec la multitudes de sources et de flux, il > >> est logique de voir des solutions matérielles plus adaptées à ce type de > >> traitement. > >> > >> On peut discuter du support, on peut discuter de la fiabilité, on peut > >> discuter de la capacité à régler soi même des problèmes sans être > >> dépendant d'un support trop long à se bouger aussi en contreparite. > >> > >> Mais limiter le débât à "C'est juste pour dire qu'on a la plus grosse > >> qui coûte cher pour rassurer le client" VS "C'est de la bidouille de > >> geek dans son coin inmaintenable", c'est vraiment noyer tout > >> argumentaire constructif selon moi. > >> > >> > >> Pour moi le problème c'est surtout de savoir à partir de quel volume une > >> solution n'est plus adaptée et peser le pour et le contre en fonction du > >> nombre de personnes pour s'en occuper versus le budget d'une solution > >> toute faite avec support. Et également de calculer le risque en cas de > >> problème et l'impact sur la santé financière de la société. Quand je > >> vois quelqu'un parler de "suicide" dans un titre de sujet sur le FRnOG > >> parce qu'il n'a aucune solution pour se protéger, ça me donne > >> l'impression d'un mec qui n'a aucune assurance et qui voit sa boutique > >> bruler, avec juste un verre d'eau à la main pour l'éteindre sans jamais > >> s'être posé la question avant. > >> > >> > >> Pour finir quand on a des clients derrière sa solution, on n'a pas le > >> droit à l'erreur. Si on se plante et qu'on a fait le truc soi même, on > >> se fait torpiller par ses clients. Quand on a un constructeur derrière, > >> on gagne une certaine crédibilité et on n'est moins coupable si la > >> solution est connue/réputée (ça n'empêche pas qu'il y a des gens très > >> doués pour ne pas savoir les implémenter parfois). Alors faire joujou > >> c'est sympa, mais faut être sûr de maitriser tous les cas, de tenir les > >> pics et de pouvoir assumer face à ses clients. > >> > >> > >> Bref, le débat est nuancé par l'activité à protéger, par l'impact, par > >> l'équipe derrière la gestion de l'infra et par ce qu'on veut faire de sa > >> boîte. > >> > >> Claquer des gros chèques chez un constructeur ça fonctionne souvent, ça > >> ne sert à rien parfois aussi. Chercher à réinventer la roue quand on > >> peut s'appuyer sur des fournisseurs/partenaires qui savent mieux le > >> faire (techniquement ou financièrement), ça n'est pas forcément > >> intelligent non plus. > >> > >> Bien s'entourer mène souvent bien plus loin qu'être intelligent tout > >> seul. Pour autant l'argent n'est pas forcément gage de qualité. > >> > >> > >> My 2 cents, > >> Frederic > >> > >> > >> --------------------------- > >> 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/ > -- Cordialement, Guillaume BARROT --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
