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

utilise la match recent

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

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

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

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:

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

Je suis comme qui dirait dépassé.

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

"match recent"... kekséksa?

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 ?

Quand j'entre la commande:

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

 
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.

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
 
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.

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)...  

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

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...

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

et j'obtiens le résultat suivant:

Manque-t-il quelque chose?

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.

"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...

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...

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

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

Une regle sympa :

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

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

Sauf qu'avec cette commande toutes les nouvelles connexion TCP vont y passer, peut importe la source
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

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.

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  
 

 
 
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    .
 
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 .

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.