Databases, Systems & Networks

En sécurité informatique, on sait de nos jours parer à la grande majorité des menaces. Si on se concentre sur la partie serveur et sur Linux, Grsex / Pax, un coup de hardening, un kernel statique et optimisé, du chroot et ma foi on est déjà pas mal…

Les démons comme apaches et Mysql, ainsi que les interprêteurs comme PHP ou Perl, sont protégés contre leurs ennemis intimes : les overflows. Les droits séparés, les arborescences protégées, les connexions filtrées, que peut on faire de plus ? Par exemple séparer le back office sur un autre vhost pour ajouter un htaccess afin de le protéger, auditer le site contre les vulnérabilités classiques, XSS, SQL injection etc…

Well… Que reste t’il, un ou deux mécanismes à protéger mais… Le D.D.O.S, c’est fatal.

Know your ennemy !

La D.D.O.S – Distributed Denial Of Services – c’est la grande frayeur de n’importe quel E-commerçant, de n’importe quel site gagnant de l’argent en ligne et surtout, de votre infogérant…

Un déni de service distribué consiste à envoyer des milliers, des dizaines de milliers, des centaines de milliers de requêtes simultanément. Si l’on limite la réflexion aux sites Web, il suffit, en général, de faire 10 à 50 000 connexions simultanées pour mettre à genou un serveur et/ou la connexion Internet des serveurs.

Ces innombrables connexions arrivent, en général, depuis des machines compromises, de partout dans le monde. Ces machines sont compromises par des vers, par exemple Confliker ou d’autres plus discrets, qui sommeillent dans des PC depuis des mois, à l’écoute des ordres. Ces machines, appelées Zombies, font partie de réseaux nommés Botnets.

Ensuite, c’est malheureusement d’une simplicité diabolique. Un script kiddy (ou même un vrai hacker) paye quelques poignées de dollars et loue tout simplement la puissance d’un botnet. Combien de machines, combien de temps, quelles commandes doit être lancée. Simple, terriblement efficace, imparable…

Les machines reçoivent les ordres et en quelques minutes, des centaines milliers de connexions pleuvent sur le site ciblé.

Comment éviter une D.D.O.S ?

Une D.D.O.S se base, pas essence, sur des machines compromises, la plupart du temps des bêtes PC de particuliers.

Evidemment, nous ne pouvons avoir une action sur ces machines directement. Les désinfecter à distance n’est pas possible, pas plus que cela ne serait autorisé du reste.

Ensuite, bloquer ces machines une par une dans un firewall est aussi inutile qu’impossible. Impossible à cause du volume, inutile car bloquer ces connexions n’empêchera pas le pirate d’en envoyer d’autres, d’en envoyer plus et de toute façon, si ce ne sont pas les serveurs qui craquent, ca sera la connexion Internet des serveurs.

Damned, we are done ?

Non. Plutôt que d’étudier le problème sous l’angle de ce qu’on ne peut pas faire, voyons plutôt ce que nos assaillants ne peuvent pas faire :

Il n’est pas possible pour le pirate de réellement patcher le noyau des machines Windows compromises. Si un ver se comportait de cette façon, il serait beaucoup moins efficace (capté par des anti virus) et beaucoup moins portable (selon les versions de Windows). Donc, les vers tournent en général au dessus, dans la couche logicielle. Résultat, ils sont obligés de faire ce que la couche du dessous demande…

Et c’est là que ce situe la faille de ces attaques, de ces vers. Si l’on arrive à forcer les machines à arrêter d’envoyer des paquets en utilisant une subtilité du protocole TCP, le driver de la carte réseau sera obligé d’agir et cet ensemble est lui directement au niveau noyau, donc prioritaire sur la couche logicielle.

Voila un début solution semble t’il…

Tarpit : du goudron et des plumes !

Règle number one du Blog : plus c’est long, moins c’est lu… Je vais donc faire court et je ne vais pas non plus vous expliquer comment paramétrer un noyau linux et le compiler, de même pour le binaire iptables. Vous trouverez le noyau ici : ftp.kernel.org et pas mal de guide de survie en googlant.

Sinon j’en ai écris un il y a longtemps, mais ca devrait vous aider, ca se trouve ici. il y a des choses tout à fait dépassées, des choses inexactes dans les exemples de firewall mais je n’ai pas eu le temps de le corriger. Ceci étant, vous pouvez partir de là. vous aurez besoin de  recompiler aussi le binaire iptables en passant par la patch-o-matic, tout est expliqué ici.

Mais pourquoi Iptables et Tarpit sont nos amis ?

La règle TARPIT, et il existe d’autres moyens de faire cela évidemment, permet d’informer nos gentils PC zombies qu’ils sont priés d’attendre qu’on les recontacte avant de nous envoyer le prochain paquet réseau. Les machines Windows, comme la plupart des OS récents du reste, respecte le « window resizing ».

Quand on règle la fenêtre (window) de communication à une taille de zéro, la machine distante reste dans un état d’attente, jusqu’à ce que l’on remette une taille normale à la window TCP.

Mais que se passe t’il si l’on ne remet jamais la fenêtre à une taille normale ? Eh bien la machine reste en attente… Et c’est là que la solution se situe. La connexion se bloquera jusqu’à ce que l’OS fasse le ménage dans ses connexions inertes !

Ca peut prendre du temps… pas mal de temps en fait, quand bien même notre machine distante s’acharnerait en refaisant une connexion, à chaque nouvelle tentative, elle bloquera un peu plus sa propre « stack tcp », son propre système de gestion du réseau… Ca va prendre un peu de temps mais ca va bien ralentir l’attaque, d’autant plus que la plupart des machines ne réessayeront pas puisque la connexion n’est pas morte, elle est juste « en pause ».

