Combattre les attaques DDoS est non seulement un travail difficile, mais aussi passionnant. Il n'est pas surprenant que chaque administrateur système essaie avant tout d'organiser lui-même la défense - d'autant plus que cela est encore possible.

Nous avons décidé de vous aider dans cette affaire difficile et de publier quelques conseils courts, triviaux et non universels pour protéger votre site contre les attaques. Les recettes données ne vous aideront pas à faire face à une quelconque attaque, mais elles vous protégeront de la plupart des dangers.

Les bons ingrédients

La dure vérité est que n'importe qui peut détruire de nombreux sites en utilisant l'attaque Slowloris, qui tue complètement Apache, ou en organisant ce qu'on appelle un SYN Flood à l'aide d'une ferme de serveurs virtuels créée en une minute dans le cloud Amazon EC2. Tous nos autres conseils sur la protection DDoS à faire soi-même sont basés sur les conditions importantes suivantes.

1. Arrêtez d'utiliser Windows Server

La pratique suggère qu'un site fonctionnant sous Windows (2003 ou 2008 - peu importe) est voué à l'échec en cas de DDoS. La raison de l'échec réside dans la pile réseau Windows : lorsqu'il y a beaucoup de connexions, le serveur commence certainement à mal répondre. Nous ne savons pas pourquoi Windows Server fonctionne de manière si dégoûtante dans de telles situations, mais nous avons rencontré cela plus d'une ou deux fois. Pour cette raison, cet article se concentrera sur les moyens de protection contre les attaques DDoS dans le cas où le serveur fonctionne sous Linux. Si vous êtes l'heureux propriétaire d'un noyau relativement moderne (à partir de la version 2.6), les principaux outils seront les utilitaires iptables et ipset (pour ajouter rapidement des adresses IP), avec lesquels vous pourrez rapidement bannir les robots. Une autre clé du succès est une pile réseau correctement préparée, dont nous parlerons également plus tard.

2. Rompre avec Apache

La deuxième condition importante est l’abandon d’Apache. Si vous utilisez Apache, installez au moins un proxy de mise en cache devant celui-ci - nginx ou lighttpd. Apache est extrêmement difficile à transférer des fichiers et, ce qui est encore pire, il est fondamentalement (c'est-à-dire irrémédiablement) vulnérable à l'attaque Slowloris la plus dangereuse, qui vous permet de submerger le serveur presque à partir d'un téléphone mobile. types de Slowloris, les utilisateurs d'Apache ont d'abord proposé un patch Anti-slowloris.diff, puis mod_noloris, puis mod_antiloris, mod_limitipconn, mod_reqtimeout... Mais si vous voulez dormir paisiblement la nuit, il est plus facile d'utiliser un serveur HTTP immunisé à Slowloris au niveau de l'architecture du code. Par conséquent, toutes nos autres recettes sont basées sur l'hypothèse que ce nginx est utilisé sur le frontend.

Combattre les DDoS

Que faire si un DDoS arrive ? Une technique d'autodéfense traditionnelle consiste à lire le fichier journal du serveur HTTP, à écrire un modèle grep (captant les requêtes des robots) et à bannir tous ceux qui en font partie. Cette technique fonctionnera... si vous avez de la chance. Il existe deux types de botnets, tous deux dangereux, mais de manière différente. L'un arrive complètement sur le site instantanément, l'autre progressivement. Le premier tue tout d’un coup, mais tout apparaît dans les journaux, et si vous les réchauffez et bannissez toutes les adresses IP, alors vous êtes gagnant. Le deuxième botnet attaque le site avec douceur et précaution, mais vous devrez peut-être le bannir pendant 24 heures. Il est important que tout administrateur comprenne : si vous envisagez de vous battre avec grep, vous devez alors être prêt à consacrer quelques jours à combattre l'attaque. Vous trouverez ci-dessous des conseils sur l'endroit où vous pouvez placer les pailles à l'avance pour rendre les chutes moins douloureuses.

3. Utilisez le module testcookie

Peut-être la recette la plus importante, la plus efficace et la plus opérationnelle de cet article. Si des attaques DDoS arrivent sur votre site, le moyen le plus efficace de riposter peut être le module testcookie-nginx, développé par habrauser @kyprizel. L'idée est simple. Le plus souvent, les robots qui implémentent l'inondation HTTP sont assez stupides et ne disposent pas de mécanismes de cookie et de redirection HTTP. Parfois, vous en rencontrez des plus avancés - ils peuvent utiliser des cookies et traiter des redirections, mais presque jamais un robot DoS ne dispose d'un moteur JavaScript à part entière (bien que cela devienne de plus en plus courant). Testcookie-nginx fonctionne comme un filtre rapide entre les robots et le backend lors d'une attaque DDoS L7, vous permettant de filtrer les requêtes indésirables. Que sont inclus dans ces contrôles ? Le client sait-il comment effectuer une redirection HTTP, prend-il en charge JavaScript, est-ce le navigateur qu'il prétend être (puisque JavaScript est différent partout et si le client dit qu'il s'agit, disons, de Firefox, alors nous pouvons le vérifier). La vérification est mise en œuvre à l'aide de cookies selon différentes méthodes :

• « Set-Cookie » + redirection à l'aide de l'emplacement HTTP 301 ;
• « Set-Cookie » + redirection à l'aide de la méta-actualisation HTML ;
• n’importe quel modèle et vous pouvez utiliser JavaScript.

Pour éviter l'analyse automatique, le cookie de validation peut être chiffré avec AES-128 puis déchiffré côté client JavaScript. La nouvelle version du module a la possibilité de définir des cookies via Flash, ce qui vous permet également de filtrer efficacement les robots (que Flash, en règle générale, ne prend pas en charge), mais bloque également l'accès à de nombreux utilisateurs légitimes (en en fait, tous les appareils mobiles). Il est à noter qu’il est extrêmement simple de commencer à utiliser testcookie-nginx. Le développeur, en particulier, fournit plusieurs exemples clairs d'utilisation (pour différents cas d'attaque) avec des exemples de configurations pour nginx.

En plus de ses avantages, testcookie présente également des inconvénients :

• coupe tous les robots, y compris Googlebot. Si vous envisagez de conserver testcookie de manière permanente, assurez-vous de ne pas disparaître des résultats de recherche ;
• crée des problèmes pour les utilisateurs avec Links, w3m et navigateurs similaires ;
• ne protège pas contre les robots équipés d'un moteur de navigation à part entière avec JavaScript.

Bref, testcookie_module n'est pas universel. Mais cela aide pour un certain nombre de choses, comme par exemple les outils primitifs en Java et C#. De cette façon, vous éliminez une partie de la menace.

4.Code 444

La cible des DDoSers est souvent la partie du site la plus gourmande en ressources. Un exemple typique est la recherche, qui effectue des requêtes de base de données complexes. Naturellement, les attaquants peuvent en profiter en chargeant plusieurs dizaines de milliers de requêtes sur le moteur de recherche à la fois. Ce que nous pouvons faire? Désactivez temporairement la recherche. Même si les clients ne peuvent pas rechercher les informations dont ils ont besoin à l'aide des outils intégrés, l'ensemble du site principal restera opérationnel jusqu'à ce que vous trouviez la racine de tous les problèmes. Nginx prend en charge un code 444 non standard, qui vous permet simplement de fermer la connexion et de ne rien renvoyer en réponse :

Localisation/recherche (retour 444 ; )

