Attaques DDOS et extorsion de paiements en Bitcoin ? Comment vous protéger avec CloudFlare

Au cours des deux dernières semaines, certains de nos clients ont également été ciblés par ce qui semble être une tendance destinée à se répandre de plus en plus, Attaques DDOS suivre demandes de rançon en Bitcoin pour mettre fin à l'attaque.

Ce qui semblait être un cas sporadique en fait qui a d'abord frappé le site d'un de nos clients, dans les jours suivants s'est avéré être une récurrence, ayant en fait dû faire face à 5 tentatives d'attaque DDOS Layer 7 et autant de demandes d'extorsion et de paiements en Bitcoin.

En effet, en nous comparant à nos clients Webmasters et autres hébergeurs, nous avons pu constater que la tendance de ces attaquants est en forte hausse, ayant eu la confirmation du même modus operandi avec même le même montant à payer si vous vouliez arrêter le attaque, ou 250 € en Bitcoin.

Vous pouvez trouver sur la photo ci-dessous l'e-mail menaçant avec la demande de rançon :

Comme on peut le voir sur l'adresse du portefeuille Bitcoin, c'est le même hacker qui a attaqué un autre site d'un de nos clients en essayant de extorquer le même montant et même se plaindre que le gestionnaire (c'est-à-dire nous) limitait l'attaque en excluant certains pays attaquants où l'attaquant avait vraisemblablement de grands botnets et était capable de générer un nombre très élevé de requêtes GET et POST sur le site de notre client, provoquant une panne qui dans la terminologie technique s'appelle Denial Of Service ou plus simplement DOS.

salut,
Je remarque actuellement que votre responsable continue de m'obstruer en essayant de bloquer les demandes entrantes d'autres pays. Actuellement, seule l'Italie a accès à votre site Web. Ce qui est assez ennuyeux pour vous, car selon certaines de mes recherches, votre public n'embrasse pas que les Italiens : en fait, 20% des visiteurs de votre site ne sont PAS d'Italie.
Ce que je recommande c'est de montrer cet e-mail à votre manager et de lui faire comprendre que je peux très bien "jouer" avec ses mauvaises protections (geoblock, ipban, recaptcha, jschallenge).

Pour le reste je souhaite un bon travail PAS comme toujours, et j'attends ma somme de 250€ dans mon wallet BITCOIN à :

1HHFxKeVk35FCnd36bV7LYyk3CNT6avFRT

J'ai besoin d'une réponse dans les 24 heures

PS : Cloudflare est inutile pour déguiser l'IP du serveur : (78.47.XX)
Je peux facilement trouver le backend. Mais je n'en ai pas encore besoin. Je m'en tiens juste au frontend. Bonne chance!

Le message nous a été envoyé directement par l'un de nos clients Webmaster via Whatsapp comme vous pouvez le voir sur l'écran suivant :

Quelques hypothèses sur l'identité de l'agresseur.

Les deux messages, le premier et le second, semblent être écrits dans un italien parfait, on peut donc supposer que l'attaquant est italien ou au moins de langue maternelle italienne. Ce n'est évidemment pas certain mais il est raisonnable et pacifique de le penser.

Sûrement le fait qu'il demande explicitement un paiement en mentionnant les euros plutôt que les dollars nous fait penser encore plus que nous sommes face à un attaquant européen presque certainement italien.

Le montant requis, bien qu'il puisse sembler faible, est un coût intelligemment pondéré, ni trop élevé pour être ignoré, ni trop faible par rapport au coût d'atténuation d'un DDOS. Il s'agit probablement d'une extorsion bien pondérée qui pourrait inviter l'attaquant à payer la somme indiquée afin de voir cesser l'attaque DDOS et remettre le site en ligne.

Le type d'attaque.

L'attaque lancée est une attaque Layer7 (au niveau applicatif donc) se concentrant sur l'inondation de requêtes GET et POST vers le site victime.

Les IP sources avaient une géolocalisation mondiale avec des pays internationaux et européens, dont l'Italie. L'attaque concernait de nombreux fournisseurs de consommateurs ADSL, il est donc supposé que le prétendu botnet n'était en réalité rien de plus qu'une redirection de navigateur légitime d'utilisateurs réels.