Comment et à qui appliquer le Tarpit ?

Simplement en 1° scotchant la connexion attaquante 2° en dropant le paquet pour ne pas nous encombrer inutilement. Histoire de faire simple, on va se créer une règle qui fait ca en une fois.

iptables -N TARPIT_DROP
iptables -A TARPIT_DROP  -j TARPIT
iptables -A TARPIT_DROP  -j DROP

Ok mais si on fait un tarpit de tout le trafic entrant avec un iptables -I INPUT -P TARPIT_DROP ou la même chose en FORWARD, on va perdre tout le trafic entrant, y compris les vrais clients du site… C’est peut être un peu désagréable pour les personnes qui n’y sont pour rien.

Afin de trier le bon grain de l’ivraie, il va nous falloir être plus malin que les « bots », les zombies, qui nous attaquent. Il est possible de faire un peu de trie avec des IDS comme Snort par exemple ou sinon d’analyser les logs et les requêtes, ou encore même le rythme des connexions.

Quand on y réfléchit, il est assez simple de reconnaitre un bot car il fait toujours la même chose en général (par exemple un get /blabla.php) et/ou utilise une fréquence précise (par exemple toutes les 5 secondes).

Si l’on utilise un IDS, c’est lui qui pilotera les règles de firewalling (flex rules) directement quand il détecte un comportement anormal. Si l’on souhaite utiliser un parser de logs, il est très simple de lui donner la « pattern » de l’attaque (par exemple un get /blabla.php toutes les 5 secondes) et d’interdire toutes les machines utilisant cette pattern.

Si c’est une page spécifique qui est visée (blabla.php par exemple) il est aussi possible de détecter dans le contenu du paquet (sauf en https) le mot blabla et d’interdire, en fait de tarpiter les machines l’appelant. Certes, les personnes appelant réellement pour de bonnes raisons la page blabla vont être déçues, mais les autres vont être bloquées aussi. Si ca a lieu sur la homepage, cette méthode n’est pas applicable, mais sinon :

iptables -I INPUT -p tcp -s 0.0.0.0/0 –dport 80 -m string –string « blabla » –j TARPIT

Il nous reste d’autres possibilités, avec les mod geoip par exemple ou encore en tarpitant les connexions entrantes qui sont des réseaux similaires (49.230.xxx.xxx par exemple)

Il est possible de limiter en fonction du nombre de paquets et du type de paquets reçus par secondes. Iptables en fait est une usine à idées sans limite. Les attaques peuvent prendre plusieurs formes mais la réponse peut aussi être assez polymorphe à sa manière avec Iptables !

-m limit –limit 2/second –dport 80 –syn -j ACCEPT

Utiliser un mélange subtile des paramètres limit et burst-limit peut permettre d’enrayer les flots de paquets réseau trop « soutenu ».

Mélanger subtilement –string pour identifier le contenu et –limit pour le rythme, –state pour l’état de la connexion et d’autres tests, cela peut aussi permettre des résultats intéressants en terme de détection :

iptables -I INPUT -p tcp –dport 80 –m string –string “blabla” –m limit –limit 1/6s –limit-burst 1 –m recent –name DDOSbot –set
iptables –I INPUT FORWARD -p tcp –dport 80 -m recent –name badguy –set -j TARPIT_DROP
iptables –I INPUT -m state –state NEW –m limit –limit 1/6s –limit-burst 1-j TARPIT_DROP

Là par contre, on a beaucoup limité les personnes qui sont tarpitées, en fait à celle faisant une nouvelle connexion plus souvent que toutes les 6 secondes ou si elles appellent la chaine blabla à la même fréquence. Encore une variante ?

iptables -I INPUT -m state –state NEW -m recent –update –seconds 20 –hitcount 4 -j DROP
iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j RETURN

Le parametre “Syn cookie” dans le noyau permet aussi de s’assurer qu’un petit malin ne nous flood pas à coup de SYN uniquement car s’il ne donne pas suite à sa connexion, elle ne sera pas maintenue, c’est un élément de protection indispensable. Et si notre assaillant est très « vieux jeu » et votre réseau très vétuste, qu’il utilise un ping flood, iptables -A INPUT -p icmp -m limit --limit  1/s --limit-burst 1 -j ACCEPT, devrait limiter se velléités.
Si vous vous passez d’un IDS, vous aurez à analyser vous-même l’attaque, sa méthode et sa forme afin de déterminer la méthode la plus adaptée pour y répondre.
L’analyse est un point vital et Tarpit une réponse fatale.

More fun with Tarpit ?

Bon soyons clairs, on peut aller plus loin dans le fun.

Par exemple une personne qui scanne les machines va utiliser un scanner qui va soit utiliser des séquences TCP connues (SYN scan, Xmas Scan etc..) ou même un enchainement de ports, linéaire (1,2,3 etc…), spécifique croissant (21,22,23,25,80 par exemple) ou aléatoire (443,22,53,80,21 par exemple).

Dans tous ces cas, on peut utiliser un démon comme knocked par exemple, un démon de port knocking, pour identifier une séquence de scan. Une fois qu’on l’a identifié, le port knocker est censé ouvrir la connexion pour la personne qui a fait la bonne séquence. Faisons l’inverse puisque c’est un pirate, interdisons lui l’accès et au passage tarpitons le un petit coup…

Le plus drôle c’est qu’on va maintenir son IP en Tarpit et donc provoquer une connexion bloquée par port scanné et là… assez rapidement… sa machine va sévèrement bloquer du coté réseau.

Alors, au final, Tarpit, c’est fun non ? Il existe de nombreuses autres options que vous pourrez trouver dans le kernel ou dans la patch-o-matic, toutes peuvent donner lieu à des mélanges très utiles.

écrit par Philippe Humeau

Source: Wikigento