[FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
Très bon travail de Dobbins : https://app.box.com/s/r7an1moswtc7ce58f8gg Notez surtout la fin, « que faire » et, encore mieux, le slide « que ne PAS faire », qui rassemble beaucoup de c...ies faites au nom de la lutte anti-DoS. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
Le 30/05/2014 à 13h42, Stephane Bortzmeyer a écrit : Très bon travail de Dobbins : https://app.box.com/s/r7an1moswtc7ce58f8gg Notez surtout la fin, « que faire » et, encore mieux, le slide « que ne PAS faire », qui rassemble beaucoup de c...ies faites au nom de la lutte anti-DoS. Bonjour, serait-il possible d’avoir un lien direct vers le PDF ne nécessitant pas de faire tourner un script javascript privateur et lourd qui a tendance à faire freezer les navigateurs libres modernes — néanmoins insuffisamment parallélisés ? signature.asc Description: PGP signature
Re: [FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
+1 Y. Le 30 mai 2014 13:42, Stephane Bortzmeyer bortzme...@nic.fr a écrit : Très bon travail de Dobbins : https://app.box.com/s/r7an1moswtc7ce58f8gg Notez surtout la fin, « que faire » et, encore mieux, le slide « que ne PAS faire », qui rassemble beaucoup de c...ies faites au nom de la lutte anti-DoS. --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Youssef BENGELLOUN-ZAHR --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
Salut Stephane, Oui c'est interessant, mais ces techniques de blocage de requetes DNS sont tres discutables et pourraient devenir rapidement un outil extraordinaire pour les hackers. Par exemple une requete DNS bloquee facilite le cache poisoning. Ou encore avoir la possibilite de bloquer l'adresse IP (spoofe) d'un serveur racine ou du DNS d'un ISP est une tres belle opportunite pour mettre la pagaille. De mon point de vue, la meilleure solution est de ne pas bloquer les requetes DNS mais d'y repondre. -- Jean-Yves Bisiaux Le 30 mai 2014 13:42, Stephane Bortzmeyer bortzme...@nic.fr a écrit : Très bon travail de Dobbins : https://app.box.com/s/r7an1moswtc7ce58f8gg Notez surtout la fin, « que faire » et, encore mieux, le slide « que ne PAS faire », qui rassemble beaucoup de c...ies faites au nom de la lutte anti-DoS. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
Il suffit pas de cliquer en haut à droite sur « Téléchargement » ? Ok ça demande de supporter 30 secondes de JS. David Le 30 mai 2014 à 14:08, Garreau, Alexandre galex-...@galex-713.eu a écrit : Le 30/05/2014 à 13h42, Stephane Bortzmeyer a écrit : Très bon travail de Dobbins : https://app.box.com/s/r7an1moswtc7ce58f8gg Notez surtout la fin, « que faire » et, encore mieux, le slide « que ne PAS faire », qui rassemble beaucoup de c...ies faites au nom de la lutte anti-DoS. Bonjour, serait-il possible d’avoir un lien direct vers le PDF ne nécessitant pas de faire tourner un script javascript privateur et lourd qui a tendance à faire freezer les navigateurs libres modernes — néanmoins insuffisamment parallélisés ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
Pour ceux qui sont allergiques au JS : wget http://presentations.liopen.fr/reflectionamplificationpublic.pdf --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
Le 30/05/2014 à 14h24, David Ponzone a écrit : Le 30 mai 2014 à 14h08, « Garreau, Alexandre » a écrit : Le 30/05/2014 à 13h42, Stephane Bortzmeyer a écrit : Très bon travail de Dobbins : https://app.box.com/s/r7an1moswtc7ce58f8gg Notez surtout la fin, « que faire » et, encore mieux, le slide « que ne PAS faire », qui rassemble beaucoup de c...ies faites au nom de la lutte anti-DoS. Bonjour, serait-il possible d’avoir un lien direct vers le PDF ne nécessitant pas de faire tourner un script javascript privateur et lourd qui a tendance à faire freezer les navigateurs libres modernes — néanmoins insuffisamment parallélisés ? Il suffit pas de cliquer en haut à droite sur « Téléchargement » ? L’apparition de ce bouton et son fonctionnement requiert l’exécution d’un javascript privateur et suffisamment lourd pour faire freezer le seul navigateur décent dont je dispose (Iceweasel, le reste est peu ou pas acceptable, par sa qualité ou ses abus). Ok ça demande de supporter 30 secondes de JS. T’as eu de la chance, suffisamment peu d’onglets/fenêtres ouvertes, suffisamment peu de processus lancés, etc. pour que ça ne dure que 30 secondes, moi au bout d’un quart d’heure j’ai abandonné. Mais tu peux aussi poster l’adresse du PDF que fait télécharger le bouton « Télécharger » aussi, ça évite deux messages inutiles ;) signature.asc Description: PGP signature
Re: [FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
Mouais Avec Iceweasel 26, ça baigne. C'est sur que si tu utilises encore la version 3.5, avec la sale manie qu'ont les techno web de changer tout les 15min, c'est sensiblement plus délicat On 30/05/2014 14:38, Garreau, Alexandre wrote: Le 30/05/2014 à 14h24, David Ponzone a écrit : L’apparition de ce bouton et son fonctionnement requiert l’exécution d’un javascript privateur et suffisamment lourd pour faire freezer le seul navigateur décent dont je dispose (Iceweasel, le reste est peu ou pas acceptable, par sa qualité ou ses abus). Ok ça demande de supporter 30 secondes de JS. T’as eu de la chance, suffisamment peu d’onglets/fenêtres ouvertes, suffisamment peu de processus lancés, etc. pour que ça ne dure que 30 secondes, moi au bout d’un quart d’heure j’ai abandonné. Mais tu peux aussi poster l’adresse du PDF que fait télécharger le bouton « Télécharger » aussi, ça évite deux messages inutiles ;) -- UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things. – Doug Gwyn --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
Je n’ai effectivement que 12 fenêtres Safari ouvertes et que 37 onglets au total dans ces 12 fenêtres. Et une quinzaine d’autres applications ouvertes (dont Firefox et Xcode). Je dois admettre que je dépasse rarement ce niveau donc je ménage probablement mon Mac. Après vérification, je n’ai pas mis 30 secondes, mais 11 secondes pour que la page https://app.box.com/s/r7an1moswtc7ce58f8gg s’affiche, pour cliquer sur le lien Téléchargement, et pour que le PDF de 7Mo arrive. Est-ce qu’il serait éventuellement possible que le problème vienne de ton PC/Mac ? Le 30 mai 2014 à 14:38, Garreau, Alexandre galex-...@galex-713.eu a écrit : Le 30/05/2014 à 14h24, David Ponzone a écrit : Le 30 mai 2014 à 14h08, « Garreau, Alexandre » a écrit : Le 30/05/2014 à 13h42, Stephane Bortzmeyer a écrit : Très bon travail de Dobbins : https://app.box.com/s/r7an1moswtc7ce58f8gg Notez surtout la fin, « que faire » et, encore mieux, le slide « que ne PAS faire », qui rassemble beaucoup de c...ies faites au nom de la lutte anti-DoS. Bonjour, serait-il possible d’avoir un lien direct vers le PDF ne nécessitant pas de faire tourner un script javascript privateur et lourd qui a tendance à faire freezer les navigateurs libres modernes — néanmoins insuffisamment parallélisés ? Il suffit pas de cliquer en haut à droite sur « Téléchargement » ? L’apparition de ce bouton et son fonctionnement requiert l’exécution d’un javascript privateur et suffisamment lourd pour faire freezer le seul navigateur décent dont je dispose (Iceweasel, le reste est peu ou pas acceptable, par sa qualité ou ses abus). Ok ça demande de supporter 30 secondes de JS. T’as eu de la chance, suffisamment peu d’onglets/fenêtres ouvertes, suffisamment peu de processus lancés, etc. pour que ça ne dure que 30 secondes, moi au bout d’un quart d’heure j’ai abandonné. Mais tu peux aussi poster l’adresse du PDF que fait télécharger le bouton « Télécharger » aussi, ça évite deux messages inutiles ;) --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
On Fri, May 30, 2014 at 02:20:32PM +0200, Jean-Yves Bisiaux j...@efficientip.com wrote a message of 67 lines which said: Oui c'est interessant, mais ces techniques de blocage de requetes DNS sont tres discutables et pourraient devenir rapidement un outil extraordinaire pour les hackers. Bloquer le DNS ? L'article dit exactement le contraire « Do not indiscriminately block UDP/53 on your networks! » --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
Le 30/05/2014 à 14h50, David Ponzone a écrit : Le 30/05/2014 à 14h38, « Garreau, Alexandre » a écrit : Le 30/05/2014 à 14h24, David Ponzone a écrit : Le 30/05/2014 à 14h08, « Garreau, Alexandre » a écrit : Le 30/05/2014 à 13h42, Stephane Bortzmeyer a écrit : Très bon travail de Dobbins : https://app.box.com/s/r7an1moswtc7ce58f8gg Notez surtout la fin, « que faire » et, encore mieux, le slide « que ne PAS faire », qui rassemble beaucoup de c...ies faites au nom de la lutte anti-DoS. Bonjour, serait-il possible d’avoir un lien direct vers le PDF ne nécessitant pas de faire tourner un script javascript privateur et lourd qui a tendance à faire freezer les navigateurs libres modernes — néanmoins insuffisamment parallélisés ? Il suffit pas de cliquer en haut à droite sur « Téléchargement » ? L’apparition de ce bouton et son fonctionnement requiert l’exécution d’un javascript privateur et suffisamment lourd pour faire freezer le seul navigateur décent dont je dispose (Iceweasel, le reste est peu ou pas acceptable, par sa qualité ou ses abus). Ok ça demande de supporter 30 secondes de JS. T’as eu de la chance, suffisamment peu d’onglets/fenêtres ouvertes, suffisamment peu de processus lancés, etc. pour que ça ne dure que 30 secondes, moi au bout d’un quart d’heure j’ai abandonné. Je n’ai effectivement que 12 fenêtres Safari ouvertes et que 37 onglets au total dans ces 12 fenêtres. Et une quinzaine d’autres applications ouvertes (dont Firefox et Xcode). Je dois admettre que je dépasse rarement ce niveau donc je ménage probablement mon Mac. Safari est peut-être mieux parallélise, qu’en sais-je ? Pour moi il continue à faire partie des navigateur pas décemment acceptables, donc la question ne se pose pas. Après vérification, je n’ai pas mis 30 secondes, mais 11 secondes pour que la page https://app.box.com/s/r7an1moswtc7ce58f8gg s’affiche, pour cliquer sur le lien Téléchargement, et pour que le PDF de 7Mo arrive. Bien, bah t’as un navigateur à jour sur tous les points techniques, aussi bien bon que mauvais (dieu^Wqui diable sait ce que fout Safari ?). Est-ce qu’il serait éventuellement possible que le problème vienne de ton PC/Mac ? Mmh… je doutes très fortement que le mauvais fonctionnement d’*un* logiciel soit dû au matériel. Probablement un problème d’obsolescence de quelques vieux softs encore sous Sid, des trucs lourds inutiles, etc. Je ferais le ménage un jour (btw c’est un poil provocateur d’accuser d’utiliser un Mac quelqu’un qui parle d’abus et décence logicielles). Le 30/05/2014 à 14h45, fr...@jack.fr.eu.org a écrit : Le 30/05/2014 14h38, « Garreau, Alexandre » a écrit : Mais tu peux aussi poster l’adresse du PDF que fait télécharger le bouton « Télécharger » aussi, ça évite deux messages inutiles ;) Avec Iceweasel 26, ça baigne. T’as recompilé pour avoir la 26 ? Ou c’est moi qui met pas assez souvent à jour… C'est sur que si tu utilises encore la version 3.5, avec la sale manie qu'ont les techno web de changer tout les 15min, c'est sensiblement plus délicat 24.5, celle de la dernière fois que j’ai fait une mise-à-jour, sous Sid. Après le problème vient plutôt de changer de façon irrégulière des standards complexes quand un simple lien direct et une meilleure intégration d’application externes suffit. Le 30/05/2014 à 14h32, Denis Fondras a écrit : Pour ceux qui sont allergiques au JS : wget http://presentations.liopen.fr/reflectionamplificationpublic.pdf Et hop le problème ne se pose plus (s/wget http/torify wget https/, btw). :) signature.asc Description: PGP signature
Re: [FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
Salut, ça fait aussi crasher mon Nigthly, mis à jour chaque nuit, avec les dernières corrections de bug de Mozilla. Jean-Marc Gailis --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
On Fri, May 30, 2014, at 14:20, Jean-Yves Bisiaux wrote: Oui c'est interessant, mais ces techniques de blocage de requetes DNS sont tres discutables et pourraient devenir rapidement un outil extraordinaire pour les hackers. Il ne parle jamais de bloquer les requetes DNS au niveau reseau, juste de ne pas repondre (en tant que resolver) a tout le monde. Il parle pas non plus de bloquer les requetes vers les serveurs faisant autorite. De mon point de vue, la meilleure solution est de ne pas bloquer les requetes DNS mais d'y repondre. Le probleme etant quand le serveur repond n'importe quoi (X fois plus de data dans le reponse que dans la requete) a une addresse spoofe. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
On Fri, May 30, 2014 at 03:20:03PM +0200, Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net wrote a message of 15 lines which said: Il ne parle jamais de bloquer les requetes DNS au niveau reseau, juste de ne pas repondre (en tant que resolver) a tout le monde. Ce qui est une Bonne Pratique depuis longtemps http://www.bortzmeyer.org/5358.html (RFC vieux de six ans) Le probleme etant quand le serveur repond n'importe quoi (X fois plus de data dans le reponse que dans la requete) a une addresse spoofe. Là, la solution est clairement la limitation de trafic (dont Dobbins ne parle pas) https://conf-ng.jres.org/2013/planning.html#article_37 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
J ai pas de soucis avec IE8 et une petite 20 d onglets Firefox et aussi quelques onglets ... C est quand meme un vieux debat l histoire des browsers ... Qui me rappelle mes 1eres utilisations de mozilla vers 97-98 et les moqueries de certains sans parler de netscape et de fork par ici et par la ... Sinon il y a toujours lynx pour les mecontents Presque sans interet comme debat surtout que c est un assez loin du sujet d origine qui pour le coup lui l est . - Message d'origine - De : Jean-Marc Gailis [mailto:jeanmarc.gai...@gmail.com] Envoyé : Friday, May 30, 2014 03:15 PM W. Europe Standard Time À : frnog-t...@frnog.org frnog-t...@frnog.org Objet : Re: [FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification Salut, ça fait aussi crasher mon Nigthly, mis à jour chaque nuit, avec les dernières corrections de bug de Mozilla. Jean-Marc Gailis --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
Oui c'est interessant, mais ces techniques de blocage de requetes DNS sont tres discutables et pourraient devenir rapidement un outil extraordinaire pour les hackers. Bloquer le DNS ? L'article dit exactement le contraire « Do not indiscriminately block UDP/53 on your networks! » Dire: • Do not indiscriminately block UDP/53 on your networks! • Do not block UDP/53 packets larger than 512 bytes! • Do not block TCP/53 on your networks! laisse a penser que certaines requetes DNS peuvent etre bloquees. Non ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
On 30 May, 2014 9:46 PM, Jean-Yves Bisiaux j...@efficientip.com wrote: Oui c'est interessant, mais ces techniques de blocage de requetes DNS sont tres discutables et pourraient devenir rapidement un outil extraordinaire pour les hackers. Bloquer le DNS ? L'article dit exactement le contraire « Do not indiscriminately block UDP/53 on your networks! » Dire: • Do not indiscriminately block UDP/53 on your networks! • Do not block UDP/53 packets larger than 512 bytes! • Do not block TCP/53 on your networks! laisse a penser que certaines requetes DNS peuvent etre bloquees. Non ? --- Liste de diffusion du FRnOG http://www.frnog.org/ D'ailleurs les requetes dns txt qui servent beaucoup pour la collecte d'url a la hussarde (oui zvelo.com je pense a toi), vous en faites quoi? --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
On Fri, May 30, 2014 at 03:46:40PM +0200, Jean-Yves Bisiaux j...@efficientip.com wrote a message of 44 lines which said: Dire: • Do not indiscriminately block UDP/53 on your networks! • Do not block UDP/53 packets larger than 512 bytes! • Do not block TCP/53 on your networks! laisse a penser que certaines requetes DNS peuvent etre bloquees. Non ? Ben, c'est pareil que pour IP. Je pense qu'on sera tous d'accord pour dire qu'il ne faut pas indiscriminately block IP on your networks, néanmoins nous allons tous bloquer des paquets de temps en temps, sur des critères comme l'adresse IP de destination, en cas de dDoS. Donc, oui, si nos serveurs crachent un flot continu de réponses DNS énormes, nous allons bloquer (ou, plus exactement, limiter) le trafic des requêtes DNS venant de cette adresse (les guillemets à cause de l'usurpation d'adresse). Agir autrement ne serait pas responsable puisque le réflecteur participe, même si ce n'est pas volontaire, à une attaque. (Notez qu'il s'agit d'une opinion personnelle, ce point ne figure *pas* dans l'exposé de Dobbins.) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
On Fri, May 30, 2014, at 14:09, Youssef Bengelloun-Zahr wrote: +1 Le 30 mai 2014 13:42, Stephane Bortzmeyer bortzme...@nic.fr a écrit : Très bon travail de Dobbins : https://app.box.com/s/r7an1moswtc7ce58f8gg Notez surtout la fin, « que faire » et, encore mieux, le slide « que ne PAS faire », qui rassemble beaucoup de c...ies faites au nom de la lutte anti-DoS. Pfff encore une fois le discours religieux Deploy antispoofing at *all* network edges. J'ai un certain probleme avec ALL; notamment cote peering edge et vers certains types de clients (on ne melange pas mme Michu avec le fourniseur d'infrastructure qui annonce 100 prefixes a 10 endroits sur 3 continents et qui a a son tour des clients qui a leur tour ont des clients). Je ne suis pas d'accord non plus avec If you get a reputation as a spoofing-friendly network, you will be de-peered/de-transited and/or blocked!; c'est juste mensonger et intellectuellement malhonnete. Sinon, le reste est quand-meme tres interessant. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: Re: [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
On Fri, May 30, 2014 at 09:54:29PM +0800, Yanik Cawidrone ycawidr...@gmail.com wrote a message of 65 lines which said: D'ailleurs les requetes dns txt qui servent beaucoup pour la collecte d'url a la hussarde (oui zvelo.com je pense a toi), vous en faites quoi? Euh, explications demandées. Je ne comprends pas comment des requêtes DNS TXT permettraient de collecter des URL (qui sont un concept d'un autre protocole...) --- Liste de diffusion du FRnOG http://www.frnog.org/
[TECH] Re: [FRnOG] Re: [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
On Fri, May 30, 2014, at 15:46, Jean-Yves Bisiaux wrote: Dire: • Do not indiscriminately block UDP/53 on your networks! • Do not block UDP/53 packets larger than 512 bytes! • Do not block TCP/53 on your networks! laisse a penser que certaines requetes DNS peuvent etre bloquees. Non ? Il s'addresse surtout aux RSSI et inges securite qui bloquent aveuglement des choses sans savoir a quoi ca correspond. On peut parler longuement sur ca, certains diront que c'est LA bonne pratique. Apres, il y a aussi difference entre bloquer (la source transmet, la destination ne recoit pas) et ne pas repondre (la source n'emet pas de reponse). --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
On Fri, May 30, 2014 at 03:56:12PM +0200, Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net wrote a message of 29 lines which said: Je ne suis pas d'accord non plus avec If you get a reputation as a spoofing-friendly network, you will be de-peered/de-transited and/or blocked!; c'est juste mensonger et intellectuellement malhonnete. Je pense que c'était plutôt un souhait, de la part de Dobbins. En effet, si les mauvais qui ne font pas de BCP 38 étaient dé-transités, ça se saurait :-} --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
Je disais que les technique de blocage sont tres discutable, dans le sens ou celles qui sont automatiques sont dangereuse car basées sur des euristiques de statistiques tres/trop simples. Le 30 mai 2014 15:26, Stephane Bortzmeyer bortzme...@nic.fr a écrit : On Fri, May 30, 2014 at 03:20:03PM +0200, Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net wrote a message of 15 lines which said: Il ne parle jamais de bloquer les requetes DNS au niveau reseau, juste de ne pas repondre (en tant que resolver) a tout le monde. Ce qui est une Bonne Pratique depuis longtemps http://www.bortzmeyer.org/5358.html (RFC vieux de six ans) Ici tu parles de resolver ouvert, moi je te le refais avec un resolver fermé. Un faux serveur autoritaire (spoofed) flood un serveur recursif fermé, tu limites la prise en compte de reponses en dropant des paquets sur ton recursif. Regarde la page 7 de ce slide: http://www.ssi.gouv.fr/IMG/pdf/DNS-OARC-2013-Blocking_DNS_Messages_Is_Dangerous.pdf Le probleme etant quand le serveur repond n'importe quoi (X fois plus de data dans le reponse que dans la requete) a une addresse spoofe. Là, la solution est clairement la limitation de trafic (dont Dobbins ne parle pas) https://conf-ng.jres.org/2013/planning.html#article_37 Je suis d'accord avec toi, c'est avant tout un pb de spoofing, qu'on ne va pas resoudre en bloquant les paquets. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
Le 30 mai 2014 15:54, Stephane Bortzmeyer bortzme...@nic.fr a écrit : On Fri, May 30, 2014 at 03:46:40PM +0200, Jean-Yves Bisiaux j...@efficientip.com wrote a message of 44 lines which said: Dire: • Do not indiscriminately block UDP/53 on your networks! • Do not block UDP/53 packets larger than 512 bytes! • Do not block TCP/53 on your networks! laisse a penser que certaines requetes DNS peuvent etre bloquees. Non ? Ben, c'est pareil que pour IP. Je pense qu'on sera tous d'accord pour dire qu'il ne faut pas indiscriminately block IP on your networks, néanmoins nous allons tous bloquer des paquets de temps en temps, sur des critères comme l'adresse IP de destination, en cas de dDoS. OK au cas par cas. Donc tu ne laisse pas un système automatique le faire à ta place ? Donc, oui, si nos serveurs crachent un flot continu de réponses DNS énormes, nous allons bloquer (ou, plus exactement, limiter) le trafic des requêtes DNS venant de cette adresse (les guillemets à cause de l'usurpation d'adresse). C'est bien pour ca que RRL renvoie toujours une reponse. Mais la tu est dans l'optique de proteger la victime. Les solutions de pure DDOS sont en périphérie du DNS et ne protège pas que les victimes mais le DNS dans sa globalité. En pensant se protéger d'une manière radicale contre un flooding (reflexion, DDOS, amplifiaction) on finit par se mettre en danger avec des mécanismes de protection. Agir autrement ne serait pas responsable puisque le réflecteur participe, même si ce n'est pas volontaire, à une attaque. (Notez qu'il s'agit d'une opinion personnelle, ce point ne figure *pas* dans l'exposé de Dobbins.) Complétement d'accord. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
On Fri, May 30, 2014 at 04:14:13PM +0200, Jean-Yves Bisiaux j...@efficientip.com wrote a message of 96 lines which said: Je disais que les technique de blocage sont tres discutable, dans le sens ou celles qui sont automatiques sont dangereuse car basées sur des euristiques de statistiques tres/trop simples. Je suggère d'essayer de mettre plus de rigueur dans la discussion. Radu-Adrian Feurdean a fait remarquer à juste titre qu'on parle ici dans une perspective d'opérateur réseau. Bloquer le DNS dans le réseau, non, et c'est ce que dit Dobbins. Mais qu'un serveur ne réponde pas, c'est tout à fait autre chose. Une machine a toujours le droit de ne pas répondre si ça la gonfle ! Peut-être je comprendrai mieux si je savais de quoi on parle ? De RRL ? Ici tu parles de resolver ouvert, moi je te le refais avec un resolver fermé. S'il est fermé, aucun problème. Et Dobbins ne cite *aucune* recommandation concernant ces résolveurs fermés. Il faut lire son exposé. Un faux serveur autoritaire (spoofed) flood un serveur recursif fermé, tu limites la prise en compte de reponses en dropant des paquets sur ton recursif. Je ne comprends pas. Si quelqu'un émet une réponse à un récursif, en se faisant passer pour un serveur faisant autorité, la réponse ne sera pas acceptée par le récursif (mauvais Query ID, port source, etc). Aucun besoin de mesure spécifique. Regarde la page 7 de ce slide: http://www.ssi.gouv.fr/IMG/pdf/DNS-OARC-2013-Blocking_DNS_Messages_Is_Dangerous.pdf Je connais. Je ne suis pas d'accord. Et, de toute façon, ce n'est pas le cas que vous décrivez, il s'agit dans cet exposé d'un serveur faisant autorité, et décidant de ne pas répondre à tout (grâce à RRL). --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
On Friday 30 May 2014 13:42:45 Bouzemarene, Farid wrote: J ai pas de soucis avec IE8 et une petite 20 d onglets Firefox et aussi quelques onglets ... C est quand meme un vieux debat l histoire des browsers ... Qui me rappelle mes 1eres utilisations de mozilla vers 97-98 et les moqueries de certains sans parler de netscape et de fork par ici et par la ... Sinon il y a toujours lynx pour les mecontents On voit bien que ça fait longtemps que tu n'as pas utilisé lynx, car justement non les mécontents ne peuvent plus utiliser lynx depuis la mode de faire du javascript une nécéssité pour accéder au contenu des pages web. les vénérables navigateurs en cli n'ont pas le support du javascript, ni lynx, ni w3m, ni netsurf, il y a bien eu links qui s'est essayé au js avant d'abandonner en 2007 et elinks qui propose une sorte de support partiel qui marche plus ou moins pas. Le problème ici n'est pas le navigateur mais bien l'usage à outrance du javascript et qui presque toujours n'apporte rien à l'usager. Quand à la question du matériel, je dispose d'un ordi doté d'un core i5, d'un ssd dernier cri et de 16Go de RAM en DDR3 et mes navigateurs ont tous le javascript désactivé par défaut pour économiser la batterie, ne pas avoir à chercher quelle tab parmi les dizaines ouvertes fait ramer l'ordi, protéger ma vie privée, éviter les pubs, marketing, animations et autres agacements qui viennent se mettre entre moi et le contenu que je veux consulter et j'en passe des meilleures. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
Sinon pour info, l'URL générée par l'hébergeur d'origine qui permet de télécharger le fichier pdf directement: https://dl.boxcloud.com/bc/4/86a2d4f14b6a07364cf81b944bec62cf/nc0JJh104Btc3zQI2dE3QgOs6fDoF8WjDxxA7-yOmuH-Z2wPu276OU8M_5IStzpu0K2vp6lL3WutyhDEjfLqwN4t_1xzzYPu2GN2sna88oGWts8EncXF557CEgQ5Z7cKK-CwCJPWfiBW_cY_lEL96IlbxXSr4TOm54uTHvdiZzOBrG145y7OrQTK7MSIH1YhKGIeC4Xv9ajXDVjtEzIgwJJVl_ZjclmpOwL3j4S5IInQaHKf7KwZj3mZ1T0pbuvvTUBsVeOcunLmssG9elsq4ii3TIyOwNXSYTVlOgMZl5INbXC2VInm0K6C2N29TySO1fYwFUTjmsmch7sEs3arDbUTokUqsFklkrY8AgYsYvWTm5TIdZlKrLYt0GOqfD0-dLtW9KIc4CMkV9G8WYXQFEYD1ufYobhhzP2jBXaqmdcPUDtLNUnV7fzhAP-k8WLPRYkj7BZnFt4M_jvNtT4MfYooZbthNrPTvJLURRBmEMgEYXqB5X5TCGQfognIwVZqBRCvDbHJ0y0uTVFFQcYUhTZcHjJefuVx4bWUUGnddozc_MmvdrycU0giLmesWnxdm9-KSHOjh-J-aEnsKFQMO8sY4DkeEFtMEWHMjn1i3xAoD8iAv9ZAnSj1mtYA6slsWoxeLjslWSkrstM9Lja14lt2g9J40l1tjgFNsxDhg1zX9Lf4RVzh35HmenTmxdh0vSYShnq22-WXTHQjQQmHDAmS5gZGs0sMhBGtO1LecO5Ep_d47KSjuF7bPtShhwmPPtc0QJtd6wzC5yPzWiTE1fOL8nmjK_1tqbuiEDM6lGN4kKish4_0M77gHRqfn62xCh883DiFKNFzVc1Vo5GrScoEnLLPgL49aUkGUVvgk0rt4T6BRw../ NB: j'ai testé en changeant de browser et ça marche, mais pas en changeant d'IP. Guillaume Le 30 mai 2014 08:32, Denis Fondras xx...@ledeuns.net a écrit : Pour ceux qui sont allergiques au JS : wget http://presentations.liopen.fr/reflectionamplificationpublic.pdf --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
Le Fri, May 30, 2014 at 03:56:12PM +0200, Radu-Adrian Feurdean [fr...@radu-adrian.feurdean.net] a écrit: Pfff encore une fois le discours religieux Deploy antispoofing at *all* network edges. J'ai un certain probleme avec ALL; notamment cote peering edge et vers certains types de clients (on ne melange pas mme Michu avec le fourniseur d'infrastructure qui annonce 100 prefixes a 10 endroits sur 3 continents et qui a a son tour des clients qui a leur tour ont des clients). C'est plus complique, mais surement pas infaisable. C'est, il me semble, une pratique courante, de filtrer les prefixes qu'on recoit sur une session BGP d'un client. Il suffit d'utiliser la meme info pour alimenter le dispositif de filtrage. Ou alors chaque acteur filtre a la bordure la plus exterieure, et ton fournisseur d'infrastructure leur fait confiance. (et coupe si y'a du spoof qui passe) -- Dominique Rousseau Neuronnexion, Prestataire Internet Intranet 21 rue Frédéric Petit - 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
On 30 May 2014, at 16:55, Dominique Rousseau d.rouss...@nnx.com wrote: Le Fri, May 30, 2014 at 03:56:12PM +0200, Radu-Adrian Feurdean [fr...@radu-adrian.feurdean.net] a écrit: Pfff encore une fois le discours religieux Deploy antispoofing at *all* network edges. J'ai un certain probleme avec ALL; notamment cote peering edge et vers certains types de clients (on ne melange pas mme Michu avec le fourniseur d'infrastructure qui annonce 100 prefixes a 10 endroits sur 3 continents et qui a a son tour des clients qui a leur tour ont des clients). C'est plus complique, mais surement pas infaisable. C'est, il me semble, une pratique courante, de filtrer les prefixes qu'on recoit sur une session BGP d'un client. Il suffit d'utiliser la meme info pour alimenter le dispositif de filtrage. Ou alors chaque acteur filtre a la bordure la plus exterieure, et ton fournisseur d'infrastructure leur fait confiance. (et coupe si y'a du spoof qui passe) Heuu filtrage RFC1918 ? Bogons ? C’est un peu la base à mon sens surtout sur de l’edge opérateur. Si tu filtres ce qu’il faut pourquoi encore virer des choses côté client ? Si tu es propres sur tes annonces .. Après le filtrage côté client - Chez nous c’est DB RIPE toutes les nuits et filtering sur les objets route etc .. Donc en gros si rien - pas de routes. Si le client fait son travail - défiltrage etc .. Bref ça devrait exister partout. Ca éviterai de voir des soucis … Pour ce qui est de faire confiance .. Pas trop non :) A+ -- Dominique Rousseau Neuronnexion, Prestataire Internet Intranet 21 rue Frédéric Petit - 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Nicolas STRINA Jaguar Network Switzerland Boulevard Georges Favon, 19 CH - 1024 Genève Leading Your Performance Tel : +33 4 88 00 65 16 Gsm : +33 6 18 20 49 55 Std : +41 8 40 65 61 11 Fax : +33 4 88 00 65 25 URL: http://www.jaguar-network.ch/ Support 24+7 : supp...@jaguar-network.ch signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
Le Fri, May 30, 2014 at 05:01:44PM +0100, Nicolas Strina [nicolas.str...@jaguar-network.com] a écrit: [...] C'est plus complique, mais surement pas infaisable. C'est, il me semble, une pratique courante, de filtrer les prefixes qu'on recoit sur une session BGP d'un client. Il suffit d'utiliser la meme info pour alimenter le dispositif de filtrage. Ou alors chaque acteur filtre a la bordure la plus exterieure, et ton fournisseur d'infrastructure leur fait confiance. (et coupe si y'a du spoof qui passe) Heuu filtrage RFC1918 ? Non, BCP38 (ie, pas laisser sortir du traf avec une ip source qui n'est pas de ton reseau) -- Dominique Rousseau Neuronnexion, Prestataire Internet Intranet 21 rue Frédéric Petit - 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
On 30 May 2014, at 17:08, Dominique Rousseau d.rouss...@nnx.com wrote: Le Fri, May 30, 2014 at 05:01:44PM +0100, Nicolas Strina [nicolas.str...@jaguar-network.com] a écrit: [...] C'est plus complique, mais surement pas infaisable. C'est, il me semble, une pratique courante, de filtrer les prefixes qu'on recoit sur une session BGP d'un client. Il suffit d'utiliser la meme info pour alimenter le dispositif de filtrage. Ou alors chaque acteur filtre a la bordure la plus exterieure, et ton fournisseur d'infrastructure leur fait confiance. (et coupe si y'a du spoof qui passe) Heuu filtrage RFC1918 ? Non, BCP38 (ie, pas laisser sortir du traf avec une ip source qui n'est pas de ton reseau) Oui tu peux inclure BCP 38. Mais c’est la combinaison de bien des choses. On est sur ce mode la. Quand tu as du client BGP tu te dois de contrôler .. Mais finalement peu de gens le font vraiment. Je parle in et out de ton network. Si tu sais filtrer en out tu sais le faire en in également. Question de temps et de volonté. A+ -- Dominique Rousseau Neuronnexion, Prestataire Internet Intranet 21 rue Frédéric Petit - 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Nicolas STRINA Jaguar Network Switzerland Boulevard Georges Favon, 19 CH - 1024 Genève Leading Your Performance Tel : +33 4 88 00 65 16 Gsm : +33 6 18 20 49 55 Std : +41 8 40 65 61 11 Fax : +33 4 88 00 65 25 URL: http://www.jaguar-network.ch/ Support 24+7 : supp...@jaguar-network.ch signature.asc Description: Message signed with OpenPGP using GPGMail
[FRnOG] Re: [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
Le 30 mai 2014 16:30, Stephane Bortzmeyer bortzme...@nic.fr a écrit : On Fri, May 30, 2014 at 04:14:13PM +0200, Jean-Yves Bisiaux j...@efficientip.com wrote a message of 96 lines which said: Je disais que les technique de blocage sont tres discutable, dans le sens ou celles qui sont automatiques sont dangereuse car basées sur des euristiques de statistiques tres/trop simples. Je suggère d'essayer de mettre plus de rigueur dans la discussion. Radu-Adrian Feurdean a fait remarquer à juste titre qu'on parle ici dans une perspective d'opérateur réseau. Bloquer le DNS dans le réseau, non, et c'est ce que dit Dobbins. Mais qu'un serveur ne réponde pas, c'est tout à fait autre chose. Une machine a toujours le droit de ne pas répondre si ça la gonfle ! Peut-être je comprendrai mieux si je savais de quoi on parle ? De RRL ? Pas de RRL qui répond lui, mais des équipements de detection de flooding et de mitigation automatique anti-DDOS. Ici tu parles de resolver ouvert, moi je te le refais avec un resolver fermé. S'il est fermé, aucun problème. Et Dobbins ne cite *aucune* recommandation concernant ces résolveurs fermés. Il faut lire son exposé. Ok, je vais bien le relire alors. :-) Un faux serveur autoritaire (spoofed) flood un serveur recursif fermé, tu limites la prise en compte de reponses en dropant des paquets sur ton recursif. Je ne comprends pas. Si quelqu'un émet une réponse à un récursif, en se faisant passer pour un serveur faisant autorité, la réponse ne sera pas acceptée par le récursif (mauvais Query ID, port source, etc). Aucun besoin de mesure spécifique. Tu le sais, c'est une approche court terme. Seul DNSSEC aujourd'hui ou d'autres mécanisme actifs garantissent la protections. Regarde la page 7 de ce slide: http://www.ssi.gouv.fr/IMG/pdf/DNS-OARC-2013-Blocking_DNS_Messages_Is_Dangerous.pdf Je connais. Je ne suis pas d'accord. Et, de toute façon, ce n'est pas le cas que vous décrivez, il s'agit dans cet exposé d'un serveur faisant autorité, et décidant de ne pas répondre à tout (grâce à RRL). Dans ce document on parle effectivement de l'exploitation d'un serveur faisant l'autorite, mais pour empoisonner un resolveur. Le message general est qu'il ne faut pas bloquer les paquets. Et encore une fois l'empoisonnement du cache n'est qu'un exemple. Le declenchement automatique du bloquage d'une adresse spoofed (resolveur d'un ISP ...) bien choisie serait tres efficace comme acte de malveillance. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
On Fri, May 30, 2014, at 18:08, Dominique Rousseau wrote: Non, BCP38 (ie, pas laisser sortir du traf avec une ip source qui n'est pas de ton reseau) Tu as parfaitement raison, quand il s'agit de TON reseau (enfin, celui sur lequel tu as l'autorite). Par contre faut arreter de trop deconner avec le traffic d'un client autonome. Soit tu (toi, ton NOC, ton/tes stagiaire(s), ...) est capable d'appliquer un filtre custom en temps et en heure, soit tu te limites au strict minimum (RFC1918 co) soit tu laisse carement tomber (dans quel cas tu vas etre traite de mauvais). Et une fois le filtre custom applique, il ne revient pas a sa forme par default apres un week-end. ... alors sur un lien de peering, j'ai certainement mes meilleures activites que maintenir pour chaque peer des ACL 10 fois plus grandes que la liste de prefixes reelement annonces, en plus avec un risque de me faire de-peerer parce-que je fache un de ses clients. Le strict minimum ca suffit. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification
On Fri, May 30, 2014, at 18:01, Nicolas Strina wrote: Heuu filtrage RFC1918 ? Bogons ? C’est un peu la base à mon sens surtout Pour le RFC1918 (et consorts) oui, ok. Pour les bogons, hmmm. 128.0.0.0/16 anyone ? si tout ton staff sait que le bogons, ca se met a jour - ok, sinon - priere de s'abstenir. Après le filtrage côté client - Chez nous c’est DB RIPE toutes les nuits et filtering sur les objets route etc .. Donc en gros si rien - pas de routes. Si le client fait son travail - défiltrage etc .. Bref ça devrait exister partout. Filtrer les routes et filtrer le traffic en fonction de la source n'est pas le meme chose. Il y a des cas legitimes pour envoyer du trafic avec une source pour laquelle tu ne peux pas annoncer proprement une route. J'ai ete personellement tres content de pouvoir le faire pendant 2 ans en travaillant avec 6 transitaires differents (1 x petit, 1 x moyen et 4 x grands). Pour faire rapide: tu fais du content, tu as un ancien bloc PA alloue par un de tes anciens fournisseurs. Tu as sur ce bloc des services qui prennent un temps fou a faire changer d'IP : des VPN, des services dont tu controles pas le DNS voire carrement des services codes en dur chez tes partenaires (ou pire encore, clients). Tu est depuis devenu LIR, tu as un AS et ton propre PA, mais ni la volonte ni les moyens de maintenir 2 reseaux ou des configurations qui causent plus de problemes qe ce qu'ils resoudent. La migration va finir par se faire, mais un nombre reduit de services prennent un temps fou pour etre migres. Pendant ce temps, ca serait pas mal de reccuperer le trafic entrant pour ces services legacy sur le lien legacy (souvent a prix d'or, dont tout le monde attend l'expiration des 36 mois d'engagement), tout en sortant le trafic correspondant par l'endroit ou tout le traffic sort ... oups - c'est ton nouveau upstream qui droppe ton trafic s'il n'y a pas un objet route bien renseigne dans la RIPE DB :) --- Liste de diffusion du FRnOG http://www.frnog.org/