En effet, n'étant pas des requêtes simples et triviales de type GET et POST implémentées par les toolkits "habituels" des hackers du dimanche, ils ont su s'affranchir du mode challenge du mode « SOUS ATTAQUE » par CloudFlare, notre précieux partenaire dans l'atténuation DDOS.

Cela signifie essentiellement que le client qui fait des demandes au CloudFlare ont pu exécuter du code Javascript, étant donné que la technologie de validation du navigateur de CloudFlare prévoit un défi (une résolution d'un problème mathématique) via l'interpréteur Javascript dont tous les navigateurs sont fournis mais très peu ou pas d'outils pour effectuer l'inondation de requêtes GET ou POST .

De nombreuses demandes provenaient de référents tels que reddit.com, baidu.com, yahoo.com et similaire, comme vous pouvez le voir dans cet écran suivant en allant filtrer directement dans le log du serveur web NGINX access.log

Ne cédez pas au chantage et ne payez jamais la rançon.

Même si une baisse peut être préoccupante du fait de la perte de revenus même à court terme (pensez juste au manque de monétisation des annonces publicitaires, des bannières ou de simples ventes perdues) et de la somme à payer, somme toute économique, nous doit toujours se rappeler que céder au chantage signifie être désormais disponible pour être des « distributeurs automatiques » personnels pour l'attaquant.

Si vous payez une fois, préparez-vous à en payer une seconde, puis une troisième et ainsi de suite. Vous paierez toujours, car vous l'avez déjà fait une fois et vous serez considéré comme psychologiquement faible et toujours enclin à payer et à subir du chantage.

Vous ne devez jamais payer ou céder au chantage, mais contactez plutôt du personnel compétent et qualifié comme nous pour résoudre le problème une fois pour toutes.

Dans ces cas, la règle est simple : ne saignez jamais devant les requins.

Qu'est-ce que CloudFlare ?

CloudFlare est proxy inverse avec fonctions CDN (Content Delivery Network). En pratique, c'est un serveur qui s'interpose entre le serveur où est hébergé votre site et les visiteurs, effectuant également fonctions de mise en cache, accélérant encore les performances de votre site. Il ne se limite pas à la distribution de contenu statique (comme un CDN normal), mais offre de nombreuses fonctionnalités pour augmenter la sécurité, optimiser un site, accélérer le DNS et se protéger contre les attaques DDOS.

Lorsqu'une demande arrive d'un utilisateur, CloudFlare (en un minimum de temps), vérifiez d'abord si le visiteur est digne de confiance, et si c'est le cas, après avoir pris les contenus statiques (images, css, javascript) du cache, il les renvoie au visiteur lui-même.

Laissant de côté la fonctionnalité du CDN et l'optimisation de la diffusion de contenu via la minification, les conversions d'images Webp et bien plus encore, dans cet article, nous nous concentrerons sur l'utilisation de CloudFlare afin d'atténuer une attaque DDOS.

Comment atténuer un DDOS Layer7 via CloudFlare ?

La première chose à comprendre à propos des attaques de niveau 7 est qu'elles nécessitent une meilleure compréhension du site Web et de son fonctionnement. L'attaquant doit faire ses devoirs et créer une attaque spécialement conçue pour atteindre son objectif. Pour cette raison, ces types d'attaques DDoS nécessitent moins de bande passante pour arrêter le site et sont plus difficiles à détecter et à bloquer.

La meilleure façon d'arrêter un DDOS Layer7 est d'utiliser un service de sécurité comme CloudFlare celui qui fonctionne en reverse proxy, nous offre quelques fonctionnalités importantes pour filtrer le trafic en amont.

En d'autres termes, comme vous pouvez le voir sur l'image ci-dessus, lorsque l'attaquant essaie de contacter notre site (ou son trafic malveillant), il devra passer par CloudFlare qui nous permet via une interface Web agréable et pratique de mettre en place des règles pour filtrer le trafic malveillant et ainsi le bloquer renvoyer les codes d'erreur 500 et éviter que des requêtes aléatoires ou paramétriques puissent littéralement faire planter notre serveur Web, notre interpréteur PHP ou notre base de données jusqu'à ce qu'il se bloque.

Pour ce faire, vous pouvez compter en toute sécurité sur CloudFlare qui également dans la version gratuite (donc gratuite) vous permet d'avoir tous les outils dont vous avez besoin pour faire un filtrage intelligent sur différents facteurs.

Par la suite, une fois le plan gratuit confirmé, le système intelligent d'analyse des enregistrements DNS reproduira la ZONE DNS actuelle de notre serveur de noms faisant autorité pour le domaine en question (dans ce cas, par exemple pippo.it) afin de trouver tous les enregistrements de la ZONE sur les serveurs de noms CloudFlare.

NOTE IMPORTANTE : Attention, le système intelligent de CloudFlare bien que très avancé il est souvent incapable de localiser les enregistrements « cachés » tels que les domaines de troisième niveau et autres et donc c'est toujours votre tâche et votre soin de vous assurer que toutes les entrées utiles de la ZONE DNS actuelle sont également signalées sur la nouvelle ZONE des serveurs de noms CloudFlare, en prenant soin d'ajouter tous les enregistrements introuvables.

Vous serez confronté à une liste d'enregistrements de ce type qui reflète (ou du moins devrait) votre ZONE DNS actuelle.

La bulle orange qui peut être activée ou désactivée d'un simple clic de souris signifie si pour le type d'enregistrement en question CloudFlare doit accorder un accès direct à l'IP du site réel, réalisant ainsi une fonction de serveur de noms très normale, ou si le trafic doit passer par CloudFlare et donc fonctionner en mode Reverse Proxy.

Dans le mode de Reverse Proxy, le navigateur d'un éventuel visiteur contactera l'IP du serveur CloudFlare et selon certaines règles que nous verrons plus tard CloudFlare aura le droit de contacter le site du client ou de refuser la connexion avec un code d'erreur.

Il est donc raisonnable si le serveur Web est attaqué via des requêtes GET ou POST, de filtrer tous les enregistrements qui renvoient au serveur Web lui-même, comme on peut le voir ci-dessous le nom de domaine nu sans www, celui avec www et le ftp relatif conscient que très souvent, l'adresse FTP correspond à celle du serveur Web et en laissant l'IP FTP visible, l'attaquant pourrait retracer l'IP d'origine de la machine qui se trouve actuellement derrière CloudFlare.

La configuration ressemblerait donc à ceci :

Par la suite, en avançant dans la configuration et en cliquant sur continuer, CloudFlare invitera l'utilisateur à changer les serveurs de noms actuels du REGISTRAIRE actuel par ceux fournis par CloudFlare lui-même.

Dans l'image ci-dessus, par exemple, CloudFlare m'invite à remplacer les serveurs de noms faisant autorité actuels alicom.com par les deux de cloudflare.com précédés d'un nom souvent unique pour chaque compte d'utilisateur individuel.

Pour faire ça vous devez normalement avoir accès au panneau de contrôle de votre fournisseur où vous avez enregistré le domaine et choisir de remplacer les serveurs de noms d'origine par ces nouveaux, ce n'est qu'une fois que les nouveaux serveurs de noms CloudFlare se sont propagés dans le monde que vous pouvez être sûr que le trafic web transite par les systèmes CloudFlare et n'arrive pas directement sur votre site sans aucun intermédiaire capable de vous protéger et de filtrer le trafic malveillant.

NOTE IMPORTANTE : Changer les serveurs de noms bien que ce soit une opération extrêmement simple, ce n'est pas une opération immédiate. Changer un serveur de noms dans de nombreuses configurations cela peut prendre des heures voire des jours. Pour cette raison, il serait judicieux si vous vous souciez de votre site Web de remplacer immédiatement les serveurs de noms de votre fournisseur par ceux de CloudFlare, en obtenant, entre autres, une vitesse de réponse beaucoup plus élevée aux requêtes DNS et en ayant la possibilité d'être immédiatement prêt à activer le filtrage fonctionne en cas d'attaque, sans avoir à attendre la propagation du nouveau DNS et en évitant toute la procédure indiquée jusqu'à présent.

Un site Web producteur de richesse ne devrait utiliser que les serveurs de noms de CloudFlare comme serveurs de noms.

 

Utilisation de CloudFlare.

Filtrer une attaque DDOS en général, et en particulier une attaque Layer7 sur un site web, c'est tout d'abord avoir une bonne capacité à analyser l'attaque afin de comprendre de quoi filtrer à travers CloudFlare uniquement le trafic malveillant, ne laissant passer que le sain.

L'une des principales raisons de l'échec de l'atténuation DDOS consiste à adopter le bon outil (CloudFlare) mais simplement à activer le mode Sous Attaque pensant qu'en cliquant sur le bouton "Je suis attaqué", CloudFlare pourra vous protéger en faisant tout par lui-même. Rien de plus faux.

Le mode under attack est en fait un système qui pense de manière assez grossière, pensant que si de nombreuses requêtes GET ou POST arrivent sur le site Web, ces requêtes proviennent probablement d'outils d'attaque installés sur divers botnets qui prétendent être un navigateur Web mais sont pas réellement un navigateur Web.

Il s'attend à ce qu'un client soit capable de communiquer sur le protocole TCP / IP, d'effectuer une poignée de main via le protocole SSL ou TLS pour établir une communication HTTPS, puis de continuer à inonder la cible victime de requêtes.

Ce que ces boîtes à outils d'attaque n'ont normalement pas, c'est un interpréteur Javascript et donc proposer un CHALLENGE (une sorte de question) en Javascript à un client qui n'a pas la possibilité de le résoudre car il n'a pas d'interpréteur Javascript signifie que le client ne peut pas donner la bonne réponse et ainsi gagner un TOKEN (qui en général dure 30 minutes mais peut être augmentée à partir des paramètres CloudFlare) afin d'être sur liste blanche et donc d'atteindre le site.

Nous pouvons facilement reconnaître un site sur lequel le mode SOUS ATTAQUE est activé à partir d'un écran d'accueil d'introduction comme le suivant et avec un temps d'attente de quelques secondes, le temps de relever le défi.

Mais que faire si les requêtes ne sont pas générées par des clients grossiers, mais par de vrais navigateurs Web comme Firefox, Google Chrome, Internet Explorer, Safari, qui à leur insu sont détournés en très grand nombre vers le site de l'attaquant ? Il arrive que leur navigateur étant un navigateur Javascript à part entière, il pourra résoudre le défi, obtenir le jeton et pouvoir inonder le site de la victime de requêtes.

À ce stade, nous ne pouvons donc plus nous limiter à garder leMode SOUS ATTAQUE par CloudFlare sans rien faire d'autre, puis se plaindre que CloudFlare ne fonctionne pas. Vous ne savez tout simplement pas comment l'utiliser. Il ne suffit pas d'avoir l'outil pour être maître mais surtout de savoir s'en servir. Cette règle est valable dans tous les domaines de la vie, notamment dans le domaine professionnel.

Que filtrer cependant ?

Ce que vous devez faire, c'est comprendre comment l'attaque se produit, d'où viennent les demandes, quels sont les renvois, les pays, les fournisseurs, les demandes, les URL qui sont appelées afin d'identifier chirurgicalement le trafic malveillant de ce trafic légitime et ne laissez passer que ce dernier.

Pour ce faire, nous avons tout d'abord besoin d'une certaine expérience dans l'analyse des requêtes qui arrivent au serveur Web en parcourant le journal qui s'appelle normalement access.log ou access_log.

C'est à travers l'analyse de ces requêtes que l'on peut percevoir visuellement les anomalies du trafic malveillant et de l'attaque et aller filtrer ce trafic.

Pour ce faire, nous avons le module FIREWALL de CloudFlare ce qui nous permet d'utiliser certains paramètres pour filtrer en fonction des conditions à l'aide d'opérateurs logiques.

Par exemple, nous pourrions vérifier (faire correspondre) le trafic à travers le pays et décider de bloquer toutes les IP en provenance du Brésil, d'Iran et de Russie, ou peut-être connecter uniquement des IP provenant d'Italie, de Saint-Marin et de Suisse.

Ou nous pourrions décider de connecter toutes les IP européennes qui n'ont pas le site reddit.com comme référence, ou de connecter tous les pays européens sauf les clients qui recherchent sur le site avec le paramètre dans l'URL ?S=.

Bien que le plan gratuit CloudFlare ne vous permette de définir que 5 règles de pare-feu, leur combinaison via l'utilisation des opérateurs logiques AND et OR nous permet de définir chirurgicalement n'importe quel modèle afin de décider de le bloquer ou de le laisser atteindre notre site.

Les possibilités d'utilisation et les combinaisons possibles dans des scénarios réels sont si nombreuses qu'il serait impossible d'examiner toutes les possibilités dans cet article, mais il est bon de savoir que grâce à une analyse appropriée et à un ajustement de la prise de vue avec une pincée d'intuition, d'expérience et de compétence il est toujours possible d'arrêter un DDOS Layer7 qui parvient à maintenir un site qui autrement aurait inévitablement disparu.

L'utilisation de CloudFlare comme solution de sécurité des applications nous permet d'obtenir les avantages et méthodes de filtrage très importants suivants :

1. Filtrage au niveau du navigateur via le mode Under Attack

À travers leEn mode attaque de CloudFlare, il est possible de défier les navigateurs des visiteurs pour vérifier s'il s'agit de vrais navigateurs ou simplement de trafic HTTP / S d'outils astucieusement emballés pour amener DDOS au niveau de l'application et forger des requêtes GET ou POST malveillantes. Dans cette phase nous allons discerner les navigateurs des vrais utilisateurs des outils des attaquants en bloquant ces derniers.

2. Filtrage au niveau de référence

Dans ce mode utilisé dans certains types d'attaque par injection de contenu sur des sites très fréquentés, on peut décider de filtrer l'attaquant en déterminant le référent. En fait, si l'utilisateur réel provient d'une référence utilisée comme vecteur d'attaque, le blocage de la référence avec des règles de pare-feu appropriées bloquera également tous les utilisateurs qui proviennent de cette référence.

3. Filtrage des modèles d'URL

Si un botnet décide d'appeler des modèles spécifiques dans des URL en mode intense ou d'utiliser des modèles paramétriques pour contourner tout système de cache, nous pouvons identifier le modèle et bloquer son accès.

4. Filtrage au niveau géographique.

Nous pouvons activer un type de filtrage géographique au niveau GeoIP qui nous permet de bloquer ou de contester les connexions provenant de pays suspects via le mode Under Attack. Par exemple, si notre entreprise est italienne ou peut-être européenne, nous pouvons décider de bloquer ou de contester les IP asiatiques, africaines, américaines, russes, etc.

La précision de cette solution est supérieure à 99% et permet de mettre en place des politiques de filtrage très agressives et restrictives si vous êtes confronté à une solution extrêmement complexe à résoudre immédiatement.

5. Filtrage sur Autonomous System AS

Un système autonome (en francese Système autonome), en référence à protocoles de routage, est un groupe de routeur e réseaux sous le contrôle d'une autorité administrative unique et bien définie.

Devrions-nous être attaqués par Serveurs Dédiés piratés et utilisés comme zombies pour lancer l'attaque contre nos clients, nous pouvons décider de filtrer toutes les connexions qui n'appartiennent pas aux fournisseurs proposant des services DSL grand public.

Pourquoi un serveur Digital Ocean ou AWS ou OVH devrait-il faire des requêtes à notre serveur web où nous pouvons héberger un e-commerce d'articles de sport ?

Comme il n'y a apparemment aucune raison à cela et qu'une attaque est en cours, une autre possibilité consiste à bloquer les systèmes autonomes de centre de données connus qui peuvent être piratés et utilisés contre.

6. Un MIX des méthodes ci-dessus en combo

L'utilisation d'opérateurs logiques d'inclusion et d'exclusion tels que AND et OR nous permet d'utiliser toutes les méthodes précédentes décrites en utilisant des conditions logiques très complexes qui nous permettent d'être chirurgical dans l'application des règles de filtrage, excluant les faux positifs et le trafic légitime par le filtrage et l'abandon des politiques qui suivent.

7. Orienté SEO

Toutes les opérations de filtrage sont orientées SEO, c'est-à-dire adéquates pour ne pas bloquer les activités de crawl légitimes des principaux moteurs de recherche tels que Google et Bing.

 

Si vous souhaitez notre aide et notre expérience pour mieux atténuer une attaque DDOS, n'hésitez pas à nous contacter.