Limiter le forward des paquets à destination de SSH

Salut à tous,

J’ai un routeur sur lequel je souhaite passer de:

Y a-t-il une façon de spécifier cette exception simplement dans mes règles iptables ?
Par ex:

iptables -A FORWARD -i $DSL -p tcp --dport !22 -j ACCEPT iptables -A FORWARD -i $DSL -p tcp --dport 22 -m limit --limit 1/min -j ACCEPT

Merci

c’est comme tu dit, sauf qu’il faut mettre ton exception >avant< la règle générale pour que les paquets port 22 sortent en ACCEPT de temps en temps, et qu’il te faut ensuite une règle DROP pour les paquets ports 22 qui ne matchent pas, pour qu’ils ne rencontrent jamais la règle ACCEPT pour tout le reste.
Pour résumer:

iptables -A FORWARD -i $DSL -p tcp --dport 22 -m limit --limit 1/min -j ACCEPT iptables -A FORWARD -i $DSL -p tcp --dport 22 -j DROP iptables -A FORWARD -i $DSL -j ACCEPT

Remarque: pourquoi tu veux faire ça ? Ca va empêcher de faire du scp plein pot.
En général on privilègie plutot le ssh aucontraire, il me semble.

Sinon pour éviter le brute-force il y a l’option LoginGraceTime dans la config de sshd, mais je ne sais pas si ça correspond vraiment à ton besoin :slightly_smiling:

fail2ban aussi aide bien à limiter les attaques.

Attention : ne pas confondre paquet et connexion !
S’il n’y a rien d’autre, ce jeu de règles limite le nombre de paquets SSH par minute sans distinction de connexion ni de source, et crois-moi, à 1 paquet/mn, ça ne va pas être pratique de taper des commandes ! Pire, pendant une attaque par force brute il sera quasiment impossible à un utilisateur légitime d’utiliser sa session quelle que soit la limite.

Pour limiter le nombre de connexions SSH par minute sans distinction de source avec iptables, il faut appliquer la limitation seulement aux paquets qui créent une nouvelle connexion SSH. On les reconnaît avec le drapeau SYN (–syn) et/ou l’état NEW (-m state --state NEW). Une autre possibilité consiste à accepter les paquets dans l’état ESTABLISHED ou RELATED avant, de sorte qu’ils ne soient pas affectés par la règle de limitation. Mais là encore, une attaque par force brute en cours pourra empêcher un utilisateur légitime de se connecter.

Pour limiter le nombre de connexions par minute et par source avec iptables, il faut utiliser la correspondance recent.

:smt003 et comme d’hab, je suis passé à coté de ça. 1 paquet/minute, ça fait un peu court…

Peu importe la valeur de la limite, en fait. C’est l’approche initiale qui est mauvaise. Si la limite est atteignable, elle pourra provoquer un déni de service contre les utilisateurs légitimes : si la limite est à 100, qu’un attaquant envoie 200 paquets/mn un paquet légitime a une chance sur 2 d’être accepté. Si la limite est inatteignable (compte tenu de la vitesse de la connexion réseau par exemple), alors elle sera inefficace.

Même les autres méthodes que j’ai évoquées ont leur faiblesse. La limitation simple des connexions avec limit peut provoquer un déni de service en cas d’attaque : si la limite est à 10/mn et qu’un attaquant fait 20 tentatives/mn, un utilisateur légitime a une chance sur 2 de réussir à se connecter. La limitation des connexions par source avec recent peut aussi provoquer un déni de service en cas d’attaque par usurpation d’adresse. C’est néanmoins plus difficile à réaliser, car il faut connaître l’adresse d’un utiliseur légitime et être capable d’envoyer des paquets avec une adresse source usurpée.

Salut,

merci pour ces infos.
J’utilise déjà fail2ban sur le serveur final.
Mais filtrer plus en amont les attaques par bruteforce: éviter de les propager à travers le réseau pour les jetter une fois arrivées sur le serveur.

D’où ma question sur le filtrage au niveau du routeur.

Effectivement, la limitation doit être sur les demande d’ouverture de connexion (syn) et non pas sur tous les paquets à destination de SSH.

L’utilisation de l’option recent me parait tout a fait pertinente car elle permet de limiter le filtrage à l’IP à l’origine du bruteforce (en se mettant dans le cas quela source du bruteforce n’est pas usurpée).

Ce jeu de règles conviendrait:

[code]iptables -A FORWARD -p tcp --dport 22 -i $DSL -m state --state NEW -m recent --set

iptables -A FORWARD -p tcp --dport 22 -i $DSL -m state --state NEW -m recent --update --seconds 600 --hitcount 2 -j DROP
iptables -A FORWARD -i $DSL -j ACCEPT
[/code] ??
Merci

iptables -A INPUT -i eth1 -p tcp --dport 22 -m state --state NEW -m recent --set iptables -I INPUT -i eth1 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 90 --hitcount 3 -j DROP
ne limite que les nouvelles connexions et permet le scp rapide. Je l’utilise à la place de fail2ban. Très efficace, ça a divisé par 20 la taille des logs…

[edit: je viens de lire la suite du post, bon j’arrive après la bagarre, mes paramètres sont un peu distincts des tiens]