[iptables] Contrer une attaque DDos

Contrer une attaque DDos [iptables] - réseaux et sécurité - Linux et OS Alternatifs

Marsh Posté le 24-03-2008 à 22:36:27    

Je désire savoir s'il existe une (ou un ensemble de) ligne de commande iptables qui permet de limiter le nombre d'accès simultanés à un port du serveur (dans ce cas le port 80) en provenance de chaque IP.
 
En fait ce que j'aimerais c'est que mon serveur applique la règle suivante:
 
À chaque moment une adresse IP unique, quelle qu'elle soit, ne peut pas obtenir plus de N accès simultanés au port 80 du serveur
 
Merci d'avance à toute personne qui pourrait m'aider.
 
Sujet mis à jour


Message édité par genevois le 25-03-2008 à 15:33:12

---------------
Salutations de Genève
Reply

Marsh Posté le 24-03-2008 à 22:36:27   

Reply

Marsh Posté le 24-03-2008 à 22:44:44    

      --limit rate
              Maximum  average  matching  rate: specified as a number, with an
              optional ‘/second', ‘/minute', ‘/hour', or  ‘/day'  suffix;  the
              default is 3/hour.


:??:


Message édité par Mjules le 24-03-2008 à 22:45:02

---------------
Celui qui pose une question est idiot 5 minutes. Celui qui n'en pose pas le reste toute sa vie. |  Membre du grand complot pharmaceutico-médico-scientifico-judéo-maçonnique.
Reply

Marsh Posté le 25-03-2008 à 07:56:25    

utilise la match recent


---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 25-03-2008 à 11:33:11    

juste pour info, pourquoi tu as besoin de faire ça ?

Reply

Marsh Posté le 25-03-2008 à 12:43:55    

Taz a écrit :

juste pour info, pourquoi tu as besoin de faire ça ?


Pour bloquer une attaque DDoS.
 
La solution m'a été donnée par ailleurs:

iptables -A INPUT -p tcp --syn --dport 80 -m iplimit --iplimit-above xxx --iplimit-mask 24 -j REJECT


 
où xxx est le nombre de connexions maximales
 
Il ne me reste plus qu'à tester l'efficacité de cette mesure.


---------------
Salutations de Genève
Reply

Marsh Posté le 25-03-2008 à 14:02:59    

Et non, ça ne marche pas encore tout à fait. J'ai testé la commande ci-dessus (j'ai vérifié la syntaxe avec le peu de connaissances que j'ai de Linux) avec la limite (xxx) fixée à 5 et j'obtiens le message d'erreur suivant:

iptables: No chain/target/match by that name


Et pourtant une chaîne INPUT existe bel et bien:

$iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       all  --  143.243.


Je suis comme qui dirait dépassé.

Reply

Marsh Posté le 25-03-2008 à 14:03:47    

1. utilise la match recent je te dis
2. ca ne t'éviteras des DDoS mais seulement certains DoS


---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 25-03-2008 à 14:26:38    

o'gure a écrit :

utilise la match recent


"match recent"... kekséksa?

Reply

Marsh Posté le 25-03-2008 à 14:47:19    

c'est normalement décrit dans le man page d'iptables... T'as penser à regarder dedans ?

 

Sinon http://www.debian-administration.org/articles/187
L'article là utilise ca pour limiter le nombre de connexion sur le port 22 (SSH) pour contrer les tentatives d'attaques brute force.

 

Le principe est valable pour d'autre chose.

 

Sinon tu as regarder niveau applicatif si tu pouvais faire quelque chose ?

 

De quel type de DoS parles tu ?

Message cité 1 fois
Message édité par o'gure le 25-03-2008 à 14:47:37

---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 25-03-2008 à 15:45:42    

o'gure a écrit :

De quel type de DoS parles tu ?


Quand j'entre la commande:

netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n


les dernières lignes de résultat me donnent ça:
 

     9 59.92.113.254
     10 24.147.229.189
     11 77.48.69.1
     12 84.55.152.80
     21 212.111.199.138
     34 77.41.9.60
     39 212.248.40.158
     39 82.127.106.50
     44 85.142.1.120
     66 82.114.98.217


 
