Service de Protection Avancé DDoS

Comme Cloudflare est utilisé comme un proxy pour tout le trafic de votre réseau, nous pouvons vous protéger de toutes sortes d’attaques de déni de service distribuées, dont:

Attaques de Layer 3/4

La plupart des attaques DDoS vise les couches de transport et réseau des systèmes de communication. Dans le modèle OSI, ce sont les couches 3 et 4.

Cette couche de “transport” (comme elle est parfois aussi nommée) de la pile réseau précise le protocole (par exemple TCP ou UDP) selon lequel deux hôtes sur un réseau communiquent l’un avec l’autre. Les attaques ciblées sur les couches 3 et 4 ont pour but d’inonder l’interface réseau d’une machine pour la surcharger, afin qu’elle ne puisse plus répondre au trafic légitime. Plus précisément, les attaques de ce type visent à saturer la capacité d’un commutateur réseau, ou surcharger la carte réseau d’un serveur ou la capacité de son processeur à gérer le trafic.

Les attaques de la couche 3 et 4 sont très dures, voire même impossibles, à atténuer avec des solutions traditionnelles. Si un assaillant peut envoyer sur un lien réseau plus de trafic que ce dernier ne peut gérer, aucun matériel supplémentaire ne peut l’aider ce réseau à contrer une telle attaque. Par exemple, si vous avez un routeur avec un port de 10 Gbit/s, et qu’un assaillant envoie sur votre trafic une attaque de 11 Gbit/s, aucun logiciel intelligent ou matériel ne peut vous permettre de contrer cette attaque si le lien réseau est complètement saturé.

Les plus grosses attaques de la couche 3/4 proviennent presque toujours de multiples sources. Ces nombreuses sources envoient des attaques sur un emplacement Internet unique, provoquant un raz-de-marée qui le submerge. C’est la raison pour laquelle on qualifie ces attaques de “distribuées”. Les sources de l’attaque du trafic peuvent être un groupe d’individus travaillant ensemble, un groupe d’ordinateurs ou de serveurs corrompus, des résolveurs DNS mal-configurés ou même des routeurs Internet avec des mots de passe faibles.

Comme les assaillants qui lancent une attaque de la couche 3/4 ne se préoccupent pas de recevoir une réponse aux requêtes qu’ils envoient, les paquets générés pour l’attaque n’ont pas à être corrects. Les attaquants vont régulièrement usurper des informations contenues dans les paquets de l’attaque, y compris l’adresse IP source, afin de laisser croire que l’attaque vient d’un nombre potentiellement infini de machines. Comme les données des paquets peuvent être complètement aléatoires, même des techniques telles que le filtrage IP en amont deviennent inutiles.

Avec Cloudflare, tout le trafic des attaques, qui autrement frapperait directement l’infrastructure de votre serveur, est directement acheminé vers nos datacenters via le réseau Anycast de Cloudflare. Une fois que le trafic des attaques est dévié, nous pouvons profiter de la capacité significative de notre réseau mondial et de nos nombreux serveurs pour absorber une quantité de trafic malveillant gigantesque en périphérie de notre réseau. Cela signifie que Cloudflare peut aussi protéger l’accès à un site d’une attaque traditionnelle de la couche 3/4.

Attaques en déni de service distribué par amplification DNS

Les attaques en déni de service distribué par amplification DNS (DRDos) sont en augmentation et sont devenues la plus grande source d’attaques DDoS des couches 3/4. Cloudflare bloque régulièrement des attaques supérieures à 100 Gbit/s et a récemment protégé un client d’une attaque supérieure à 300 Gbit/s. Cette attaque a été décrite par le New York Times comme “l’attaque DDoS publiquement annoncée la plus grosse de l’histoire d’Internet”.

Dans une attaque par amplification DNS, l’assaillant envoie une requête concernant une large zone DNS en prenant soin de maquiller l’adresse IP source de sa requête avec l’adresse IP de sa victime, et répète le processus auprès d’un grand nombre de résolveurs DNS. Les résolveurs répondent donc à la requête, envoyant la réponse (typiquement plus grande que la requête) à l’adresse IP de la victime. Comme les requêtes des attaquants ne représentent qu’une fraction de la taille des réponses, cela leur permet d’amplifier l’attaque au-delà des ressources en bande-passante qu’ils contrôlent.

Les attaques par amplification DNS par rebond sans Cloudflare

L’assaillant rassemble des ressources (typiquement, des robots ou des DNS récurseurs non-sécurisés), et les contacte en usurpant l’adresse IP de la cible. Ces ressources envoient ensuite un flot de réponses à la cible, qui est alors submergée et mise hors ligne.

