En ce qui concerne la mitigation d'attaque - tu n'es pas obligé de me croire sur parole (encore heureux) - mais je t'invite à lire les docs que j'ai linké chez CloudFlare qui sont raisonnablement accessibles (Oui parce que les docs sur les systèmes de cryptographie ça devient vite pénible pour le non initié).
Encore une fois, la doc de CloudFlare n’est pas de la mitigation d’attaque, mais de la diminution d’amplification d’attaque.
Ce n’est pas CloudFlare qui est visé directement par le DDOS, mais CloudFlare qui génère le DDOS.
Un attaquant Y souhaitant massacrer un serveur X va envoyer des tonnes de requêtes DNS (via UDP donc) avec un spoof de l’IP source en X.
Si le domaine est signé par DNSSec, alors la requête DNS faite par l’attaquant à un serveur DNSSec de CloudFlare est très courte (par exemple pour le NSEC3 q0da90gqv16l28ro6i5s6ce4ogqe0cp4.imirhil.fr, la question est Type50? q0da90gqv16l28ro6i5s6ce4ogqe0cp4.imirhil.fr. (72) = 58 octets) mais la réponse est TRÈS longue (je vous passe les détails, mais elle fait 1074 octets).
L’IP source étant spoofée (merci UDP), cette réponse ne va pas retournée chez l’attaquant, mais chez l’attaqué !
Du coup, on a un traffic de 58Mbps entre l’attaquant et CloudFlare (une simple ligne fibre classique suffit), mais un trafic entre CloudFlare et l’attaqué de 1.074Gbps (facteur d’amplification de 18) !
Si en plus l’attaquant a le bon goût de contrôler un petit botnet d’une centaine de machines, c’est ×ばつ50Mbps = 5Gbps de traffic qui se transforme en ×ばつ1Gbps = 100Gbps chez l’attaqué... Rideau...
Là je n’ai que ×ばつ18 d’amplification, mais on peut monter à ×ばつ4000 sans soucis avec les bonnes requêtes DNS qui vont bien et des serveurs résolveurs mal configurés (genre avec le AXFR actif, qui vont transformer « AXFR? imirhil.fr » (17 octets) en le dump intégral de ma zone DNSSec (69885 octets, soit amplification ×ばつ4110)) .
Si en plus CloudFlare a le bon goût d’avoir voulu protégé ses propres clients d’un listing de domaine via DNSSec, ce qui impose de resigner à la volée les zones, alors CloudFlare va aussi s’écrouler, puisque les millions de requêtes DNSSec qui vont lui être faites vont littéralement lui faire exploser tous ses CPU, et se faire DDOS par elle-même.
De simple vecteurs d’attaque, CloudFlare devient une victime collatérale du DDOS.
La position de CloudFlare est donc la suivante : si ECDSA était utilisé dans DNSSec, ça diminuerait déjà de beaucoup les amplifications DNS possibles (une signature ECDSA est beaucoup plus courte que RSA), mais en plus si CloudFlare était quand même vecteur malencontreux d’un DDOS, elle ne se DDOSerait pas elle-même à coup de CPU-burn (ECDSA beaucoup plus léger en calcul que RSA).
Ce que CloudFlare dénonce, c’est donc valable pour tout les serveurs DNSSec faisant autorité qui peuvent se retrouver par mégarde vecteur d’amplification d’un DDOS, et tomber eux-même s’ils ont activé les protections contre le domaine listing.
CloudFlare n’est pas plus sécurisé que les autres, puisque ECDSA n’est actuellement pas déployable dans DNSSec, c’est d’ailleurs ce qu’ils aimeraient voir adopter bien plus vite que ce qui n’est actuellement le cas.
[^] # Re: Juste pour compléter la liste
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 1.
Encore une fois, la doc de CloudFlare n’est pas de la mitigation d’attaque, mais de la diminution d’amplification d’attaque.
Ce n’est pas CloudFlare qui est visé directement par le DDOS, mais CloudFlare qui génère le DDOS.
Un attaquant Y souhaitant massacrer un serveur X va envoyer des tonnes de requêtes DNS (via UDP donc) avec un spoof de l’IP source en X.
Si le domaine est signé par DNSSec, alors la requête DNS faite par l’attaquant à un serveur DNSSec de CloudFlare est très courte (par exemple pour le NSEC3 q0da90gqv16l28ro6i5s6ce4ogqe0cp4.imirhil.fr, la question est
Type50? q0da90gqv16l28ro6i5s6ce4ogqe0cp4.imirhil.fr. (72)= 58 octets) mais la réponse est TRÈS longue (je vous passe les détails, mais elle fait 1074 octets).L’IP source étant spoofée (merci UDP), cette réponse ne va pas retournée chez l’attaquant, mais chez l’attaqué !
Du coup, on a un traffic de 58Mbps entre l’attaquant et CloudFlare (une simple ligne fibre classique suffit), mais un trafic entre CloudFlare et l’attaqué de 1.074Gbps (facteur d’amplification de 18) !
Si en plus l’attaquant a le bon goût de contrôler un petit botnet d’une centaine de machines, c’est ×ばつ50Mbps = 5Gbps de traffic qui se transforme en ×ばつ1Gbps = 100Gbps chez l’attaqué... Rideau...
Là je n’ai que ×ばつ18 d’amplification, mais on peut monter à ×ばつ4000 sans soucis avec les bonnes requêtes DNS qui vont bien et des serveurs résolveurs mal configurés (genre avec le AXFR actif, qui vont transformer « AXFR? imirhil.fr » (17 octets) en le dump intégral de ma zone DNSSec (69885 octets, soit amplification ×ばつ4110)) .
Si en plus CloudFlare a le bon goût d’avoir voulu protégé ses propres clients d’un listing de domaine via DNSSec, ce qui impose de resigner à la volée les zones, alors CloudFlare va aussi s’écrouler, puisque les millions de requêtes DNSSec qui vont lui être faites vont littéralement lui faire exploser tous ses CPU, et se faire DDOS par elle-même.
De simple vecteurs d’attaque, CloudFlare devient une victime collatérale du DDOS.
La position de CloudFlare est donc la suivante : si ECDSA était utilisé dans DNSSec, ça diminuerait déjà de beaucoup les amplifications DNS possibles (une signature ECDSA est beaucoup plus courte que RSA), mais en plus si CloudFlare était quand même vecteur malencontreux d’un DDOS, elle ne se DDOSerait pas elle-même à coup de CPU-burn (ECDSA beaucoup plus léger en calcul que RSA).
Ce que CloudFlare dénonce, c’est donc valable pour tout les serveurs DNSSec faisant autorité qui peuvent se retrouver par mégarde vecteur d’amplification d’un DDOS, et tomber eux-même s’ils ont activé les protections contre le domaine listing.
CloudFlare n’est pas plus sécurisé que les autres, puisque ECDSA n’est actuellement pas déployable dans DNSSec, c’est d’ailleurs ce qu’ils aimeraient voir adopter bien plus vite que ce qui n’est actuellement le cas.