toutes des IP "exotiques" (principalement en provenance de Russie en général) qui par ailleurs n'auraient aucune raison d'accéder au site hébergé sur le serveur, et surtout pas avec autant d'occurrences. De plus, quand j'avais essayé de bloquer l'une ou l'autre de ces IP, d'autres apparaissaient immédiatement après. Donc visiblement ça a une très forte odeur de DDoS.
 
Bon, je viens de charger (D)Dos-Deflate, je verrai s'il arrive à bloquer les attaques.


Message édité par genevois le 25-03-2008 à 15:46:58

---------------
Salutations de Genève
Reply

Marsh Posté le 25-03-2008 à 15:45:42   

Reply

Marsh Posté le 25-03-2008 à 16:02:09    

Le -m recent devrait suffir pour ca.
sinon a partir du moment ou tu mets un service en accès sur le net faut s'attendre à ce qu'il soit attaquer [:spamafote]
 
As tu vu des ralentissements ou des problèmes ?
Il ne faut pas sombrer dans la parano non plus...


---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 25-03-2008 à 17:35:39    

o'gure a écrit :

Le -m recent devrait suffir pour ca.
sinon a partir du moment ou tu mets un service en accès sur le net faut s'attendre à ce qu'il soit attaquer [:spamafote]
 
As tu vu des ralentissements ou des problèmes ?
Il ne faut pas sombrer dans la parano non plus...


Ralentissement est en l'occurrence un euphémisme. Le serveur est inaccessible par http, et en ssh (telnet) d'une lenteur à désespérer, quand il n'est pas complètement bloqué comme actuellement, au point que je doive contacter l'hébergeur pour qu'il fasse un redémarrage manuel.
 
Dès que j'ai de nouveau accès je vais tester votre solution.

Reply

Marsh Posté le 25-03-2008 à 18:01:28    

Il faut que tu aies bien conscience du type de DDoS ou DoS auquel tu as affaire :
1. si c'est simplement un gars qui tente de bouffer les connexions dispo ("backlog" = nombre de connexion simultanée à un service) tu peux gérer ca grace aux solutions au dessus.
 
2. si c'est un gars qui te floode et rempli ton tuyau, tu peux rien y faire étant donné que tu ne controles pas et qu'a priori tu ne peux pas controler ce flux
 
---
soit c'est un petit botnet (orienté consommation de ressource d'un service, et pas consommation de la bande passante) et tu peux éventuellement t'en sortir en utilisant :
 - utilisation de la match recent + logging des adresses IP que tu blacklistes
 - utilisation de règle de blacklist
 
Au bout d'un moment en regardant les logs d'iptables issues de la match tu auras moyen de les recouper et de mettre en place un blacklist des subnets les plus utilisés.
 
Le problème :
 - les proxies : si tes "clients" utilisent des proxies, tu auras des faux positifs, c'est a dire des connexion légitimes issues de derrière le proxy. Seulement vu qu'il y a plusieurs clients... tu ne pourras pas le distinguer d'un flood...
 
 - certains clients qui utilisent à fond le forum...
 
Après en regardant d'où vient l'adresse IP tu as moyen de corriger les faux.
A toi de bien régler tes parametres.
 
 
--
 
Les vrais DDoS :
Typiquement un DDoS est issu d'un botnet et ce botnet couvre le monde entier. Il n'y a pas de source clairement identifiée, les différentes sources ne peuvent être aggrégées au niveau adressage IP... tout ca fait qu'il est extremement difficile de contrer un vrai DDoS. Seulement au niveau ISP tu peux gérer ca, et ils ne le font que pour des clients "intéressants"...
 
 - beaucoup de source qui émettent vers une meme destination
 - peut importe le service derriere, l'aggrégation des multiples flux arriveront tous sur le meme lien : la carte réseau de ton ordi
 - ton ordi va tenter de répondre aux multiples requetes (chose qu'il n'arrivera pas) qui arriveront sur le port 80 par exemple
 - ou tout simplement le traffic ne fera que prendre une partie de ta bande passante...
 
=> au final, aucune solution a part mettre en place du filtrage DANS le réseau, là ou la bande passante est largement supérieure au flux du DDoS
 