Les attaques par amplification DNS par rebond avec Cloudflare

L’assaillant rassemble des ressources (typiquement, des robots ou des DNS récurseurs non-sécurisés), et les contacte en usurpant l’adresse IP de la cible. Ces ressources envoient ensuite un flot de réponses à la cible, mais celles-ci transitent par les datacenters de Cloudflare, qui les bloquent. Le trafic normal peut donc être acheminé correctement.

Deux conditions sont nécessaires pour effectuer une attaque par amplification: 1.) que la requête puisse être envoyée avec une adresse source usurpée (par exemple via les protocoles ICMP ou UDP qui ne nécessitent pas de “handshake”); 2.) que la réponse à la requête soit considérablement plus large que la requête elle-même. Le DNS est un service répandu qui répond à ces critères, et qui est donc devenu la plus grand vecteur d’attaques par amplification.

Les requêtes DNS sont généralement transmises via UDP, ce qui signifie, comme pour les requêtes ICMP utilisées dans une attaque SMURF (décrite ci-dessous), qu’elles sont de type "fire and forget". Ainsi, la source d’une requête DNS peut être falsifiée et le serveur n’a aucun moyen de déterminer son intégrité avant de répondre. Le DNS peut aussi générer une réponse bien plus volumineuse que la requête. Par exemple, vous pouvez envoyer la requête suivante, de petite taille (x.x.x.x étant l’adresse d’un résolveur DNS ouvert):

dig ANY isc.org @x.x.x.x +edns=0

Et recevoir l’énorme réponse ci-dessous:

