- Accueil
- Tous les articles
- Par catégorie
- Les plus récents
- Hacking 101
- Blog
- Vers le vrai hacking
- Sources exemples
Dénis de Service
| << La couche de liaison de données | Le scanning avancé >> |
I°) Les Denial of Service (DoS)
Notre but n'est pas de fournir des outils tout prêts à utiliser afin d'effectuer des DoS performants. Ceci dit, il nous paraît important de se familiariser avec les techniques de détournement de TCP/IP (TCP/IP Hijack), c'est pourquoi nous allons ici vous exposer brièvement la théorie de certaines techniques de Déni de Service. Une attaque de type DoS vise tout simplement à empêcher la victime (un poste personnel, un réseau) de communiquer, c'est-à-dire l'isoler, en le faisant crasher ou en lui envoyant beaucoup plus de requêtes qu'il n'est capable de traiter afin de remplir sa bande passante (Flood). Voici donc 6 DoS très communs.
Communications radio
Les communications radio (Wifi, Bluetooth, etc.) sont intrinsèquement très différentes des communications filaires classiques, et ce à plusieurs égards :
Le ping de la mort
Dans les spécifications du protocole ICMP, les paquets echo n'ont été conçus que pour contenir 216 octets de données dans le corps du paquet. A vrai dire, cela importe peu, puisque dans le cas des requêtes et réponses ICMP, seuls les en-têtes importent, aucun réel message n'est nécessaire. Un DoS très connu est simplement l'utilisation de minimum 65 537 (= 216 + 1) octets de données. Le système recevant le message paniquera à la réception du paquet et crashera. Cette attaque est très ancienne et connue comme The Ping of Death. Seuls les systèmes relativement anciens sont affectés par cette attaque car elle a bien sûr été patchée depuis. Ceci dit, elle illustre très bien comment les personnes ayant conçu ces systèmes ne se préparaient pas à l'éventualité que quelqu'un puisse sortir du protocole attendu.
Le ping-flood
Cette attaque est la plus commune et la plus connue. Cette fois, on ne veut pas crasher l'ordinateur distant mais le saturer, de façon à ce qu'il ne puisse plus communiquer. Les attaques de flood TCP/IP essaient de simplement surcharger la bande passante sur le réseau de la machine concerner et ainsi l'isoler. En pratique, cette attaque consiste juste à envoyer beaucoup de requêtes PING à la victime, avec des paquets contenant beaucoup de données. Cette attaque n'a rien de spécialement intelligente car elle se résume à un combat entre bandes passantes, et que la meilleure gagne..
Les attaques amplifiées
A ce stade, l'utilisation de TCP commence à devenir intéressante. Les attaques amplifiées sont juste une façon d'exploiter des floods, mais intelligemment. Nous avons parlé dans notre article sur l'adressage dans la couche liaison de données d'une adresse spéciale, la broadcast. Cette adresse donne la possibilité d'envoyer un paquet à toutes les machines connectées au réseau. Ainsi, si on envoie une requête PING à la broadcast, tous les systèmes connectés nous enverrons un paquet ICMP reply en retour. Comme se flooder soi-même n'est pas d'une immense utilité, il faut trouver un moyen de faire répondre tous ces systèmes à qui on l'entend, car cela représente un gros potentiel. La solution est simple : envoyer un paquet PING echo spoofé contenant l'adresse de la victime comme source et la broadcast comme destinataire. Ainsi, chaque système du réseau recevra un ping qu'ils croieront venir de la machine de la victime et y répondront. En envoyant beaucoup de paquets spoofés, la bande passante de la victime est prise d'assaut de manière exponentielle avec le nombre de systèmes connectés au réseau.
Une manière de se prémunir de ces attaques est d'interdir les pings sur la broadcast ou de ne les rerouter que vers le serveur principal, ce qui est couramment effectué dans les grands réseaux (universités, entreprises). Cette attaque s'appelle communément un smurf.
Le flood DDoS (Distributed Denial of Service)
Comme nous l'avons fait remarquer pour l'attaque de type ping-flood, le flooding revient à un combat entre bandes passantes. L'idée du Déni de Service Distribué est simple et rejoint celle du smurf, à savoir, pourquoi faire le combat tout seul et pas à plusieurs ? Effectivement, plus il y a d'ordinateurs qui floodent une seule machine ou un seul réseau, plus ça devient facile de saturer sa bande passante, toute immense qu'elle puisse être. Les attaques de flood les plus remarquables de ces années suivent ce principe, on peut notamment nommer l'attaque des 13 root servers (les serveurs qui maintiennent l'Internet) en Février 2007. Cette attaque avait été particulièrement simple : environ 5 000 machines ont submergé les root servers de requêtes DNS et UDP. Au moins 2 serveurs sont tombés dans cette nuit du 6 au 7 Février et au moins 3 autres ont étés saturés, ce qui s'est ressenti parfois par un très léger lag sur l'Internet. Vous nous direz que rassembler 5 000 machines n'est pas à la portée du premier venu. Et bien si. En fait, ces machines ne sont autres que des machines lambda, comme vous ou moi qui ont étés affectés par un virus, reproducteur, qui est resté silencieux sur tous ces postes jusqu'à ce que leur "maître" leur demande de passer à l'action. Tous les postes infectés étaient sous Windows et plus de 65% en Corée du Sud, ce qui laisse penser que là-bas se trouvait le chef-lieu de l'attaque. De plus, utiliser autant d'ordinateurs à la fois permet naturellement de rendre quasiment impossible le traçage de la source du flood.
Le SYN flood
Cette manière d'exploiter TCP/IP est beaucoup plus maligne. Elle se sert d'une limitation obligatoire du protocole : la pile TCP/IP. Comme un ordinateur doit connaître l'état des connexions en cours pour pouvoir notamment les maintenir ou les établir, il faut stocker les informations (notamment numéros de reconnaissance et de session) quelque part, c'est ce qu'on appelle la pile TCP/IP. Or, il est bien sûr impossible d'avoir une pile TCP/IP infinie, par conséquent le nombre d'initialisations de connexion que peut surveiller un simple ordinateur est limité. Ainsi, l'attaquant floode la victime avec beaucoup de paquets SYN spoofés (d'adresses prises au hasard). La victime va donc répondre à ces paquets SYN par un paquet ACK/SYN en attente d'un paquet ACK, comme la coutume le veut. Puisque les réponses ne viendront pas, la machine gardera dans la pile les informations sur chaque host qui a demandé l'initialisation d'une connexion. Pour que ces connexions soient enlevées de la queue, il faut qu'elles timeout, ce qui prendre relativement longtemps. Par conséquent, tant que l'attaquant continue l'envoi des paquets SYN, aucune autre réelle connexion ne pourra parvenir à la cible et elle sera isolée.
De la même façon que ces attaques se servent du protocole TCP pour mener à bien leurs objectifs malveillants, il est possible de scanner un ordinateur de façon beaucoup plus savante que celle utilisée par les scanners classiques (vérification de l'établissement d'une connexion TCP/IP), c'est ce que nous nous proposons de vous expliquer maintenant.
Notre but n'est pas de fournir des outils tout prêts à utiliser afin d'effectuer des DoS performants. Ceci dit, il nous paraît important de se familiariser avec les techniques de détournement de TCP/IP (TCP/IP Hijack), c'est pourquoi nous allons ici vous exposer brièvement la théorie de certaines techniques de Déni de Service. Une attaque de type DoS vise tout simplement à empêcher la victime (un poste personnel, un réseau) de communiquer, c'est-à-dire l'isoler, en le faisant crasher ou en lui envoyant beaucoup plus de requêtes qu'il n'est capable de traiter afin de remplir sa bande passante (Flood). Voici donc 6 DoS très communs.
Communications radio
Les communications radio (Wifi, Bluetooth, etc.) sont intrinsèquement très différentes des communications filaires classiques, et ce à plusieurs égards :
-
- Tout d'abord, le medium. En effet, les communications transitent via ondes radio, dans l'air, en utilisant
une gamme de fréquence précise (2,4 GHz). Lorsqu'un signal est traité, il est modulé puis démodulé afin de
n'extraire que les fréquences intéressantes, mais ne nous y attardons pas, un cours de physique sur le sujet
serait plus adapté. Ce qu'il faut comprendre, c'est que lorsqu'une onde se propage dans l'air et qu'elle en
rencontre une autre, les signaux se mélangent (s'additionnent, se soustraient selon la valeur nominale). Encore
une fois, loin des équation de physique, on se rend bien compte qu'un bruitage radio dans la fréquence observée
va totalement fausser le medium et les données reçues. Par conséquent, les communications wifi sont à la base
non-sûres puisque la création d'un champ électromagnétique peut mettre fin à toute possibilité de communication.
- Soit, chacun n'a pas son antenne et son modulateur sur soi. Ceci dit, il peut également être intéressant de se pencher sur les mécanismes de communication en Wifi. En effet, puisque le medium doit être libre, il est important qu'un seul ordinateur ne parle à la fois. De ce fait, les acteurs doivent se mettre d'accord sur un ordonnancement. En général, les protocoles de type CSMA (Carrier Sense Multiple Access) sont utilisés. Ils proposent plusieurs mécanismes, parmi lesquels l'émission de préambules avant le début du message (si un noeud veut envoyer alors que quelqu'un est déjà en train d'envoyer un préambule, il attend la fin du message) ou les mécanismes RTS/CTS (Request/Clear To Send) permettant respectivement de demander le medium et de l'accorder. Quoiqu'il en soit, ces mécanismes reposent sur la bienveillance des participants. Si, à l'aide d'une carte Wifi traditionnelle, est implémenté un CSMA malveillant, permettant de ne pas respecter les temps d'accès au medium des autres participants, beaucoup de collisions auront lieu, rendant impossible toute communication (d'autant plus qu'un paquet en Wifi doit être envoyé/reçu dans son intégralité pour pouvoir être lu correctement, donc chaque réémission portera sur l'ensemble du paquet).
Le ping de la mort
Dans les spécifications du protocole ICMP, les paquets echo n'ont été conçus que pour contenir 216 octets de données dans le corps du paquet. A vrai dire, cela importe peu, puisque dans le cas des requêtes et réponses ICMP, seuls les en-têtes importent, aucun réel message n'est nécessaire. Un DoS très connu est simplement l'utilisation de minimum 65 537 (= 216 + 1) octets de données. Le système recevant le message paniquera à la réception du paquet et crashera. Cette attaque est très ancienne et connue comme The Ping of Death. Seuls les systèmes relativement anciens sont affectés par cette attaque car elle a bien sûr été patchée depuis. Ceci dit, elle illustre très bien comment les personnes ayant conçu ces systèmes ne se préparaient pas à l'éventualité que quelqu'un puisse sortir du protocole attendu.
Le ping-flood
Cette attaque est la plus commune et la plus connue. Cette fois, on ne veut pas crasher l'ordinateur distant mais le saturer, de façon à ce qu'il ne puisse plus communiquer. Les attaques de flood TCP/IP essaient de simplement surcharger la bande passante sur le réseau de la machine concerner et ainsi l'isoler. En pratique, cette attaque consiste juste à envoyer beaucoup de requêtes PING à la victime, avec des paquets contenant beaucoup de données. Cette attaque n'a rien de spécialement intelligente car elle se résume à un combat entre bandes passantes, et que la meilleure gagne..
Les attaques amplifiées
A ce stade, l'utilisation de TCP commence à devenir intéressante. Les attaques amplifiées sont juste une façon d'exploiter des floods, mais intelligemment. Nous avons parlé dans notre article sur l'adressage dans la couche liaison de données d'une adresse spéciale, la broadcast. Cette adresse donne la possibilité d'envoyer un paquet à toutes les machines connectées au réseau. Ainsi, si on envoie une requête PING à la broadcast, tous les systèmes connectés nous enverrons un paquet ICMP reply en retour. Comme se flooder soi-même n'est pas d'une immense utilité, il faut trouver un moyen de faire répondre tous ces systèmes à qui on l'entend, car cela représente un gros potentiel. La solution est simple : envoyer un paquet PING echo spoofé contenant l'adresse de la victime comme source et la broadcast comme destinataire. Ainsi, chaque système du réseau recevra un ping qu'ils croieront venir de la machine de la victime et y répondront. En envoyant beaucoup de paquets spoofés, la bande passante de la victime est prise d'assaut de manière exponentielle avec le nombre de systèmes connectés au réseau.
Une manière de se prémunir de ces attaques est d'interdir les pings sur la broadcast ou de ne les rerouter que vers le serveur principal, ce qui est couramment effectué dans les grands réseaux (universités, entreprises). Cette attaque s'appelle communément un smurf.
Le flood DDoS (Distributed Denial of Service)
Comme nous l'avons fait remarquer pour l'attaque de type ping-flood, le flooding revient à un combat entre bandes passantes. L'idée du Déni de Service Distribué est simple et rejoint celle du smurf, à savoir, pourquoi faire le combat tout seul et pas à plusieurs ? Effectivement, plus il y a d'ordinateurs qui floodent une seule machine ou un seul réseau, plus ça devient facile de saturer sa bande passante, toute immense qu'elle puisse être. Les attaques de flood les plus remarquables de ces années suivent ce principe, on peut notamment nommer l'attaque des 13 root servers (les serveurs qui maintiennent l'Internet) en Février 2007. Cette attaque avait été particulièrement simple : environ 5 000 machines ont submergé les root servers de requêtes DNS et UDP. Au moins 2 serveurs sont tombés dans cette nuit du 6 au 7 Février et au moins 3 autres ont étés saturés, ce qui s'est ressenti parfois par un très léger lag sur l'Internet. Vous nous direz que rassembler 5 000 machines n'est pas à la portée du premier venu. Et bien si. En fait, ces machines ne sont autres que des machines lambda, comme vous ou moi qui ont étés affectés par un virus, reproducteur, qui est resté silencieux sur tous ces postes jusqu'à ce que leur "maître" leur demande de passer à l'action. Tous les postes infectés étaient sous Windows et plus de 65% en Corée du Sud, ce qui laisse penser que là-bas se trouvait le chef-lieu de l'attaque. De plus, utiliser autant d'ordinateurs à la fois permet naturellement de rendre quasiment impossible le traçage de la source du flood.
Le SYN flood
Cette manière d'exploiter TCP/IP est beaucoup plus maligne. Elle se sert d'une limitation obligatoire du protocole : la pile TCP/IP. Comme un ordinateur doit connaître l'état des connexions en cours pour pouvoir notamment les maintenir ou les établir, il faut stocker les informations (notamment numéros de reconnaissance et de session) quelque part, c'est ce qu'on appelle la pile TCP/IP. Or, il est bien sûr impossible d'avoir une pile TCP/IP infinie, par conséquent le nombre d'initialisations de connexion que peut surveiller un simple ordinateur est limité. Ainsi, l'attaquant floode la victime avec beaucoup de paquets SYN spoofés (d'adresses prises au hasard). La victime va donc répondre à ces paquets SYN par un paquet ACK/SYN en attente d'un paquet ACK, comme la coutume le veut. Puisque les réponses ne viendront pas, la machine gardera dans la pile les informations sur chaque host qui a demandé l'initialisation d'une connexion. Pour que ces connexions soient enlevées de la queue, il faut qu'elles timeout, ce qui prendre relativement longtemps. Par conséquent, tant que l'attaquant continue l'envoi des paquets SYN, aucune autre réelle connexion ne pourra parvenir à la cible et elle sera isolée.
De la même façon que ces attaques se servent du protocole TCP pour mener à bien leurs objectifs malveillants, il est possible de scanner un ordinateur de façon beaucoup plus savante que celle utilisée par les scanners classiques (vérification de l'établissement d'une connexion TCP/IP), c'est ce que nous nous proposons de vous expliquer maintenant.
| << La couche de liaison de données | Le scanning avancé >> |
11 Commentaires
Afficher tous
| Anonyme | 10/05/14 02:37 |
| thanks |
|
| FrizN | 05/03/14 21:45 |
| Oui. |
|
| Yedoz | 05/03/14 15:14 |
| Ca fait pareil que quand on le fait à quelqu'un quand on se DoS soi-même ? Merci. |
|
| Anonyme | 09/08/13 20:05 |
| Merci baucoup :) |
|
Commentaires désactivés.
Apprendre la base du hacking - Liens sécurité informatique/hacking - Contact
Copyright © Bases-Hacking 2007-2014. All rights reserved.
Copyright © Bases-Hacking 2007-2014. All rights reserved.