En russie ca se monnaye très bien pour pas cher, tu ne pourras pas y faire grand chose à moins de remonter tous aux "abuse" des FAI sources (s'ils prennent en compte, ce qui est loin d'etre le cas) ou alors de faire un filtrage dans le coeur de réseau. Et ca c'est à ton ISP de le faire, par contre  :
- ca m'étonnerait qu'il te le face gratuitement...
- c'est loin d'etre facile de le mettre en place, de manière industrielle (détecter les sources nuisible, et faire un blackhole = puit de trafic)...  


Message édité par o'gure le 25-03-2008 à 20:25:23

---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 25-03-2008 à 23:24:12    

o'gure a écrit :

1. utilise la match recent je te dis
2. ca ne t'éviteras des DDoS mais seulement certains DoS


ça va surtout bloquer les gens natés. rien d'autres.

Reply

Marsh Posté le 26-03-2008 à 07:35:00    

j'ai mentionné ce probleme en dessous. Pour les gens ayant la même adresse IP (nat, proxies...) ils risquent de se faire bloquer. Après c'est à lui de gérer correctement les paramètres et de voir en fonction de ses clients.

 

Si tu connais d'autres solutions à mettre en place au niveau du serveur, éclaire nous...


Message édité par o'gure le 26-03-2008 à 07:35:35

---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 26-03-2008 à 14:24:30    

o'gure a écrit :

1. utilise la match recent je te dis
2. ca ne t'éviteras des DDoS mais seulement certains DoS


J'ai essayé d'utiliser les commandes dans le lieu que tu as précisé, juste en changeant le port (22 en 80), soit:

iptables -I INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --set


et j'obtiens le résultat suivant:

iptables v1.2.8: Couldn't load match `recent':/lib/iptables/libipt_recent.so: cannot open shared object file: No such file or directory


Manque-t-il quelque chose?

Reply

Marsh Posté le 26-03-2008 à 16:38:02    

dans l'exemple du lien il y a un \ après le recent. Peut être que ca pourrait t'aider?

Reply

Marsh Posté le 26-03-2008 à 16:47:43    

mic_12 a écrit :

dans l'exemple du lien il y a un \ après le recent. Peut être que ca pourrait t'aider?


Ah, je croyais qu'il servait de caractère indiquant le passage à la ligne dans l'exemple... Je vais réessayer de ce pas.

Reply

Marsh Posté le 26-03-2008 à 16:56:42    

"recent" est normalement un module pour netfilter. Dans les derniers kernel il se nomme ipt_recent
Pour pouvoir l'utiliser il faut un iptables à jour également.
 
Vérifie les versions et fait quelques recherches sur exactement comment fonctionne ces options/modules... Ca t'éviteras de mauvaise surprise, notament perdre la main sur ta machine...


---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 26-03-2008 à 17:03:26    

par contre l'option -m j'arrive pas à savoir à quoi elle correspond  :??:

Reply

Marsh Posté le 26-03-2008 à 17:04:26    

mic_12 a écrit :

par contre l'option -m j'arrive pas à savoir à quoi elle correspond  :??:


A charger la "match" en question.
Vous avez lu le manpage d'iptables par hasard ?

 

on indique avec -m quelle comparaison on va faire, par exemple "-m state" pour dire qu'on regarde l'état du paquet et après on met les critères sur lesquels on va se baser...

-m state --state NEW


par exemple pour filtrer les paquets appartenant à une connexion en état NEW

 


le nom qui suit le -m indique à iptables quel module de netfilter on va utiliser [:spamafote]


Message édité par o'gure le 26-03-2008 à 17:34:19

---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 27-03-2008 à 10:31:31    

j'ai regardé la man page et g fini par trouver. Pas facile à voir  :whistle: . J'aurais dû faire une recherche tout de suite
 
ca pourrait t'aider pour t'assurer de la syntaxe:
 

Citation :

iptables peut utiliser des modules additionnels  de  correspondance  de
       paquets. Ceux-ci peuvent être chargés de deux manières : implicitement,
       lorsque -p ou --protocol est employé, ou avec l’option -m  ou  --match,
       suivie  du  nom  du  module de correspondance ; après cela, des options
       supplémentaires en ligne de commande deviennent disponibles,  en  fonc-
       tion  du  module. Vous pouvez spécifier plusieurs modules de correspon-
       dance sur une même ligne, et utiliser l’option -h ou --help après avoir
       spécifié le module, pour visualiser l’aide relative à ce module