; <<>> DiG 9.7.3 <<>> ANY isc.org @x.x.x.x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5147
;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 4, ADDITIONAL: 5
;; QUESTION SECTION:
;isc.org. IN ANY
;; ANSWER SECTION:
isc.org. 4084 IN SOA ns-int.isc.org. hostmaster.isc.org. 2012102700 7200 3600 24796800 3600
isc.org. 4084 IN A 149.20.64.42
isc.org. 4084 IN MX 10 mx.pao1.isc.org.
isc.org. 4084 IN MX 10 mx.ams1.isc.org.
isc.org. 4084 IN TXT "v=spf1 a mx ip4:204.152.184.0/21 ip4:149.20.0.0/16 ip6:2001:04F8::0/32 ip6:2001:500:60::65/128 ~all"
isc.org. 4084 IN TXT "$Id: isc.org,v 1.1724 2012-10-23 00:36:09 bind Exp $"
isc.org. 4084 IN AAAA 2001:4f8:0:2::d
isc.org. 4084 IN NAPTR 20 0 "S" "SIP+D2U" "" _sip._udp.isc.org.
isc.org. 484 IN NSEC _kerberos.isc.org. A NS SOA MX TXT AAAA NAPTR RRSIG NSEC DNSKEY SPF
isc.org. 4084 IN DNSKEY 256 3 5 BQEAAAAB2F1v2HWzCCE9vNsKfk0K8vd4EBwizNT9KO6WYXj0oxEL4eOJ aXbax/BzPFx+3qO8B8pu8E/JjkWH0oaYz4guUyTVmT5Eelg44Vb1kssy q8W27oQ+9qNiP8Jv6zdOj0uCB/N0fxfVL3371xbednFqoECfSFDZa6Hw jU1qzveSsW0=
isc.org. 4084 IN DNSKEY 257 3 5 BEAAAAOhHQDBrhQbtphgq2wQUpEQ5t4DtUHxoMVFu2hWLDMvoOMRXjGr hhCeFvAZih7yJHf8ZGfW6hd38hXG/xylYCO6Krpbdojwx8YMXLA5/kA+ u50WIL8ZR1R6KTbsYVMf/Qx5RiNbPClw+vT+U8eXEJmO20jIS1ULgqy3 47cBB1zMnnz/4LJpA0da9CbKj3A254T515sNIMcwsB8/2+2E63/zZrQz Bkj0BrN/9Bexjpiks3jRhZatEsXn3dTy47R09Uix5WcJt+xzqZ7+ysyL KOOedS39Z7SDmsn2eA0FKtQpwA6LXeG2w+jxmw3oA8lVUgEf/rzeC/bB yBNsO70aEFTd
isc.org. 4084 IN SPF "v=spf1 a mx ip4:204.152.184.0/21 ip4:149.20.0.0/16 ip6:2001:04F8::0/32 ip6:2001:500:60::65/128 ~all"
isc.org. 484 IN RRSIG NS 5 2 7200 20121125230752 20121026230752 4442 isc.org. oFeNy69Pn+/JnnltGPUZQnYzo1YGglMhS/SZKnlgyMbz+tT2r/2v+X1j AkUl9GRW9JAZU+x0oEj5oNAkRiQqK+D6DC+PGdM2/JHa0X41LnMIE2NX UHDAKMmbqk529fUy3MvA/ZwR9FXurcfYQ5fnpEEaawNS0bKxomw48dcp Aco=
isc.org. 484 IN RRSIG SOA 5 2 7200 20121125230752 20121026230752 4442 isc.org. S+DLHzE/8WQbnSl70geMYoKvGlIuKARVlxmssce+MX6DO/J1xdK9xGac XCuAhRpTMKElKq2dIhKp8vnS2e+JTZLrGl4q/bnrrmhQ9eBS7IFmrQ6s 0cKEEyuijumOPlKCCN9QX7ds4siiTIrEOGhCaamEgRJqVxqCsg1dBUrR hKk=
isc.org. 484 IN RRSIG MX 5 2 7200 20121125230752 20121026230752 4442 isc.org. VFqFWRPyulIT8VsIdXKMpMRJTYpdggoGgOjKJzKJs/6ZrxmbJtmAxgEu /rkwD6Q9JwsUCepNC74EYxzXFvDaNnKp/Qdmt2139h/xoZsw0JVA4Z+b zNQ3kNiDjdV6zl6ELtCVDqj3SiWDZhYB/CR9pNno1FAF2joIjYSwiwbS Lcw=
isc.org. 484 IN RRSIG TXT 5 2 7200 20121125230752 20121026230752 4442 isc.org. Ojj8YCZf3jYL9eO8w4Tl9HjWKP3CKXQRFed8s9xeh5TR3KI3tQTKsSeI JRQaCXkADiRwHt0j7VaJ3xUHa5LCkzetcVgJNPmhovVa1w87Hz4DU6q9 k9bbshvbYtxOF8xny/FCiR5c6NVeLmvvu4xeOqSwIpoo2zvIEfFP9deR UhA=
isc.org. 484 IN RRSIG AAAA 5 2 7200 20121125230752 20121026230752 4442 isc.org. hutAcro0NBMvKU/m+2lF8sgIYyIVWORTp/utIn8KsF1WOwwM2QMGa5C9 /rH/ZQBQgN46ZMmiEm4LxH6mtaKxMsBGZwgzUEdfsvVtr+fS5NUoA1rF wg92eBbInNdCvT0if8m1Sldx5/hSqKn8EAscKfg5BMQp5YDFsllsTauA 8Y4=
isc.org. 484 IN RRSIG NAPTR 5 2 7200 20121125230752 20121026230752 4442 isc.org. ZD14qEHR7jVXn5uJUn6XR9Lvt5Pa7YTEW94hNAn9Lm3Tlnkg11AeZiOU 3woQ1pg+esCQepKCiBlplPLcag3LHlQ19OdACrHGUzzM+rnHY50Rn/H4 XQTqUWHBF2Cs0CvfqRxLvAl5AY6P2bb/iUQ6hV8Go0OFvmMEkJOnxPPw 5i4=
isc.org. 484 IN RRSIG NSEC 5 2 3600 20121125230752 20121026230752 4442 isc.org. rY1hqZAryM045vv3bMY0wgJhxHJQofkXLeRLk20LaU1mVTyu7uair7jb MwDVCVhxF7gfRdgu8x7LPSvJKUl6sn731Y80CnGwszXBp6tVpgw6oOcr Pi0rsnzC6lIarXLwNBFmLZg2Aza6SSirzOPObnmK6PLQCdmaVAPrVJQs FHY=
isc.org. 484 IN RRSIG DNSKEY 5 2 7200 20121125230126 20121026230126 4442 isc.org. i0S2MFqvHB3wOhv2IPozE/IQABM/eDDCV2D7dJ3AuOwi1A3sbYQ29XUd BK82+mxxsET2U6hv64crpbGTNJP3OsMxNOAFA0QYphoMnt0jg3OYg+AC L2j92kx8ZdEhxKiE6pm+cFVBHLLLmXGKLDaVnffLv1GQIl5YrIyy4jiw h0A=
isc.org. 484 IN RRSIG DNSKEY 5 2 7200 20121125230126 20121026230126 12892 isc.org. j1kgWw+wFFw01E2z2kXq+biTG1rrnG1XoP17pIOToZHElgpy7F6kEgyj fN6e2C+gvXxOAABQ+qr76o+P+ZUHrLUEI0ewtC3v4HziMEl0Z2/NE0MH qAEdmEemezKn9O1EAOC7gZ4nU5psmuYlqxcCkUDbW0qhLd+u/8+d6L1S nlrD/vEi4R1SLl2bD5VBtaxczOz+2BEQLveUt/UusS1qhYcFjdCYbHqF JGQziTJv9ssbEDHT7COc05gG+A1Av5tNN5ag7QHWa0VE+Ux0nH7JUy0N ch1kVecPbXJVHRF97CEH5wCDEgcFKAyyhaXXh02fqBGfON8R5mIcgO/F DRdXjA==
isc.org. 484 IN RRSIG SPF 5 2 7200 20121125230752 20121026230752 4442 isc.org. IB/bo9HPjr6aZqPRkzf9bXyK8TpBFj3HNQloqhrguMSBfcMfmJqHxKyD ZoLKZkQk9kPeztau6hj2YnyBoTd0zIVJ5fVSqJPuNqxwm2h9HMs140r3 9HmbnkO7Fe+Lu5AD0s6+E9qayi3wOOwunBgUkkFsC8BjiiGrRKcY8GhC kak=
isc.org. 484 IN RRSIG A 5 2 7200 20121125230752 20121026230752 4442 isc.org. ViS+qg95DibkkZ5kbL8vCBpRUqI2/M9UwthPVCXl8ciglLftiMC9WUzq Ul3FBbri5CKD/YNXqyvjxyvmZfkQLDUmffjDB+ZGqBxSpG8j1fDwK6n1 hWbKf7QSe4LuJZyEgXFEkP16CmVyZCTITUh2TNDmRgsoxrvrOqOePWhp 8+E=
isc.org. 4084 IN NS ns.isc.afilias-nst.info.
isc.org. 4084 IN NS ams.sns-pb.isc.org.
isc.org. 4084 IN NS ord.sns-pb.isc.org.
isc.org. 4084 IN NS sfba.sns-pb.isc.org.
;; AUTHORITY SECTION:
isc.org. 4084 IN NS ns.isc.afilias-nst.info.
isc.org. 4084 IN NS ams.sns-pb.isc.org.
isc.org. 4084 IN NS ord.sns-pb.isc.org.
isc.org. 4084 IN NS sfba.sns-pb.isc.org.
;; ADDITIONAL SECTION:
mx.ams1.isc.org. 484 IN A 199.6.1.65
mx.ams1.isc.org. 484 IN AAAA 2001:500:60::65
mx.pao1.isc.org. 484 IN A 149.20.64.53
mx.pao1.isc.org. 484 IN AAAA 2001:4f8:0:2::2b
_sip._udp.isc.org. 4084 IN SRV 0 1 5060 asterisk.isc.org.
;; Query time: 176 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Tue Oct 30 01:14:32 2012
;; MSG SIZE rcvd: 3223

