Plop …

un petit retour sur le Ddos de ce week-end … conformément aux prédictions de certains concernant mon précédent article, un ban permanent n’est généralement pas une bonne idée, notemment lorsque les paquets sont forgés :

• ça remplit inutilement les règles du firewall (la dernière attaque avait finit avec 600 lignes de DROP, ce qui rend difficile la lecture des règles mise en place)
• en cas de ban d’un « client/joueur », il est banni à vie
• il y a un risque si l’attaquant connait l’ip de l’admin et la fait bannir en floodant avec son ip
• …

Donc on m’a filé une autre commande, plus courte et aussi performante, sans remplir inutilement les règles iptables :
(il faut supprimer l’espace entre les deux – - dans les commandes suivantes, wordpress les transforme en un seul -)

Ici, on surveille tout les nouveaux paquets sur le port 25565 et si la même ip renvoit de nouveaux paquets on incremente un compteur, si celui-ci atteint le hitcount (ici 5) dans les 60 secondes, on drop les paquets.

Si le visiteur lambda se fait drop, il devra juste attendre la fin de l’intervalle depuis son dernier paquet envoyé (ici 60 secondes à chaque fois),

Si c’est une attaque dos, il ne pourra envoyer que 5 nouveaux paquets par minutes, réduisant de ce fait la puissance de son attaque (si à chaque syn envoyé une nouvelle ip est forgée, cette protection ne servira à rien … et mon ban permanent aussi d’ailleurs ).

Et maintenant que la machine est « protégée » (c’est relatif hein ), il faut tester la sécurité ^^, on flood donc notre machine en envoyant des paquets SYN (avec scapy) sur le port du service que nous avons protégé.

On crée donc un fichier avec ce contenu en changeant les valeurs des ip, la valeur du loop et le port (derrière une NAT ça remplace l’ip source par votre adresse ip) :

Pour vérifier que les paquets sont drop, on fait un tcpdump sur le port en question et on compte le nombre de paquets provenant du port 1337.

(Si la règle en interdit plus de 5 et qu’on reçoit les 10 y’a un problème) ou l’on check les stats d’iptables via

Par contre, on peut s’amuser avec scapy à randomiser les ip (à faire sur des machines non natées) et tenter de flooder le service sans se faire drop un seul paquet :

Et là on se rend compte que l’on peut facilement contourner la règle iptables précédente, et qu’il devient important de mettre en place une règle globale pour toute les ip sur un service en particulier.

Donc pour mettre en place une limite globale par exemple sur le port 80 qui peut traiter au max 1000 connexions en parallèle (en imaginant qu’une requête est traitée en 1 seconde (téléchargement d’une page web en générale) ce qui n’est pas forcément vrai pour tout les services, donc on laisse au mimimum 10% du nombres des connexions pour les connexions en cours) ce qui donne :

Et si l’on rebalance un SYN flood avec le script précédent, en lançant plus de 1000 syn en parallele, seul une partie d’entre eux devrait passer.

Ce système permet surtout de protéger les services derrière le firewall en cas d’attaque permettant de passer les règles présentées jusque là.