Attaques en force brute sur les comptes et mots de passe

Si vous devez accéder à distance à des ordinateurs, il est probable que vous utilisez OpenSSH ou SSH, ou que vous avez au moins entendu parler de ces outils. Si vous vous en servez, vous avez certainement constaté que, régulièrement, des attaques sur les mots de passe sont lancées. Les journaux d'activité contiennent des dizaines, voire des centaines de lignes comme

 Failed password for invalid user alias from a.b.c.d port 48345 ssh2
 Failed password for invalid user alias from a.b.c.d port 49209 ssh2
 Failed password for invalid user alumni from a.b.c.d port 49273 ssh2
 Failed password for invalid user alumni from a.b.c.d port 49687 ssh2
 Failed password for invalid user apache2 from a.b.c.d port 52975 ssh2
 Failed password for invalid user apache2 from a.b.c.d port 53734 ssh2 

C'est au minimum irritant, et cela peut devenir angoissant si vos utilisateurs se connectent à cette machine à l'aide de mots de passe (et non pas à l'aide de clés publiques/privées). Lorsque l'on trouve des messages de ce genre dans le journal de bord, c'est soit qu'un utilisateur s'est trompé en indiquant son mot de passe, soit qu'un outil d'attaque "connaît" le compte X et tente différents mots de passe classiques. Dans un tel cas, il est probable que ces attaques finiront, un jour, par trouver un couple compte/mot de passe faible.

Comment se protéger ?

Sshd sur un port non-standard

C'est une suggestion qui est souvent faite : au lieu d'avoir un processus sshd qui attend ses connexions sur le port TCP/22, il est configuré pour écouter sur un autre port (par exemple TCP/2222, ou tout autre port TCP). La logique sous-jacente est de se dire que les outils d'attaque se limitent à des connexions vers le port TCP/22 et que s'ils ne trouvent rien, ils n'iront pas plus loin.

Cette logique est erronée.

L'outil d'attaque se connecte à un port déterminé, et il est vrai que nombre d'entre eux se limitent au port TCP/22. Déplacer le serveur sshd sur un autre port vous rendra invisible pour ces attaquants-là. Mais rien n'empêche l'attaquant de procéder d'abord à une analyse des ports ouverts sur votre machine. Dans ce cas, son outil d'analyse constatera l'existence d'un service ssh sur le port TCP/xyz. Cette information sera ensuite utilisée par l'outil d'attaque ssh, et la seule protection qui vous restera sera la force des mots de passe.

Cela ne signifie pas que vous ne devez pas déplacer votre serveur ssh sur un port non-standard. Cela signifie uniquement que cette précaution est insuffisante.

Contrôle du nombre de connexions

Une autre façon de procéder repose sur l'idée que l'attaquant exécute ses opérations de manière séquentielle et rapide. En bref, il se connecte de nombreuses fois à votre serveur dans un intervalle de temps assez court. Par exemple, par rapport à l'extrait de journaux précédent, l'attaquant a essayé 1500 couples compte/mot de passe en 83 minutes, soit un rythme d'une connexion toutes les trois secondes environ, ou vingt connexions par minute.

Il est évident qu'un tel rythme ne correspond pas à un comportement normal. Cela peut donc servir de discriminant pour identifier une attaque et y réagir. Cependant, n'oubliez pas qu'il suffit à l'attaquant

• de ralentir son programme pour passer en-dessous du seuil de détection
• d'utiliser non pas une seule machine pour mener son attaque, mais un ensemble de système (généralement compromis)

On voit de plus en plus souvent des attaques provenant d'adresses IP différentes mais exploitant à l'évidence une liste commune de comptes et de mots de passe. La protection par blocage suite à un trop grand nombre de tentatives provenant d'une même adresse IP sur un certain intervalle de temps perd donc régulièrement en efficacité.

Analyse des journaux

La première réaction possible repose sur une analyse régulière des journaux, par le biais de la crontab. Toutes les cinq minutes, un programme spécifique va lire le fichier dans lequel sshd inscrit les échecs de connexion. S'il relève plus d'un certain nombre d'accès à des comptes inexistants, ou d'erreurs de mots de passe, ce programme inscrit l'adresse IP source dans une liste noire de blocage. Ce peut être /etc/hosts.deny (si sshd est couplé à tcp_wrappers) ou directement une règle de type iptables.

Une telle solution est efficace, pour peu que le programme soit exécuté à des intervalles adaptés. En effet, l'attaquant est libre de faire tout ce qu'il veut tant qu'il n'est pas détecté. Si le programme de contrôle s'exécute une fois par heure, l'attaquant dispose d'une heure de tranquillité.

Il existe plusieurs outils réalisant cette fonction, comme Fail2Ban ou DenyHosts. Fail2Ban génère des règles (iptables, ipfw ou ipfwadmin) pour bloquer les adresses des impétrants. DenyHosts exécute les mêmes analyses, mais repose sur /etc/deny.hosts (et donc tcp_wrappers) pour le blocage.

Limite des flux réseau

Une autre façon de procéder est de limiter le nombre de connexions (au sens réseau) autorisées pendant un certain laps de temps. On utilise généralement les capacités d'iptables ou de tout autre système de filtrage présent sur le serveur. Par exemple :

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent \
     --set --name SSH -j ACCEPT
 iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 \
     --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH-force "
 iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 \
     --hitcount 4 --rttl --name SSH -j DROP

Ces règles autorisent au maximum 3 connexions ssh par minute provenant d'une même adresse IP. Au-delà de ce seuil, l'adresse IP en question est bloquée pour une minute.

Cette technique (il existe des variantes, par exemple en mettant en place une liste d'adresses qui sont toujours autorisées quel que soit le rythme de connexion) présente l'inconvénient de ne pas faire de distinction entre une connexion réussie et un échec. Si vous avez des utilisateurs fébriles qui, du fait de la longueur des mots de passe que vous imposez, se trompent souvent... ils risquent de ne guère apprécier.

Contrôle affiné

Les solutions précédentes sont efficaces dans beaucoup de cas, et peuvent suffire. Toutefois, il serait intéressant de disposer d'une solution pour

• ne bloquer que les adresses IP à l'origine d'échecs de connexion, et donc faire la différence entre un flot de connexions réussies et un flot de connexions en échec,
• réagir immédiatement, et pas à intervalles réguliers quels qu'ils soient,
• bloquer immédiatement dès le premier accès à un compte inexistant.

C'est ce que fait l'outil sshdfilter (lien rompu), développé par Richard Gregory. sshdfilter réagit en temps réel en provoquant le blocage de toute adresse IP provoquant l'un des messages suivant :

• Did not receive identification string from x.x.x.x
• Illegal user x from x.x.x.x
• Failed password for illegal user x from x.x.x.x port x ssh2
• Failed password for x from x.x.x.x port x ssh2

Le blocage est immédiat pour les trois premières erreurs. La quatrième, qui peut aussi être produite par un utilisateur se trompant de mot de passe, ne provoque de blocage que si elle est répétée.

Notre article sur sshdfilter.