Cette requête de 64 Bits a donné lieu à une réponse de 3223 Bits. En d’autres termes, un assaillant est capable d’amplifier 50 fois n’importe quelle requête qu’il peut envoyer via un résolveur DNS ouvert.

Le réseau Anycast de Cloudflare a été spécialement développé pour arrêter les attaques massives de la couche 3/4. En utilisant Anycast, nous sommes en mesure d'annoncer les mêmes adresses IP de chacun de nos 151 datacenters à travers le monde. Le réseau lui-même répartit les requêtes en les envoyant au point le plus proche. Dans des circonstances normales, cela nous permet de faire en sorte que les visiteurs de votre site soient automatiquement envoyés vers le datacenter de notre réseau le plus proche, afin de garantir la meilleure performance. En cas d’attaque, Anycast s’occupe de disperser et diluer efficacement le trafic sur notre réseau de datacenters dans le monde entier. Comme chaque centre de données annonce la même adresse IP pour tous les clients Cloudflare, le trafic ne peut pas être dirigé en un seul point. Au lieu d’une attaque de plusieurs sources vers une seule cible (“many-to-one”), l’attaque est désormais dirigée sur plusieurs cibles (“many-to-many”), et dans ce schéma il n’y a plus de point de rupture unique sur le réseau.

Attaques par réflexion (SMURF)