De cette manière, vous pouvez par exemple mettre en place rapidement un filtrage par URL. Si vous êtes sûr que les demandes de localisation /search proviennent uniquement de robots (par exemple, votre confiance repose sur le fait que votre site n'a pas du tout de section /search), vous pouvez installer le package ipset sur le serveur et bannir des robots avec un simple script shell :

Ipset -N bannir iphash tail -f access.log | en lisant LINE ; faire écho "$LINE" | \ cut -d""" -f3 | cut -d" " -f2 | grep -q 444 && ipset -A ban "$(L%% *)"; terminé

Si le format du fichier journal n'est pas standard (non combiné) ou si vous devez interdire sur la base de critères autres que l'état de la réponse, vous devrez peut-être remplacer cut par une expression régulière.

5. On bannit par géolocalisation

Le code de réponse non standard 444 peut également être utile pour bannir rapidement des clients en fonction de caractéristiques géolocalisées. Vous pouvez limiter strictement certains pays qui vous mettent mal à l’aise. Par exemple, il est peu probable qu'un magasin d'appareils photo en ligne de Rostov-sur-le-Don compte de nombreux utilisateurs en Égypte. Ce n'est pas une très bonne méthode (pour parler franchement, dégoûtant), car les données GeoIP sont inexactes et les Rostovites s'envolent parfois pour l'Égypte en vacances. Mais si vous n'avez rien à perdre, alors suivez les instructions :

1. Connectez le module GeoIP à nginx (wiki.nginx.org/HttpGeoipModule).
2. Afficher les informations de géoréférencement dans le journal d’accès.
3. Ensuite, en modifiant le script shell ci-dessus, exécutez le journal d'accès de nginx et ajoutez les clients géographiquement exclus à l'interdiction.

Si, par exemple, les robots venaient principalement de Chine, cela pourrait être utile.

6. Réseau neuronal (PoC)

Enfin, vous pouvez répéter l'expérience de l'utilisateur habra @SaveTheRbtz, qui a pris le réseau neuronal PyBrain, y a inséré le journal et analysé les requêtes (habrahabr.ru/post/136237). La méthode fonctionne, mais pas universelle :). Mais si vous connaissez vraiment l'intérieur de votre site - et vous devriez le faire en tant qu'administrateur système - alors vous avez une chance que dans les situations les plus tragiques, une telle boîte à outils basée sur les réseaux de neurones, la formation et les informations collectées à l'avance vous aidera. Dans ce cas, il est très utile d'avoir access.log avant le début des DDoS, car il décrit presque 100% des clients légitimes, et donc un excellent ensemble de données pour entraîner un réseau neuronal. De plus, les robots ne sont pas toujours visibles dans le journal. .

Diagnostic du problème

Le site ne fonctionne pas - pourquoi ? S'agit-il d'un DDoSed ou s'agit-il d'un bug du moteur qui n'a pas été remarqué par le programmeur ? Cela n'a pas d'importance. Ne cherchez pas de réponse à cette question. Si vous pensez que votre site peut être attaqué, contactez les sociétés qui assurent une protection contre les attaques - un certain nombre de services anti-DDoS offrent des premiers jours gratuits après la connexion - et ne perdez plus de temps à chercher des symptômes. Concentrez-vous sur le problème. Si un site est lent ou ne s'ouvre pas du tout, il y a un problème avec ses performances et - qu'il y ait une attaque DDoS ou non - il est de votre responsabilité en tant que professionnel de comprendre quelle en est la cause. Nous avons vu à plusieurs reprises comment une entreprise rencontrant des difficultés avec le fonctionnement de son site Internet en raison d'une attaque DDoS, au lieu de rechercher des faiblesses dans le moteur du site, a tenté d'envoyer des déclarations au ministère de l'Intérieur afin de trouver et de punir les attaquants. Ne faites pas ces erreurs. Trouver des cybercriminels est un processus difficile et long, compliqué par la structure même et les principes de fonctionnement d'Internet, et le problème de fonctionnement du site doit être résolu dans les plus brefs délais. Demandez à des spécialistes techniques de trouver la raison de la baisse des performances du site, et les avocats pourront rédiger une déclaration.

7. Utilisez un profileur et un débogueur

Pour la plateforme de création de sites Web la plus courante - PHP + MySQL - le goulot d'étranglement peut être détecté à l'aide des outils suivants :

• le profileur Xdebug affichera les appels sur lesquels l'application passe le plus de temps ;
• le débogueur APD intégré et la sortie de débogage dans le journal des erreurs vous aideront à découvrir exactement quel code effectue ces appels ;
• dans la plupart des cas, le chien est noyé dans la complexité et la lourdeur des requêtes dans les bases de données. La directive expliquer SQL intégrée au moteur de base de données sera utile ici.

Si le site est en panne et que vous ne perdez rien, déconnectez-vous du réseau, consultez les journaux, essayez de les lire. Si ce n’est pas le cas, parcourez les pages et regardez la base.

L'exemple concerne PHP, mais l'idée est valable pour n'importe quelle plateforme. Un développeur qui écrit des produits logiciels dans n'importe quel langage de programmation doit être capable d'utiliser rapidement à la fois un débogueur et un profileur. Entraînez-vous à l’avance !

8. Analyser les erreurs

Analysez le volume de trafic, le temps de réponse du serveur et le nombre d'erreurs. Pour ce faire, consultez les journaux. Dans nginx, le temps de réponse du serveur est enregistré dans le journal par deux variables : request_time et Upstream_response_time. Le premier est le temps total d’exécution de la requête, y compris les délais de réseau entre l’utilisateur et le serveur ; la seconde indique combien de temps le backend (Apache, php_fpm, uwsgi...) a exécuté la requête. La valeur en amont_response_time est extrêmement importante pour les sites avec beaucoup de contenu dynamique et une communication active entre le frontend et la base de données ; elle ne doit pas être négligée. Vous pouvez utiliser la configuration suivante comme format de journal :

Log_format xakep_log "$remote_addr - $remote_user [$time_local] " ""$request" $status $body_bytes_sent " ""$http_referer" "$http_user_agent" $request_time \ $upstream_response_time";

Il s'agit d'un format combiné avec des champs de timing ajoutés.

9. Suivre les requêtes par seconde

Regardez également le nombre de requêtes par seconde. Dans le cas de nginx, vous pouvez estimer approximativement cette valeur avec la commande shell suivante (la variable ACCESS_LOG contient le chemin d'accès au journal des requêtes nginx au format combiné) :

Écho $(($(fgrep -c "$(env LC_ALL=C date --date=@$(($(date \ +%s)-60)) +%d/%b/%Y:%H : %M)" "$ACCESS_LOG")/60))

Par rapport au niveau normal à cette heure de la journée, le nombre de requêtes par seconde peut diminuer ou augmenter. Ils se développent si un grand botnet arrive, et ils chutent si le botnet entrant fait tomber le site, le rendant complètement inaccessible aux utilisateurs légitimes, et en même temps, le botnet ne demande pas de statistiques, mais les utilisateurs légitimes le font. La baisse du nombre de demandes est observée précisément en raison de la statique. Mais, d’une manière ou d’une autre, nous parlons de changements sérieux dans les indicateurs. Lorsque cela se produit soudainement - pendant que vous essayez de résoudre le problème par vous-même et si vous ne le voyez pas immédiatement dans le journal, il est préférable de vérifier rapidement le moteur et en même temps de contacter des spécialistes.

10. N'oubliez pas tcpdump

Beaucoup de gens oublient que tcpdump est un formidable outil de diagnostic. Je vais vous donner quelques exemples. En décembre 2011, un bug a été découvert dans le noyau Linux lors de l'ouverture d'une connexion TCP lorsque les indicateurs de segment TCP SYN et RST étaient définis. Le premier rapport de bug a été envoyé par l'administrateur système de Russie, dont la ressource a été attaquée par cette méthode - les attaquants ont découvert la vulnérabilité avant le monde entier. Évidemment, ce diagnostic l'a aidé. Autre exemple : nginx a une propriété pas très agréable : il n'écrit dans le journal qu'une fois la demande entièrement traitée. Il y a des situations où le site est en panne, rien ne fonctionne et il n'y a rien dans les journaux. En effet, toutes les requêtes qui chargent actuellement le serveur ne sont pas encore terminées. Tcpdump aidera ici aussi.

C'est tellement bon que j'ai conseillé aux gens de ne pas utiliser de protocoles binaires jusqu'à ce qu'ils soient sûrs que tout est en ordre - après tout, les protocoles texte sont faciles à déboguer avec tcpdump, mais pas les protocoles binaires. Cependant, le sniffer est bon comme outil de diagnostic outil - comme moyen de maintenir la production" et il fait peur. Il peut facilement perdre plusieurs paquets à la fois et ruiner votre historique utilisateur. Il est pratique de consulter son résultat, et c’est utile pour les diagnostics manuels et les interdictions, mais essayez de ne rien baser de critique sur cela. Un autre outil favori pour « enterrer les demandes » - ngrep - essaie généralement par défaut de demander environ deux gigaoctets de mémoire non échangeable et commence alors seulement à réduire ses besoins.

11. Attaquer ou pas ?

Comment distinguer une attaque DDoS, par exemple, de l’effet d’une campagne publicitaire ? Cette question peut paraître drôle, mais le sujet n’en est pas moins complexe. Il y a des cas assez drôles. Certains bons gars, lorsqu'ils se sont mis à rude épreuve et ont complètement foiré la mise en cache, le site est tombé en panne pendant quelques jours. Il s'est avéré que depuis plusieurs mois, ce site avait été discrètement dataminé par certains Allemands, et avant que la mise en cache ne soit optimisée, les pages du site de ces Allemands avec toutes les images prenaient beaucoup de temps à charger. Lorsque la page a commencé à être servie instantanément à partir du cache, le bot, qui n'avait pas de délai d'attente, a également commencé à les collecter instantanément. C'était difficile. Le cas est particulièrement difficile car si vous avez vous-même modifié les paramètres (activé la mise en cache) et que le site a cessé de fonctionner après cela, alors qui, de votre avis et de celui de votre patron, est à blâmer ? Exactement. Si vous constatez une forte augmentation du nombre de requêtes, regardez, par exemple, dans Google Analytics, qui a visité quelles pages.

Réglage du serveur Web

Quels sont les autres points clés ? Bien sûr, vous pouvez installer nginx par défaut et espérer que tout ira bien. Cependant, les choses ne se passent pas toujours bien. Par conséquent, l'administrateur de n'importe quel serveur doit consacrer beaucoup de temps à la mise au point et au réglage de nginx.

12. Limiter les ressources (taille des tampons) dans nginx

Que faut-il retenir en premier ? Chaque ressource a une limite. Tout d'abord, cela concerne la RAM. Par conséquent, les tailles des en-têtes et de tous les tampons utilisés doivent être limitées à des valeurs adéquates pour le client et l'ensemble du serveur. Ils doivent être enregistrés dans la configuration nginx.

• client_header_buffer_size_ _ Définit la taille du tampon pour lire l'en-tête de la demande client. Si la ligne de requête ou le champ d'en-tête de requête ne rentre pas entièrement dans ce tampon, alors des tampons plus grands sont alloués, spécifiés par la directive large_client_header_buffers.
• large_client_header_buffers Définit le nombre maximum et la taille des tampons pour lire un en-tête de demande client volumineux.
• client_body_buffer_size Définit la taille du tampon pour lire le corps de la demande client. Si le corps de la requête est plus grand que le tampon spécifié, alors la totalité du corps de la requête ou seulement une partie est écrite dans un fichier temporaire.
• client_max_body_size Définit la taille maximale autorisée du corps de la requête client, spécifiée dans le champ « Content-Length » de l'en-tête de la requête. Si la taille est supérieure à celle spécifiée, l'erreur 413 (Demande d'entité trop grande) est renvoyée au client.

13. Configuration des délais d'attente dans nginx

Le temps est aussi une ressource. Par conséquent, la prochaine étape importante devrait être de définir tous les délais d'attente, qu'il est encore une fois très important de spécifier soigneusement dans les paramètres nginx.

• reset_timedout_connection activé ; Aide à gérer les sockets bloqués dans la phase FIN-WAIT.
• client_header_timeout Définit le délai d'expiration lors de la lecture de l'en-tête de la demande client.
• client_body_timeout Définit le délai d'expiration lors de la lecture du corps d'une requête client.
• keepalive_timeout Définit le délai d'attente pendant lequel la connexion persistante au client ne sera pas fermée du côté serveur. Beaucoup de gens ont peur de fixer ici des valeurs élevées, mais nous ne sommes pas sûrs que cette crainte soit justifiée. En option, vous pouvez définir une valeur de délai d'attente dans l'en-tête HTTP Keep-Alive, mais Internet Explorer est célèbre pour ignorer cette valeur.
• envoyer_timeout Définit le délai d'expiration lors de l'envoi d'une réponse au client. Si passé ce délai le client n'accepte rien, la connexion sera fermée.

Immédiatement, la question est : quels paramètres de tampons et de délais d'attente sont corrects ? Il n’y a pas de recette universelle ici ; chaque situation a la sienne. Mais il existe une approche éprouvée. Il est nécessaire de fixer les valeurs minimales auxquelles le site reste opérationnel (en temps de paix), c'est-à-dire que les pages sont servies et les demandes sont traitées. Ceci est déterminé uniquement par des tests, à la fois sur des ordinateurs de bureau et sur des appareils mobiles. Algorithme pour retrouver les valeurs de chaque paramètre (taille du buffer ou timeout) :

1. Nous définissons la valeur mathématiquement minimale du paramètre.
2. Nous commençons à exécuter des tests sur site.
3. Si toutes les fonctionnalités du site fonctionnent sans problème, le paramètre est défini. Sinon, augmentez la valeur du paramètre et passez à l'étape 2.
4. Si la valeur du paramètre dépasse même la valeur par défaut, c'est un motif de discussion au sein de l'équipe de développement.

Dans certains cas, une révision de ces paramètres devrait conduire à une refactorisation/refonte du site. Par exemple, si un site ne fonctionne pas sans de longues requêtes d'interrogation AJAX de trois minutes, vous n'avez pas besoin d'augmenter le délai d'attente, mais de remplacer les longues interrogations par autre chose - un botnet de 20 000 machines, suspendu aux requêtes pendant trois minutes, tuera facilement le serveur bon marché moyen.

14. Limiter les connexions dans nginx (limit_conn et limit_req)

Nginx a également la capacité de limiter les connexions, les requêtes, etc. Si vous n'êtes pas sûr du comportement d'une certaine partie de votre site, vous devez idéalement la tester, comprendre combien de requêtes elle traitera et l'écrire dans la configuration nginx. C'est une chose lorsque le site est en panne et que vous pouvez venir le récupérer. Et c'est une tout autre affaire quand cela tombe en panne à tel point que le serveur entre en swap. Dans ce cas, il est souvent plus simple de redémarrer que d’attendre son retour triomphal.

Supposons que le site comporte des sections avec des noms descriptifs /download et /search. En même temps nous :

• nous ne voulons pas que des robots (ou des personnes possédant des gestionnaires de téléchargement récursifs trop zélés) remplissent notre table de connexion TCP avec leurs téléchargements ;
• Nous ne voulons pas que les robots (ou les robots des moteurs de recherche aléatoires) épuisent les ressources informatiques du SGBD avec une multitude de requêtes de recherche.

À ces fins, la configuration suivante fonctionnera :

Http ( limit_conn_zone $binary_remote_addr zone=download_c:10m; limit_req_zone $binary_remote_addr zone=search_r:10m \ rate=1r/s; serveur ( emplacement /download/ ( limit_conn download_c 1; # Autre emplacement de configuration ) emplacement /search/ ( limit_req zone= search_r burst=5; # Autre emplacement de configuration ) ) )

Habituellement, il est tout à fait logique de définir des restrictions limit_conn et limit_req pour les emplacements où se trouvent les scripts coûteux à exécuter (l'exemple montre une recherche, et c'est pour une bonne raison). Les contraintes doivent être choisies en fonction des résultats des tests de charge et de régression, ainsi que du bon sens.

Notez le paramètre 10m dans l'exemple. Cela signifie qu'un dictionnaire avec un tampon de 10 mégaoctets et non un mégaoctet de plus sera alloué pour calculer cette limite. Dans cette configuration, cela permettra de surveiller 320 000 sessions TCP. Pour optimiser l'empreinte mémoire, la variable $binary_remote_addr est utilisée comme clé dans le dictionnaire, qui contient l'adresse IP de l'utilisateur sous forme binaire et occupe moins de mémoire que la variable de chaîne $remote_addr standard. Il convient de noter que le deuxième paramètre de la directive limit_req_zone peut être non seulement IP, mais également toute autre variable nginx disponible dans ce contexte - par exemple, dans le cas où vous ne souhaitez pas fournir un mode plus doux pour le proxy, vous pouvez utiliser $binary_remote_addr$http_user_agent ou $binary_remote_addr$http_cookie_myc00kiez - mais vous devez utiliser de telles constructions avec prudence, car, contrairement au $binary_remote_addr 32 bits, ces variables peuvent être considérablement plus longues et les « 10 m » que vous avez déclarées peuvent se terminer soudainement.

Tendances DDoS

1. La puissance des attaques sur les couches réseau et transport ne cesse de croître. Le potentiel d’une attaque par inondation SYN moyenne a déjà atteint 10 millions de paquets par seconde.
2. Les attaques contre le DNS sont particulièrement demandées ces derniers temps. L'inondation UDP de requêtes DNS valides avec des adresses IP sources usurpées est l'une des attaques les plus faciles à mettre en œuvre et difficile à contrer. De nombreuses grandes entreprises russes (y compris des sociétés d'hébergement) ont récemment rencontré des problèmes suite à des attaques contre leurs serveurs DNS. Plus vous avancez, plus ces attaques seront nombreuses et leur puissance augmentera.
3. À en juger par les signes extérieurs, la plupart des botnets ne sont pas contrôlés de manière centralisée, mais via un réseau peer-to-peer. Cela donne aux attaquants la possibilité de synchroniser les actions du botnet au fil du temps - si auparavant les commandes de contrôle étaient distribuées sur un botnet de 5 000 machines en quelques dizaines de minutes, les secondes comptent désormais et votre site peut connaître de manière inattendue une multiplication instantanée par cent du nombre de requêtes. .
4. La part des robots équipés d'un moteur de navigation à part entière avec JavaScript est encore faible, mais elle ne cesse de croître. Une telle attaque est plus difficile à repousser avec des moyens improvisés intégrés, les bricoleurs doivent donc surveiller cette tendance avec prudence.

préparer le système d'exploitation

En plus d'affiner nginx, vous devez prendre soin des paramètres de la pile réseau du système. À tout le moins, activez immédiatement net.ipv4.tcp_syncookies dans sysctl pour vous protéger immédiatement d'une petite attaque SYN-flood.

15. Ajustez le noyau

Faites attention aux paramètres plus avancés de la partie réseau (noyau), toujours concernant les délais d'attente et la mémoire. Il y en a des plus importants et des moins importants. Tout d’abord, vous devez faire attention à :

• net.ipv4.tcp_fin_timeout Le temps que le socket passera dans la phase TCP FIN-WAIT-2 (en attente du segment FIN/ACK).
• net.ipv4.tcp_(,r,w)mem Taille du tampon de réception du socket TCP. Trois valeurs : minimum, par défaut et maximum.
• net.core.(r,w)mem_max Il en va de même pour les tampons non TCP.

Avec un canal de 100 Mbit/s, les valeurs par défaut sont toujours adaptées ; mais si vous disposez d'au moins un gigabit par seconde, il est préférable d'utiliser quelque chose comme :

Sysctl -w net.core.rmem_max=8388608 sysctl -w net.core.wmem_max=8388608 sysctl -w net.ipv4.tcp_rmem="4096 87380 8388608" sysctl -w net.ipv4.tcp_wmem="4096 65536 8388608" " système - w net.ipv4.tcp_fin_timeout=10

16. Révision /proc/sys/net/**

Il est idéal d'explorer tous les paramètres dans /proc/sys/net/**. Nous devons voir à quel point ils sont différents de ceux par défaut et comprendre dans quelle mesure ils sont correctement définis. Un développeur Linux (ou administrateur système) qui comprend le fonctionnement du service Internet sous son contrôle et souhaite l'optimiser devrait lire avec intérêt la documentation de tous les paramètres de la pile réseau du noyau. Peut-être y trouvera-t-il des variables spécifiques au site qui contribueront non seulement à protéger le site des intrus, mais également à accélérer son fonctionnement.

N'ayez pas peur!

Jour après jour, les attaques DDoS réussies éteignent le commerce électronique, ébranlent les médias et détruisent les plus grands systèmes de paiement d'un seul coup. Des millions d’internautes perdent l’accès à des informations critiques. La menace est urgente, nous devons donc y faire face de front. Faites vos devoirs, n'ayez pas peur et gardez la tête froide. Vous n'êtes ni le premier ni le dernier à être confronté à une attaque DDoS sur votre site Web, et il est en votre pouvoir, guidé par vos connaissances et votre bon sens, de réduire au minimum les conséquences de l'attaque.

Attaque DDOS. Explication et exemple.

Salut tout le monde. Ceci est le blog Computer76, et maintenant un autre article sur les bases de l'art du hacking. Aujourd'hui, nous allons parler de ce qu'est une attaque DDOS avec des mots et des exemples simples. Avant d’aborder les termes techniques, il y aura une introduction que tout le monde pourra comprendre.

Pourquoi une attaque DDOS est-elle utilisée ?

Le piratage WiFi est utilisé pour obtenir le mot de passe d'un réseau sans fil. Les attaques sous la forme de « » vous permettront d'écouter le trafic Internet. L'analyse des vulnérabilités suivie du chargement d'une spécifique permet de capturer l'ordinateur cible. À quoi sert une attaque DDOS ? Son objectif est en fin de compte de sélectionner les droits de propriété d'une ressource auprès du propriétaire légitime. Je ne veux pas dire que vous ne serez pas propriétaire du site ou du blog. Cela signifie qu'en cas d'attaque réussie sur votre site, vous tu perdras la capacité de le contrôler. Au moins pour un moment.

Cependant, dans l’interprétation moderne d’une attaque DDOS, elle est le plus souvent utilisée pour perturber le fonctionnement normal de n’importe quel service. Des groupes de hackers, dont les noms sont constamment entendus, attaquent de grands sites Web gouvernementaux ou gouvernementaux afin d'attirer l'attention sur certains problèmes. Mais presque toujours derrière de telles attaques se cache un intérêt purement mercantile : le travail de concurrents ou de simples farces sur des sites totalement indécents et non protégés. Le concept principal de DDOS est qu'un grand nombre d'utilisateurs, ou plutôt de requêtes provenant d'ordinateurs robots, accèdent au site en même temps, ce qui rend la charge sur le serveur insupportable. On entend souvent l'expression « le site est indisponible », mais peu de gens pensent à ce qui se cache réellement derrière cette formulation. Eh bien, maintenant vous le savez.

Attaque DDOS - options

Option 1.

joueurs bondés à l'entrée

Imaginez que vous jouez à un jeu multijoueur en ligne. Des milliers de joueurs jouent avec vous. Et vous connaissez la plupart d’entre eux. Vous discutez des détails et à l'heure X effectuez les actions suivantes. Vous allez tous sur le site en même temps et créez un personnage avec le même ensemble de caractéristiques. Vous vous regroupez en un seul endroit, bloquant avec votre nombre de personnages créés simultanément l'accès aux objets du jeu à d'autres utilisateurs de bonne foi qui ne se doutent de rien de votre collusion.

Option 2.

Imaginez que quelqu'un décide de perturber le service de bus dans la ville sur un certain itinéraire afin d'empêcher les passagers de bonne foi d'utiliser les services de transports publics. Des milliers de vos amis se rendent simultanément aux arrêts au début de l'itinéraire spécifié et roulent sans but dans toutes les voitures d'un bout à l'autre jusqu'à ce que l'argent soit épuisé. Le voyage est payé, mais personne ne descend à aucun arrêt, sauf aux destinations finales. Et d'autres passagers, debout aux arrêts intermédiaires, surveillent tristement les minibus au départ, incapables de se faufiler dans les bus bondés. Tout le monde est en difficulté : les propriétaires de taxi et les passagers potentiels.

En réalité, ces options ne peuvent pas être physiquement mises en œuvre. Cependant, dans le monde virtuel, vos amis peuvent être remplacés par les ordinateurs d'utilisateurs peu scrupuleux qui ne prennent pas la peine de protéger leur ordinateur ou leur ordinateur portable d'une manière ou d'une autre. Et la grande majorité est comme ça. Il existe de nombreux programmes permettant de mener des attaques DDOS. Il va sans dire que de telles actions sont illégales. Et une attaque DDOS préparée de manière absurde, aussi réussie soit-elle, est détectée et punie.

Comment se déroule une attaque DDOS ?

En cliquant sur un lien d'un site Web, votre navigateur envoie une requête au serveur pour afficher la page que vous recherchez. Cette demande est exprimée sous forme de paquet de données. Et pas même un seul, mais tout un paquet de forfaits ! Dans tous les cas, la quantité de données transmises par canal est toujours limitée à une certaine largeur. Et la quantité de données renvoyées par le serveur est disproportionnée par rapport à ce qui est contenu dans votre requête. Cela prend de l'énergie et des ressources du serveur. Plus le serveur est puissant, plus il coûte cher au propriétaire et plus les services qu'il fournit sont chers. Les serveurs modernes peuvent facilement faire face à un afflux de visiteurs en forte augmentation. Mais pour chacun des serveurs, il existe toujours un nombre critique d'utilisateurs souhaitant se familiariser avec le contenu du site. Plus la situation est claire avec le serveur qui fournit les services d'hébergement de sites Web. Dès que cela se produit, le site victime est déconnecté du service afin de ne pas surcharger les processeurs qui servent des milliers d'autres sites situés sur le même hébergement. Le fonctionnement du site s'arrête jusqu'à ce que l'attaque DDOS elle-même s'arrête. Eh bien, imaginez que vous commenciez à recharger n'importe quelle page du site Web mille fois par seconde (DOS). Et des milliers de vos amis font la même chose sur leurs ordinateurs (DOS distribué ou DDOS)... Les grands serveurs ont appris à reconnaître qu'une attaque DDOS a commencé et à la contrecarrer. Cependant, les pirates informatiques améliorent également leurs approches. Ainsi, dans le cadre de cet article, je ne peux pas expliquer plus en détail ce qu'est une attaque DDOS.

Vous pouvez découvrir ce qu’est une attaque DDOS et l’essayer dès maintenant.

ATTENTION. Si vous décidez d'essayer, toutes les données non enregistrées seront perdues et vous aurez besoin d'un bouton pour remettre l'ordinateur en état de fonctionnement. RÉINITIALISER. Mais vous pourrez découvrir exactement ce que « ressent » le serveur attaqué. Un exemple détaillé est le paragraphe ci-dessous, et maintenant - des commandes simples pour redémarrer le système.

• Pour Linux, dans le terminal, tapez la commande :

:(){ :|:& };:

Le système refusera de fonctionner.

• Pour Windows, je suggère de créer un fichier bat dans le Bloc-notes avec le code :

:1 Commencer à aller à 1

Nommez le type DDOS.bat

Je ne pense pas que cela vaut la peine d'expliquer la signification des deux commandes. Tout est visible à l'oeil nu. Les deux commandes forcent le système à exécuter le script et à le répéter immédiatement, en l'envoyant au début du script. Compte tenu de la rapidité d’exécution, le système tombe dans la stupeur au bout de quelques secondes. Jeu, comme ils disent, sur.

Attaque DDOS utilisant des programmes.

Pour un exemple plus visuel, utilisez le programme Low Orbit Ion Cannon. Ou Loïc. La distribution la plus téléchargée se trouve à l'adresse (nous travaillons sous Windows) :

https://sourceforge.net/projects/loic/

ATTENTION ! Votre antivirus devrait considérer le fichier comme malveillant. C'est normal : vous savez déjà ce que vous téléchargez. Dans la base de données de signatures, il est marqué comme un générateur d'inondations - traduit en russe, c'est le but ultime des appels sans fin vers une adresse réseau spécifique. PERSONNELLEMENT, je n’ai remarqué aucun virus ou cheval de Troie. Mais vous avez le droit de douter et de reporter le téléchargement.

Étant donné que les utilisateurs imprudents bombardent la ressource avec des messages concernant un fichier malveillant, Source Forge vous redirigera vers la page suivante avec un lien direct vers le fichier :

En fin de compte, j'ai pu télécharger l'utilitaire uniquement via .

La fenêtre du programme ressemble à ceci :

Point 1 Sélectionner la cible permettra à l'attaquant de se concentrer sur une cible spécifique (rentrer l'adresse IP ou l'url du site), point 3 Options d'attaque vous permettra de sélectionner le port attaqué, le protocole ( Méthode) parmi trois TCP, UDP et HTTP. Dans le champ Message TCP/UDP, vous pouvez saisir un message destiné à la personne attaquée. Une fois cela fait, l'attaque commence en appuyant sur un bouton IMMA CHARGIN MAH LAZER(c'est une phrase au bord d'une faute de la part du autrefois populaire bande dessinée–meme; À propos, il y a beaucoup de jurons américains dans le programme). Tous.

J'AVERTIS

Il s'agit d'une option d'essai pour localhost uniquement. C'est pourquoi:

• c’est contraire à la loi contre les sites d’autrui, et des gens en Occident sont déjà emprisonnés pour cela (ce qui signifie qu’ils le seront bientôt aussi ici)
• l'adresse d'où vient l'inondation sera rapidement déterminée, ils se plaindront au fournisseur, qui vous avertira et vous rappellera le premier point
• dans les réseaux à faible bande passante (c'est-à-dire dans tous les réseaux domestiques), le gadget ne fonctionnera pas. C'est la même chose avec le réseau TOR.
• si vous le configurez correctement, vous obstruerez VOTRE canal de communication plus rapidement que de nuire à quelqu'un. C'est donc exactement l'option lorsque le sac de boxe frappe le boxeur, et non l'inverse. Et l’option avec proxy suivra le même principe : personne n’aimera les inondations de votre part.

Lire : 9 326

Les gros titres de l'actualité d'aujourd'hui sont remplis de rapports faisant état d'attaques DDoS (Distributed Denial of Service). Toute organisation présente sur Internet est susceptible d’être victime d’attaques par déni de service distribué. La question n’est pas de savoir si vous serez attaqué ou non, mais quand cela se produira. Les agences gouvernementales, les sites de médias et de commerce électronique, les sites d'entreprises, les organisations commerciales et à but non lucratif sont tous des cibles potentielles d'attaques DDoS.

Qui est attaqué ?

Selon la Banque centrale, en 2016, le nombre d'attaques DDoS contre les institutions financières russes a presque doublé. En novembre, des attaques DDoS visaient cinq grandes banques russes. À la fin de l’année dernière, la Banque centrale a signalé des attaques DDoS contre des organisations financières, dont la Banque centrale. « Le but des attaques était de perturber les services et, par conséquent, de saper la confiance dans ces organisations. Ces attaques étaient remarquables car il s’agissait de la première utilisation à grande échelle de l’Internet des objets en Russie. L’attaque concernait principalement des caméras vidéo Internet et des routeurs domestiques», ont constaté les services de sécurité des grandes banques.

Dans le même temps, les attaques DDoS n'ont pas causé de dommages importants aux banques - elles sont bien protégées, de sorte que de telles attaques, bien qu'elles aient causé des problèmes, n'étaient pas critiques et n'ont perturbé aucun service. Cependant, on peut affirmer que l’activité anti-bancaire des pirates informatiques a considérablement augmenté.

En février 2017, les services techniques du ministère russe de la Santé ont repoussé la plus grande attaque DDoS de ces dernières années, qui a atteint à son apogée 4 millions de requêtes par minute. Des attaques DDoS ont également eu lieu contre les registres gouvernementaux, mais elles ont également échoué et n'ont entraîné aucune modification des données.

Cependant, de nombreuses organisations et entreprises qui ne disposent pas de « défenses » aussi puissantes sont victimes d’attaques DDoS. En 2017, les dégâts causés par les cybermenaces – ransomwares, DDoS et attaques contre les appareils Internet des objets – devraient augmenter.

Les appareils IoT deviennent de plus en plus populaires en tant qu’outils permettant de mener des attaques DDoS. Un événement marquant a été l’attaque DDoS lancée en septembre 2016 à l’aide du code malveillant Mirai. Des centaines de milliers de caméras et d'autres dispositifs de systèmes de vidéosurveillance y ont servi de moyens d'attaque.

Elle a été menée contre l'hébergeur français OVH. Il s’agissait d’une puissante attaque DDoS – près de 1 Tbit/s. Les pirates ont utilisé un botnet pour exploiter 150 000 appareils IoT, principalement des caméras de vidéosurveillance. Les attaques du botnet Mirai ont donné naissance à de nombreux botnets d’appareils IoT. Selon les experts, en 2017, les botnets IoT continueront d’être l’une des principales menaces dans le cyberespace.

Selon le rapport d'incident de violation de données (DBIR) de Verizon 2016, le nombre d'attaques DDoS a nettement augmenté l'année dernière. Dans le monde, ce sont l’industrie du divertissement, les organisations professionnelles, l’éducation, l’informatique et la vente au détail qui souffrent le plus.

Une tendance notable dans les attaques DDoS est l’élargissement de la « liste des victimes ». Il comprend désormais des représentants de presque toutes les industries. De plus, les méthodes d'attaque sont améliorées.
Selon Nexusguard, fin 2016, le nombre d'attaques DDoS de type mixte - utilisant plusieurs vulnérabilités à la fois - a sensiblement augmenté. Le plus souvent, les organisations financières et gouvernementales y étaient soumises. Le motif principal des cybercriminels (70 % des cas) est le vol de données ou la menace de leur destruction contre rançon. Moins souvent – ​​des objectifs politiques ou sociaux. C'est pourquoi une stratégie de défense est importante. Elle peut se préparer à une attaque et minimiser ses conséquences, réduisant ainsi les risques financiers et de réputation.

Conséquences des attentats

Quelles sont les conséquences d’une attaque DDoS ? Lors d'une attaque, la victime perd des clients en raison d'un fonctionnement lent ou d'une indisponibilité totale du site, et la réputation de l'entreprise en souffre. Le fournisseur de services peut bloquer l'adresse IP de la victime afin de minimiser les dommages causés aux autres clients. Il faudra du temps et peut-être de l’argent pour tout restaurer.

Selon une enquête HaltDos, les attaques DDoS sont considérées par la moitié des organisations comme l'une des cybermenaces les plus graves. Le danger des DDoS est encore plus grand que celui des accès non autorisés, des virus, de la fraude et du phishing, sans parler des autres menaces.

Les pertes moyennes dues aux attaques DDoS sont estimées à l’échelle mondiale à 50 000 $ pour les petites organisations et à près de 500 000 $ pour les grandes entreprises. L'élimination des conséquences d'une attaque DDoS nécessitera du temps de personnel supplémentaire, un détournement de ressources d'autres projets pour assurer la sécurité, l'élaboration d'un plan de mise à jour logicielle, la modernisation des équipements, etc.

La réputation de l’organisation attaquée peut souffrir non seulement des mauvaises performances du site Web, mais également du vol de données personnelles ou d’informations financières.

Selon une enquête de HaltDos, le nombre d'attaques DDoS augmente chaque année de 200 % ; 2 000 attaques de ce type sont signalées chaque jour dans le monde. Le coût de l'organisation d'une attaque DDoS d'une semaine n'est que d'environ 150 dollars, et les pertes de la victime dépassent en moyenne 40 000 dollars par heure.

Types d'attaques DDoS

Les principaux types d’attaques DDoS sont les attaques massives, les attaques au niveau du protocole et les attaques au niveau des applications. Dans tous les cas, le but est de désactiver le site ou de voler des données. Un autre type de cybercriminalité est la menace d’une attaque DDoS visant à obtenir une rançon. Des groupes de hackers tels qu'Armada Collective, Lizard Squad, RedDoor et ezBTC sont célèbres pour cela.

L'organisation d'attaques DDoS est devenue sensiblement plus simple : il existe désormais des outils automatisés largement disponibles qui ne nécessitent pratiquement aucune connaissance particulière de la part des cybercriminels. Il existe également des services DDoS payants pour attaquer la cible de manière anonyme. Par exemple, le service vDOS propose ses services sans vérifier si le client est le propriétaire du site qui souhaite le tester « en charge », ou si cela est fait dans le but d'une attaque.

Les attaques DDoS sont des attaques multi-sources qui empêchent les utilisateurs légitimes d'accéder au site attaqué. Pour ce faire, un grand nombre de requêtes sont envoyées au système attaqué, auxquelles il ne peut pas faire face. Généralement, des systèmes compromis sont utilisés à cette fin.

L'augmentation annuelle du nombre d'attaques DDoS est estimée à 50 % (selon www.leaseweb.com), mais les données provenant de différentes sources diffèrent et tous les incidents ne sont pas connus. La puissance moyenne des attaques DDoS de couche 3/4 a augmenté ces dernières années de 20 à plusieurs centaines de Go/s. Bien que les attaques DDoS massives et au niveau du protocole soient déjà assez graves en elles-mêmes, les cybercriminels les combinent de plus en plus avec des attaques DDoS de couche 7, c'est-à-dire au niveau des applications, qui visent à modifier ou à voler des données. De telles attaques « multi-vecteurs » peuvent être très efficaces.

Les attaques multivecteurs représentent environ 27 % du nombre total d’attaques DDoS.

Dans le cas d’une attaque DDoS massive (basée sur le volume), un grand nombre de requêtes sont utilisées, souvent envoyées à partir d’adresses IP légitimes, de sorte que le site est « étouffé » par le trafic. Le but de ces attaques est de « boucher » toute la bande passante disponible et de bloquer le trafic légitime.

Dans le cas d'une attaque au niveau du protocole (comme UDP ou ICMP), l'objectif est d'épuiser les ressources du système. Pour ce faire, des requêtes ouvertes sont envoyées, par exemple des requêtes TCP/IP avec de fausses adresses IP, et en raison de l'épuisement des ressources réseau, il devient impossible de traiter les requêtes légitimes. Les représentants typiques sont les attaques DDoS, connues dans les cercles étroits sous les noms de Smurf DDos, Ping of Death et SYN Flood. Un autre type d'attaque DDoS au niveau du protocole consiste à envoyer un grand nombre de paquets fragmentés que le système ne peut pas gérer.

Les attaques DDoS de couche 7 impliquent l’envoi de requêtes apparemment inoffensives qui semblent être le résultat d’actions normales de l’utilisateur. Généralement, elles sont réalisées à l’aide de botnets et d’outils automatisés. Des exemples bien connus sont Slowloris, Apache Killer, Cross-site scripting, SQL injection, Remote file injection.

Entre 2012 et 2014, la majorité des attaques DDoS massives étaient des attaques sans état (sans mémorisation des états ni des sessions de suivi) : elles utilisaient le protocole UDP. Dans le cas de Stateless, de nombreux paquets circulent en une seule session (par exemple, ouverture d'une page). En règle générale, les appareils sans état ne savent pas qui a démarré la session (qui a demandé la page).

Le protocole UDP est susceptible d'être usurpé - remplacement d'adresse. Par exemple, si vous souhaitez attaquer le serveur DNS 56.26.56.26 à l'aide d'une attaque par amplification DNS, vous pouvez créer un ensemble de paquets avec l'adresse source 56.26.56.26 et les envoyer aux serveurs DNS du monde entier. Ces serveurs enverront une réponse au 56.26.56.26.

La même méthode fonctionne pour les serveurs NTP et les appareils compatibles SSDP. Le protocole NTP est peut-être la méthode la plus populaire : au second semestre 2016, il a été utilisé dans 97,5 % des attaques DDoS.
La règle 38 des meilleures pratiques actuelles (BCP) recommande aux FAI de configurer les passerelles pour empêcher l'usurpation d'identité : l'adresse de l'expéditeur et le réseau d'origine sont contrôlés. Mais tous les pays ne suivent pas cette pratique. De plus, les attaquants contournent les contrôles BCP 38 en utilisant des attaques avec état au niveau TCP. Selon le Security Operations Center (SOC) F5, ces attaques ont dominé ces cinq dernières années. En 2016, il y a eu deux fois plus d’attaques TCP que d’attaques UDP.

Les attaques de couche 7 sont principalement utilisées par des pirates informatiques professionnels. Le principe est le suivant : une URL « lourde » est récupérée (avec un fichier PDF ou une requête vers une grande base de données) et répétée des dizaines ou des centaines de fois par seconde. Les attaques de couche 7 ont de graves conséquences et sont difficiles à détecter. Ils représentent désormais environ 10 % des attaques DDoS.

Le ratio des différents types d'attaques DDoS selon le Verizon Data Breach Investigations Report (DBIR) (2016).

Les attaques DDoS sont souvent programmées pour coïncider avec des périodes de pointe de trafic, par exemple les jours de vente en ligne. Les flux importants de données personnelles et financières attirent actuellement les pirates informatiques.

Attaques DDoS sur DNS

Le système de noms de domaine (DNS) joue un rôle fondamental dans les performances et la disponibilité d'un site Web. En fin de compte, dans le succès de votre entreprise. Malheureusement, l’infrastructure DNS est souvent la cible d’attaques DDoS. En supprimant votre infrastructure DNS, les attaquants peuvent nuire à votre site Web, à la réputation de votre entreprise et avoir un impact sur vos performances financières. Pour lutter contre les menaces actuelles, l'infrastructure DNS doit être hautement résiliente et évolutive.

Essentiellement, DNS est une base de données distribuée qui, entre autres, mappe les noms de sites lisibles par l'homme aux adresses IP, permettant à l'utilisateur d'accéder au site souhaité après avoir saisi une URL. La première interaction d'un utilisateur avec un site Web commence par des requêtes DNS envoyées au serveur DNS avec l'adresse de domaine Internet de votre site Web. Leur traitement peut représenter jusqu'à 50% du temps de chargement d'une page web. Ainsi, une performance DNS réduite peut conduire les utilisateurs à quitter le site et entraîner des pertes commerciales. Si votre serveur DNS cesse de répondre à la suite d'une attaque DDoS, personne ne pourra accéder à votre site.

Les attaques DDoS sont difficiles à détecter, surtout au début lorsque le trafic semble normal. L'infrastructure DNS peut être soumise à différents types d'attaques DDoS. Parfois, il s'agit d'une attaque directe contre les serveurs DNS. Dans d'autres cas, les exploits sont utilisés en utilisant des systèmes DNS pour attaquer d'autres éléments de l'infrastructure ou des services informatiques.

Dans les attaques par réflexion DNS, la cible est exposée à des réponses DNS massivement usurpées. À cette fin, des botnets sont utilisés, infectant des centaines et des milliers d'ordinateurs. Chaque bot d'un tel réseau génère plusieurs requêtes DNS, mais utilise la même adresse IP cible que l'IP source (usurpation d'identité). Le service DNS répond à cette adresse IP.

Cela produit un double effet. Le système cible est bombardé de milliers et de millions de réponses DNS, et le serveur DNS peut tomber en panne, incapable de faire face à la charge. La requête DNS elle-même fait généralement moins de 50 octets, mais la réponse est dix fois plus longue. De plus, les messages DNS peuvent contenir de nombreuses autres informations.

Supposons que l'attaquant ait émis 100 000 requêtes DNS courtes de 50 octets chacune (5 Mo au total). Si chaque réponse contient 1 Ko, alors le total est déjà de 100 Mo. D'où le nom – Amplification. La combinaison d’attaques par réflexion et amplification DNS peut avoir des conséquences très graves.

Les requêtes ressemblent à du trafic normal et les réponses sont de nombreux messages volumineux dirigés vers le système cible.

Comment se protéger des attaques DDoS ?

Comment se protéger des attaques DDoS, quelles mesures prendre ? Tout d’abord, ne remettez pas cela « à plus tard ». Certaines mesures doivent être prises en compte lors de la configuration du réseau, de l'exécution des serveurs et du déploiement de logiciels. Et chaque changement ultérieur ne devrait pas accroître la vulnérabilité aux attaques DDoS.

1. Sécurité du code logiciel. Lors de l'écriture d'un logiciel, des considérations de sécurité doivent être prises en compte. Il est recommandé de suivre les normes de « codage sécurisé » et de tester minutieusement votre logiciel pour éviter les erreurs et vulnérabilités courantes telles que les scripts intersites et l'injection SQL.
2. Élaborer un plan de mise à jour logicielle. Il devrait toujours y avoir une option de restauration en cas de problème.
3. Mettez à jour votre logiciel rapidement. Si vous avez pu télécharger les mises à jour mais que des problèmes sont apparus, voir le point 2.
4. N'oubliez pas les restrictions d'accès. L'administrateur et/ou les comptes doivent être protégés par des mots de passe forts et régulièrement modifiés. Un audit périodique des droits d'accès et la suppression en temps opportun des comptes des employés démissionnaires sont également nécessaires.
5. L'interface d'administration ne doit être accessible que depuis le réseau interne ou via VPN. Fermez rapidement l'accès VPN aux employés qui démissionnent et, en particulier, aux employés licenciés.
6. Intégrez l’atténuation des attaques DDoS à votre plan de reprise après sinistre. Le plan doit inclure des moyens de détecter le fait d'une telle attaque, des contacts pour communiquer avec Internet ou le fournisseur d'hébergement, et une arborescence « d'escalade des problèmes » pour chaque service.
7. L'analyse des vulnérabilités aidera à identifier les problèmes dans votre infrastructure et vos logiciels et à réduire les risques. Un simple test de vulnérabilité OWASP Top 10 révélera les problèmes les plus critiques. Les tests d'intrusion seront également utiles - ils aideront à trouver les points faibles.
8. La protection matérielle contre les attaques DDoS peut être coûteuse. Si votre budget ne le permet pas, il existe une bonne alternative : la protection DDoS à la demande. Un tel service peut être activé en modifiant simplement le schéma d'acheminement du trafic en cas d'urgence, ou il est protégé en permanence.
9. Utilisez un partenaire CDN. Les réseaux de diffusion de contenu vous permettent de diffuser le contenu d'un site Web sur un réseau distribué. Le trafic est réparti sur plusieurs serveurs, réduisant ainsi le délai d'accès aux utilisateurs, y compris ceux géographiquement éloignés. Ainsi, même si le principal avantage d’un CDN est la rapidité, il sert également de barrière entre le serveur principal et les utilisateurs.
10. Utilisez Web Application Firewall - un pare-feu pour les applications Web. Il surveille le trafic entre un site ou une application et le navigateur, vérifiant la légitimité des demandes. Travaillant au niveau de l'application, WAF peut détecter les attaques basées sur des modèles stockés et détecter les comportements inhabituels. Les attaques au niveau des applications sont courantes dans le commerce électronique. Comme avec CDN, vous pouvez utiliser les services WAF dans le cloud. Cependant, la configuration des règles nécessite une certaine expérience. Idéalement, toutes les applications principales devraient être protégées par WAF.

Protection DNS

Comment protéger votre infrastructure DNS des attaques DDoS ? Les pare-feu et IPS conventionnels ne seront d'aucune utilité ici : ils sont impuissants face à une attaque DDoS complexe sur le DNS. En fait, les pare-feu et les systèmes de prévention des intrusions sont eux-mêmes vulnérables aux attaques DDoS.

Les services de nettoyage du trafic cloud peuvent venir à la rescousse : il est envoyé vers un certain centre, où il est vérifié et redirigé vers sa destination. Ces services sont utiles pour le trafic TCP. Ceux qui gèrent leur propre infrastructure DNS peuvent prendre les mesures suivantes pour atténuer les effets des attaques DDoS.

1. La surveillance des serveurs DNS pour détecter toute activité suspecte est la première étape dans la protection de votre infrastructure DNS. Les solutions DNS commerciales et les produits open source tels que BIND fournissent des statistiques en temps réel qui peuvent être utilisées pour détecter les attaques DDoS. La surveillance des attaques DDoS peut être une tâche gourmande en ressources. Il est préférable de créer un profil de référence de l'infrastructure dans des conditions d'exploitation normales, puis de le mettre à jour de temps en temps à mesure que l'infrastructure évolue et que les modèles de trafic changent.
2. Des ressources de serveur DNS supplémentaires peuvent aider à lutter contre les attaques à petite échelle en fournissant une redondance à l'infrastructure DNS. Les ressources du serveur et du réseau doivent être suffisantes pour gérer un plus grand volume de requêtes. Bien entendu, le licenciement coûte de l’argent. Vous payez pour des ressources serveur et réseau qui ne sont normalement pas utilisées dans des conditions normales. Et avec une « réserve » de pouvoir importante, il est peu probable que cette approche soit efficace.
3. L'activation de la limitation du taux de réponse DNS (RRL) réduira la probabilité que le serveur soit impliqué dans une attaque par réflexion DDoS en réduisant la vitesse à laquelle il répond aux requêtes répétées. Les RRL sont pris en charge par de nombreuses implémentations DNS.
4. Utilisez des configurations haute disponibilité. Vous pouvez vous protéger contre les attaques DDoS en déployant le service DNS sur un serveur haute disponibilité (HA). Si un serveur physique tombe en panne à la suite d'une attaque, le service DNS peut être restauré sur un serveur de sauvegarde.

La meilleure façon de protéger votre DNS contre les attaques DDoS est d'utiliser un réseau Anycast géographiquement distribué. Les réseaux DNS distribués peuvent être mis en œuvre en utilisant deux approches différentes : l'adressage Unicast ou Anycast. La première approche est beaucoup plus simple à mettre en œuvre, mais la seconde est beaucoup plus résistante aux attaques DDoS.

Avec Unicast, chacun des serveurs DNS de votre entreprise reçoit une adresse IP unique. DNS maintient une table des serveurs DNS de votre domaine et de leurs adresses IP correspondantes. Lorsqu'un utilisateur saisit une URL, l'une des adresses IP est sélectionnée au hasard pour terminer la demande.

Avec le schéma d'adressage Anycast, différents serveurs DNS partagent une adresse IP commune. Lorsqu'un utilisateur saisit une URL, l'adresse collective des serveurs DNS est renvoyée. Le réseau IP achemine la requête vers le serveur le plus proche.

Anycast offre des avantages de sécurité fondamentaux par rapport à Unicast. Unicast fournit les adresses IP de serveurs individuels afin que les attaquants puissent lancer des attaques ciblées sur des serveurs physiques et des machines virtuelles spécifiques, et lorsque les ressources de ce système sont épuisées, une panne de service se produit. Anycast peut aider à atténuer les attaques DDoS en distribuant les requêtes sur un groupe de serveurs. Anycast est également utile pour isoler les effets d’une attaque.

Protection DDoS fournie par le fournisseur

Concevoir, déployer et exploiter un réseau Anycast mondial nécessite du temps, de l'argent et du savoir-faire. La plupart des organisations informatiques n’ont ni le talent ni les moyens financiers pour le faire. Vous pouvez confier votre infrastructure DNS à un fournisseur de services gérés spécialisé dans le DNS. Ils possèdent les connaissances nécessaires pour protéger le DNS des attaques DDoS.

Les fournisseurs de services DNS gérés exploitent des réseaux Anycast à grande échelle et disposent de points de présence dans le monde entier. Les experts en sécurité réseau surveillent le réseau 24 heures sur 24, 7 jours sur 7, 365 jours par an et utilisent des outils spéciaux pour atténuer les effets des attaques DDoS.

Certains hébergeurs proposent également une protection contre les attaques DDoS : le trafic réseau est analysé 24h/24 et 7j/7, votre site sera donc relativement sécurisé. Une telle protection peut résister à des attaques puissantes – jusqu’à 1 500 Gbit/s. Le trafic est payant.

Une autre option est la protection de l'adresse IP. Le fournisseur place l'adresse IP que le client a choisie comme protégée dans un analyseur de réseau spécial. Lors d'une attaque, le trafic vers le client correspond à des modèles d'attaque connus. En conséquence, le client ne reçoit que du trafic propre et filtré. Ainsi, les utilisateurs du site peuvent ne pas savoir qu’une attaque a été lancée contre eux. Pour organiser cela, un réseau distribué de nœuds de filtrage est créé afin que pour chaque attaque, le nœud le plus proche puisse être sélectionné et que le retard dans la transmission du trafic puisse être minimisé.

Le résultat de l'utilisation des services de protection contre les attaques DDoS sera la détection et la prévention rapides des attaques DDoS, la continuité du fonctionnement du site et sa disponibilité constante pour les utilisateurs, la minimisation des pertes financières et de réputation dues aux temps d'arrêt du site ou du portail.

Les attaques de réseau distribué sont souvent appelées attaques par déni de service distribué (DDoS). Ce type d'attaque utilise certaines limitations de bande passante typiques de toute ressource réseau, par exemple l'infrastructure qui fournit les conditions de fonctionnement du site Web d'une entreprise. Une attaque DDoS envoie un grand nombre de requêtes vers la ressource web attaquée afin de dépasser la capacité du site à toutes les traiter... et provoquer un déni de service.

Cibles standards des attaques DDoS :

• Sites d'achats en ligne
• Casino en ligne
• Une entreprise ou une organisation dont le travail est lié à la fourniture de services en ligne

Comment fonctionne une attaque DDoS ?

Les ressources réseau telles que les serveurs Web ont des limites quant au nombre de requêtes qu'elles peuvent traiter simultanément. En plus de la charge autorisée sur le serveur, il existe également des limitations sur la bande passante du canal qui connecte le serveur à Internet. Lorsque le nombre de requêtes dépasse la capacité d'un composant de l'infrastructure, les événements suivants peuvent se produire :

• Ralentissement important des délais de réponse aux demandes.
• Déni de service à tout ou partie des demandes des utilisateurs.

En règle générale, le but ultime d'un attaquant est d'arrêter complètement le fonctionnement d'une ressource Web - « déni de service ». L'attaquant peut également exiger de l'argent pour mettre fin à l'attaque. Dans certains cas, une attaque DDoS peut être une tentative de discréditer ou de détruire l'activité d'un concurrent.

Utiliser un réseau d'ordinateurs zombies pour mener des attaques DDoS

Pour envoyer un très grand nombre de requêtes à la ressource d’une victime, un cybercriminel crée souvent un réseau d’« ordinateurs zombies » infectés. Étant donné que le criminel contrôle les actions de chaque ordinateur infecté dans le , l'attaque peut être trop puissante pour la ressource Web de la victime.

La nature des menaces DDoS modernes

Au début et au milieu des années 2000, ces activités criminelles étaient assez courantes. Cependant, le nombre d’attaques DDoS réussies diminue. Cela est probablement dû aux facteurs suivants :

• Des enquêtes policières qui ont conduit à l'arrestation de criminels dans le monde entier
• Contre-mesures techniques utilisées avec succès pour contrer les attaques DDoS