.


Message édité par mic_12 le 27-03-2008 à 10:34:00
Reply

Marsh Posté le 26-04-2008 à 20:44:21    

Une regle sympa :


$IPT -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT

 

que j'ai trouvé la : http://www.netfilter.org/documenta [...] html#ss7.3
Paragraphe  "limit" . Ca permet de limiter le nombre de nouvelles connections sans limiter les connections deja en cours . L'article t'explique bien comment ca te protege d'un syn flood , et c'est ce qui a dus t'arriver je pense .

 

Y a aussi l'option kernel

# echo 1 > /proc/sys/net/ipv4/tcp_syncookies

qui permet de limiter l'impact d'un syn-flood , je ne sais plus si cette option est activée par defaut dans le kernel mais ca ne fait pas de mal de placer cette regle dans son script iptables

Message cité 1 fois
Message édité par ipnoz le 26-04-2008 à 20:50:33
Reply

Marsh Posté le 02-05-2008 à 10:06:22    

ipnoz a écrit :

Une regle sympa :


$IPT -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT

 

que j'ai trouvé la : http://www.netfilter.org/documenta [...] html#ss7.3
Paragraphe  "limit" . Ca permet de limiter le nombre de nouvelles connections sans limiter les connections deja en cours . L'article t'explique bien comment ca te protege d'un syn flood , et c'est ce qui a dus t'arriver je pense .


Sauf qu'avec cette commande toutes les nouvelles connexion TCP vont y passer, peut importe la source [:god]
Genre tu as un serveur web, si X tente une connexion (il va etre accepté), dans la meme seconde Y en tente une => il va etre refoulé alors qu'il est tout a fait légitime [:bien]

 

Il faut paramétré la limite assez précisément, bref je ne suis pas sûr que ca soit assez flexible comme solution. Pour agir au niveau de du nombre simultanée, par source, et ceci de manière dynamique la match recent est la solution. [:spamafote]

 


Message édité par o'gure le 02-05-2008 à 10:07:08

---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 02-05-2008 à 17:31:28    

Oui bien sur que les nouvelles connections legitimes et illegitimes seront DROP sans distinctions , mais c'est une regle qui permet de gerer son load en refusant de nouvelles requetes et eviter que ton serveur ne s'ecroule . Dans le cas d'un DDOS , si ton serveur ne peut pas gerer 100 nouvelles connections ( c'est un example ) par secondes , et que 200 zombies te floodent de requetes , le module --recent ne te seras pas utile .
 
Au final , les deux doivent aller ensemble a mon avis , et encore , pour un site web , je pense que c'est difficile a gerer avec iptables uniquement .
 
J'avais placé cette regle  
 

$IPT -A FORWARD -o $INTERNET_FACE -p tcp --syn -m limit --limit 1/s limitburst 5 -j ACCEPT


 
 
sur mon routeur pour eviter qu'un PC de mon LAN ne fasse du SYN flood ( nmap ou bien virus/zombie etc... ) , et je me suis rendu compte que sa foirait sur certains sites web avec beaucoup d'images , genre cette page http://wikidota.org/H%C3%A9ro , pour la charger , le client va emmetre a peut pres 150 nouvelles requetes --syn  :heink:  .
 
Donc au final , je ne pense pas qu'il est possible de proteger un site web d'un DDOS avec --recent , c'est sympa pour eviter les brutes forces et compagnie mais vu le nombres de paquets SYN qui passent sur une transaction http , ca me semble fort impossible .


Message édité par ipnoz le 02-05-2008 à 17:31:54
Reply

Marsh Posté le 03-05-2008 à 11:34:35    

Salut pour contrer les DDOS, d'après ce que j'ai lu, les meilleurs outils pour ça sont: fwsnort et psad.
 
Désolé j'ai pas trop le temps de me pencher sur la question, mais si t'as besoin d'aide je veux bien participer car dans le futur j'aurais besoin de ce genre de protection et ça serait bien de faire un cookbook là-dessus.

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed