Les attaques DDOS ou les robots automatisés qui cherchent à «voler» des informations sur de sites (sans avoir l’intention de provoquer un DDOS, bien qu’ils puissent le faire) ont toujours été un problème depuis que le WWW existe, mais ces dernières années, ils ont pris une importance considérable. Les fournisseurs de services proxy disposant de millions d’ips à des prix très compétitifs signifient que n’importe qui, sans être un «hacker» disposant d’un nombre infini d’ordinateurs compromis, peut bénéficier d’une pool d’ips important et peut poser un réel problème à n’importe quel serveur web.
Dans le cadre de l’un des projets auxquels je participe, j’ai dû développer un robot capable de scraper Google Shopping, Amazon et des centaines d’autres sites e-commerce. De même, en tant qu’administrateur système pour d’autres clients, j’ai dû faire face à la question de savoir comment mettre fin aux crawls et aux attaques DDOS. Je connais donc les deux côtés et les défis à relever dans chaque cas. Et c’est vraiment amusant, le jeu du chat et de la souris.
Il existe d’innombrables mesures, depuis les honeypots, les défis javascript, la limitation des requêtes par ip ou plage d’ip, le blocage des listes noires d’ip, l’analyse du trafic et le blocage sélectif par type, la logique de blocage par comportement dans l’application, les cookies secrets et une infinité d’autres mesures avec lesquelles les deux acteurs du jeu devront composer et, évidemment, tout cela augmente le coût de la maintenance du site, ses ressources et les ressources et le temps nécessaires à l’attaquant.
De manière générale, Je préfère toujours la mise en œuvre de tous les services et outils de manière autonome, à partir de mon propre serveur et sans dépendre de tiers. Mais dans ce cas, étant donné l’ampleur du problème et le besoin éventuel de ressources importantes, il est intéressant d’utiliser des entreprises spécialisées dans cette tâche comme CloudFlare ou Sucuri, la première étant plus spécialisée dans la protection DDOS et l’optimisation des réseaux et la seconde dans la protection WAF, les deux finissant par converger dans leurs services, mais cela ferait l’objet d’un autre post. Dans ce post, nous allons nous concentrer sur l’utilisation de CloudFlare (ci-après CF) et de sa protection contre les DDOS.
Parmi les nombreuses fonctionnalités intéressantes de CF figure le degré de sécurité et de protection du site, qui va de nul, faible à «I’m under attack!» Cette dernière est très efficace en utilisant un défi javascript avec des cookies sans interaction de l’utilisateur, je sais que je pourrais le faire moi-même sur mon serveur mais les programmeurs de bots savent comment étudier même les défis javascript et les contourner avec ce qui serait un travail sans fin, donc pour le prix de CF (même la version gratuite comprend cette fonctionnalité) c’est payant et ils prennent soin avec leur grande infrastructure et leurs ressources de rendre la tâche de contourner les mesures très difficile pour les bots.
Malheureusement (rappelez-vous le jeu du chat et de la souris), le moyen le plus simple d’éviter cette protection ainsi que les multiples mesures de sécurité mises en œuvre par CF est de la contourner. Et c’est généralement assez simple, il existe plusieurs méthodes pour trouver l’adresse IP réelle où le serveur web original est hébergé sans protection CF et une fois que vous avez l’adresse IP, vous pouvez configurer les robots pour qu’ils l’utilisent directement en ignorant les adresses IP proxy offertes par le DNS CF. Dans un monde idéal, vous pourriez chercher des moyens de rendre la découverte de la véritable ip très difficile, mais cela nécessiterait un effort et une prudence continus de la part de toute l’équipe, à la fois des systèmes et du développement, et ces derniers accordent généralement peu d’attention aux problèmes d’ips, de procolos et de sécurité. Dans la mesure du possible, en tant qu’administrateurs système, il est donc intéressant de disposer de méthodes permettant de remédier à la possibilité qu’un attaquant connaisse la véritable ip.
Récemment, CF a annoncé la possibilité de modifier et d’ajouter des en-têtes spécifiques à la requête envoyée par ses proxies à notre serveur. Avant, c’était possible, mais il fallait programmer les workers de CF, maintenant c’est beaucoup plus facile (https://blog.cloudflare.com/transform-http-request-headers/). Ce simple outil ouvre un large éventail de possibilités.
La façon la plus simple d’éviter l’accès direct au serveur web serait de bloquer au niveau de firewall toute ip qui veut accéder aux ports 80 et 443 qui ne sont pas dans le pool des ips CF (https://www.cloudflare.com/ips/). Le problème avec cette solution est que si vous avez plusieurs domaines hébergés sur le même serveur/ip et que tous les domaines ne sont pas protégés par CF, vous ne pouvez pas bloquer par ip. De plus, bien que la plage d’adresses IP de CF ne change pas très souvent, cela vous oblige à garder un œil sur toute mise à jour de son plage d’adresses IP afin de l’adapter aux règles de votre pare-feu.
Nous avons donc besoin d’une méthode plus facile à maintenir et utile pour un système plus complexe. C’est là que les headers CF personnalisés entrent en jeu. L’idée est simple, créer un header avec une valeur clé et vérifier sur le serveur si cet header a été envoyé dans la requête, si le header n’a pas été envoyé alors nous pouvons être sûrs que la connexion est directe sans passer par CF. En principe, le header serait très difficile à trouver, il n’est connu que de celui qui l’a configuré, du serveur web et de CF. Pour trouver le header caché, il serait nécessaire de pirater le serveur web et d’exécuter un script qui montrerait les headers envoyés dans la requête par CF, ce qui est possible, mais même dans ce cas, l’attaquant devrait savoir ce qu’il cherche et quelle méthode le serveur utilise pour refuser les requêtes direct. La méthode n’est pas parfaite ? bien sûr, mais c’est une partie de plus du jeu du chat et de la souris. La protection contre les DDOS va beaucoup plus loin que cela, mais l’objectif de ce post n’est pas de donner une analyse complète de toutes les techniques possibles.
Comme exemple concret je détaille comment appliquer le filtre header sur le serveur nginx, au passage on peut en profiter pour ajouter d’autres vérifications header comme la géolocalisation CF (free pro geolocation).
Pour vérifier le header caché, il suffit d’ajouter dans la section «server» de nginx ce qui suit (évidemment avant il fallait créer le header dans CF comme expliqué dans le lien que je vous ai laissé) :
if ($http_customheader != 'TOKENSECRETO') { return 511 ; }
Et comme ça, toute demande directe qui arrive au serveur sans spécifier le customheader avec la valeur TOKENSECRETO recevra une belle erreur 511. Comme valeur de retour, vous pouvez choisir celle que vous voulez en suivant des critères logiques (ne pensez même pas à faire un retour 200). Dans ce cas, j’ai utilisé 511 (Network Authentication Required) afin d’avoir un enregistrement dans les journaux des tentatives d’accès direct qui ont été faites à des fins d’information (toujours garder un œil sur les journaux).
Un autre contrôle intéressant serait le contrôle d’accès par pays. L’un de mes clients subissait un nombre infini d’attaques en provenance de pratiquement tous les pays du monde (cela fait partie du jeu des DDOS), mais son marché potentiel n’était constitué que de quelques pays. Grâce à l’en-tête de géolocalisation de CF et au blocage de l’accès direct, tout est facile :
Nous ajoutons dans le bloc http de nginx :
map $http_cf_ipcountry $countryok {
default "0" ;
"FR" "1" ;
"ES" "1" ;
"DE" "1" ;
"BE" "1" ;
"US" "1" ;
}
Nous ajoutons dans le bloc du serveur nginx :
if ($countryok != '1') { return 511 ; }
Comme vous pouvez le voir, j’utilise l’en-tête cf_ipcountry pour obtenir le code ISO du pays et vérifier s’il figure dans la liste des pays autorisés.
Les possibilités sont infinies, il suffit de faire preuve d’imagination.
J’espère que ces informations vous seront utiles. Si vous avez besoin de conseils techniques sur la mise en œuvre d’une protection DDOS, je peux vous offrir mes années d’expérience dans ce domaine.