Merci pour vos retours et pointeurs déjà ! J'essaie de ne pas (trop) rater d'éléments, et comme il y a des choses qui se recoupent entre les différents mails, j'essaie de synthétiser :
- je mentionne des pcaps car on a pour l'instant trouvé cela chez ddossb.org et MAWI (http://www.fukuda-lab.org/mawilab/v1.1/index.html et https://mawi.wide.ad.jp/mawi/). Il y a des projets académiques qui font des pcap, il y a peut-être des entreprises qui pcap-ent des bouts de trafic spécifiques. Mais peu importe en effet, des logs, des netflows, etc. : fondamentalement, on cherche des IP source + des volumes/tailles de paquets depuis chacune de ces IP - le spoofing, oui, c'est un problème. À cela j'ai 2 éléments. Le premier est qu'il faut bien commencer par quelque part, et que le spoofing est dans la TODO list nécessaire, mais juste après. Le 2nd, c'est qu'on trouve dans nos bases actuelles (DDosDB et MAWI, donc) du DDoS TCP (en plus de UDP et ICMP), c'est une première piste pour essayer d'évaluer le "taux de spoofing" par différence entre TCP et UDP. On a une autre piste en étudiant le taux d'IP sources impossibles (des blocs non encore exploités en production mais qui seraient spoofés quand même) et en extrapolant. Ce ne sont que des pistes, c'est l'étape suivante. Elle est nécessaire je rejoins complètement cette remarque, mais on ne peut pas tout paralléliser, et pour essayer de discrimer le spoofing il faut des données à analyser, donc on en revient à cette dépendance préalable - ce qu'on cherche à évaluer, ce n'est pas le bruit de fond d'internet (c'est moi qui avais mis ce mot-là dans mon mail initial, my bad) mais la structuration d'une vraie attaque contre une vraie cible. La construction d'un honeypot, par exemple donc, n'était pas une piste intéressante. On aurait besoin de construire (au hasard) un serveur de jeu, le rendre populaire, donc cible, et enfin analyser son trafic entrant. Mais ça, clairement, on ne pourra pas le faire. - on ne cherche pas non plus à évaluer les compromissions des machines (auquel cas, en effet, on branche un device IoT accessible de l'extérieur et on attend :) ), mais bien, côté cible, à évaluer ce qu'on reçoit. Il faut donc, d'abord, être une cible d'attaque DDoS (et non une cible à compromettre pour servir de relai) Si jamais cela peut aider à préciser... Pour compléter, soyons clairs et honnêtes : il y a *plein* de choses auxquelles nous n'avons pas encore pensé, et nous ne doutons pas qu'elles surgiront en temps voulu :) . Cordialement, François Lesueur Le 06/05/2020 à 11:16, Kavé Salamatian a écrit : > +1 > C’est aussi un problème classique > > >> Le 6 mai 2020 à 11:14, Stephane Bortzmeyer <bortzme...@nic.fr> a écrit : >> >> On Wed, May 06, 2020 at 10:11:16AM +0200, >> Francois Lesueur <francois.lesu...@insa-lyon.fr> wrote >> a message of 52 lines which said: >> >>> Concrètement, nous cherchons à avoir accès à des traces d'attaques DDoS >>> subies (pcap, netflow). Nous avons un script qui peut-être exécuté soit >>> par nous, soit du côté de la capture. En sortie de ce script, il n'y a >>> plus d'IP précise >> >> Pour les attaques de mon domaine, les adresses IP source sont souvent >> usurpées. Comment vous gérez cela ? >> >> >> --------------------------- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