Une des premières attaques par amplification était une attaque par réflexion. Dans une attaque par réflexion, l’assaillant envoie des requêtes ICMP (par exemple, des requêtes ping) à une adresse dite “broadcast” (par exemple, X.X.X.255) annoncée par un routeur configuré pour relayer les requêtes ICMP à toutes les machines auxquelles il est connecté. Ensuite, la machine attaquante falsifie l'adresse IP source, la remplaçant par l'adresse IP d'une machine cible. Comme les requêtes ICMP ne nécessitent pas de poignée de main (“handshake”), le destinataire n’a aucun moyen de vérifier si l’IP source est légitime. Le routeur reçoit la requête sur son adresse broadcast et la diffuse sur l’ensemble du réseau. Toutes les machines du réseau répondent à la requête. L’assaillant peut donc amplifier l’attaque par le nombre de machines connectées au routeur (par exemple, si vous avez 5 appareils derrière le routeur, alors l’assaillant peut multiplier l’attaque par 5, voir le diagramme ci-dessous).

Les attaques par réflexion appartiennent majoritairement au passé. Pour la plupart, les opérateurs réseaux ont configuré leurs routeurs afin de désactiver la transmission des requêtes ICMP envoyées depuis une adresse broadcast.

Attaque ACK

Pour comprendre comment fonctionne une attaque ACK, il faut se plonger dans le monde du protocole TCP. Quand une connexion TCP est établie, il y a une poignée de main (ou “handshake”). Le serveur à l’origine de la session TCP envoie d’abord une requête SYN (pour synchroniser) au serveur destinataire. Celui-ci répond par un paquet ACK (“acknowledgement”, ou accord). Après cette poignée de main, les données peuvent être échangées. Dans une attaque ACK par réflexion, l’assaillant envoie un grand nombre de paquets SYN avec une adresse IP source falsifiée, pointant vers la victime. Le serveur répond ensuite à l’adresse IP de la victime, avec un paquet ACK, créant l’attaque.

Comme dans les attaques DNS par réflexion, les attaques ACK masquent la source de l’attaque, la faisant apparaître comme provenant de serveurs légitimes. Toutefois, contrairement à une attaque par réflexion DNS, il n’y a pas de facteurs amplificateur: la bande passante depuis les paquets ACK est la même que la bande passante que l’attaquant a utilisé pour générer les paquets SYN. Le réseau Cloudflare est configuré pour ignorer les paquets ACK qui ne correspondent à aucun paquet SYN, ce qui annihile ce type d’attaque.

Attaques de la couche applicative

Une nouvelle sorte d’attaque vise la 7ème couche du modèle OSI, la couche applicative. Ces attaques se concentrent sur les caractéristiques spécifiques des applications Web, créant des engorgements. Par exemple, l’attaque dite Slow Read envoie des paquets lentement par des connexions multiples. Comme Apache crée un nouveau thread pour chaque connexion et que les connexions restent ouvertes tant que des données sont envoyées, un assaillant peut submerger un serveur Web en épuisant sa capacité de traitement.

Cloudflare offre des protections contre chacune de ces attaques et en pratique nous réduisons généralement les attaques HTTP de 90%. Pour la plupart des attaques et pour la plupart de nos clients, cela suffit à les garder en ligne. Toutefois, les 10% du trafic qui échappent aux protections traditionnelles peuvent suffire à submerger le serveur web dans le cas d’une attaque de grande ampleur, ou dans le cas d’un clients dont les ressources sont limitées. Dans ce cas, Cloudflare offre une fonction de sécurité appelé le mode ”Je Suis Attaqué” (I’m Under Attack – IUAM).

Le mode IUAM est un niveau de sécurité que vous pouvez mettre en place sur votre site quand vous êtes attaqués. Quand le mode IUAM est actif, Cloudflare ajoutera une couche supplémentaire de protection pour éviter au trafic HTTP malveillant d’être transmis à votre serveur. Pendant qu’un certain nombre de vérifications sont faites en arrière-plan, une page intermédiaire est présentée aux visiteurs de votre site pendant 5 secondes durant lesquelles les vérifications sont effectuées. Voyez cela comme une simulation où les tests sont automatiques et où les visiteurs n’auront jamais à remplir de CAPTCHA.

Après avoir été certifiés comme légitimes par des tests automatiques, les visiteurs peuvent consulter votre site sans problème. Javascript et les cookies sont nécessaires pour passer ces tests, ainsi que pour en mémoriser le résultat d’une page à l’autre. La page que vos visiteurs verront en cas d’activation du mode IUAM peut être personnalisée pour respecter l’apparence de votre site. Le mode IUAM ne bloque pas les moteurs de recherche ou les adresses explicitement autorisées dans votre compte Cloudflare.