Accueil › Sécurité › Règles iptables anti brute force pour SSH

Règles iptables anti brute force pour SSH

— Laisser un commentaire

Nombreux sont les administrateurs se plaignant de la quantité d’attaques de type “brute force” (essai d’une multitude de mots de passe sur un compte donné) effectuées sur leurs serveurs SSH écoutant sur le port standard (22).

“iptables” Permet de mettre en place une protection sommaire contre ce type d’attaque du genre :

“Il est interdit d’effectuer plus de 4 connexions par minutes sur le port SSH.”.

Cette méthode n’a rien de nouveau mais reste efficace et peu contraignante. Ce post la rappelle rapidement.

Mise en place de l’anti brute force

Commençons par l’écriture d’une “chaîne nommée” (ensemble de règles appelées par un nom personnalisé) préfixant les logs des requêtes qui lui sont transmises et refusant la connexion :

1 # Regle log ssh drop :
2 iptables -N SSH_DROP
3 iptables -A SSH_DROP -m limit 
--limit 1/s -j LOG --log-prefix '[fw drop -> Attack ssh] : '
4 iptables -A SSH_DROP -j DROP

ou pour les utilisateurs d’ULOG :

1 # Regle log ssh drop :
2 iptables -N SSH_DROP
3 iptables -A SSH_DROP -j ULOG 
--ulog-nlgroup 1 --ulog-prefix '[fw drop -> Attack ssh] : '
4 iptables -A SSH_DROP -j DROP

Cette chaîne sera appliquée pour bloquer une machine.

Rappel : les règles “iptables” sont traitées, par défaut, dans l’ordre dans lesquelles elles sont définies.

L’anti brute-force proprement dit peut s’écrire ainsi :

1
2
3
4
 
# Regles anti-brute force :
iptables -A INPUT -d ${IP_EXT} -p tcp --dport ${PORT_SSH} 
-m recent --update --seconds 60 --hitcount 4 --name SSH -j SSH_DROP
iptables -A INPUT -d ${IP_EXT} -p tcp --dport ${PORT_SSH} -m recent --set --name SSH
iptables -A INPUT -d ${IP_EXT} -p tcp --dport ${PORT_SSH} -m state --state NEW -j ACCEPT

qui se lira :

  • ligne 2 : si le compteur “SSH” (–name) référence “4″ tentatives (–hitcount) d’entrées sur “IP_EXT” sur le port “PORT_SSH” depuis moins de “60″ secondes, appliquer “SSH_DROP”. Sous entendu : “sinon passe à la règle suivante”.
  • ligne 3 : Si une tentative de connexion est effectuée sur “PORT_SSH” d’”IP_EXT”, incrémente le compteur “SSH”. Encore sous entendu : “sinon passe à la règle suivante”.
  • ligne 4 : accepte les connexion SSH à destination de “IP_EXT”.

En fonctionnement, cela donne :

  • De la première à la quatrième tentative :
    • règle 1 : le compteur SSH < ou = 4, passage à la règle suivante ;
    • règle 2 : incrémente SSH ;
    • règle 3 : autorise la connexion ;
  • Cinquième tentative :
    • règle 1 : compteur SSH > 4, applique SSH_DROP ;
    • chaîne SSH_DROP : log la connexion en la préfixant par “[fw drop -> Attack ssh] : ” puis DROP la connexion.

Résultat

Si nous tentons 5 connexions successives en moins d’une minute, la machine nous fait patienter et consigne l’attaque dans les logs :

18:48:56 fhh@mafalda ~ $ ssh srv
fhh@srv's password: ^c
18:49:01 fhh@mafalda ~ $ ssh srv
fhh@srv's password: ^c
18:49:02 fhh@mafalda ~ $ ssh srv
fhh@srv's password: ^c
18:49:04 fhh@mafalda ~ $ ssh srv
fhh@srv's password: ^c
18:49:05 fhh@mafalda ~ $ ssh srv
--- plus de prompt ---^c

et dans les logs :

1 Dec  8 18:49:24 srv [fw drop -> Attack ssh] :  IN=br0 OUT= MAC=XXXXXXX  
  SRC=XXXXXXXX DST=XXXXXXXXXX LEN=60 TOS=00 PREC=0x00 TTL=64 ID=16030 DF PROTO=TCP
  SPT=57334 DPT=22 SEQ=2340649455 ACK=0 WINDOW=14600 SYN URGP=0

Notes complémentaires

Cette “protection” part des principes (souvent vérifiés) que :

  • les programmes attaquant effectue une tentative d’authentification par connexion ;
  • qu’un programme ne pouvant tester plus de 4/12 mots de passe par minutes délaissera le serveur ciblé.

Côté utilisateur, rappelons qu’iptables contrôle les connexions et non les tentatives d’identification. En général, trois tentatives d’authentification sont possible par connexion via le client SSH. Un utilisateur devrait donc effectuer 12 tentatives de mot de passe infructueuse en moins d’une minute pour ce faire bannir (comportement suffisamment suspect pour justifier de le faire attendre quelques secondes).

Si vous effectuez des sauvegardes via rsync par exemple ou ses dérivés (rsnapshots, etc) utilisant une authentification par couple de clés (publique/privée) pensez a ajouter une règle pour la machine de sauvegarde sous peine de la voir considérée comme attaquante par votre firewall…

Si les attaques persistent, complétez votre stratégie de sécurité par d’autres outils du type fail2ban, etc.

Références

Laisser un commentaire