Faire tourner sshd sur un autre port que 22
http://www.bortzmeyer.org/sshd-port-alternatif.html
----------------------------
La plupart des serveurs et routeurs connectés à l'Internet ont un
serveur SSH qui écoute sur le port 22 pour permettre l'accès à distance
et l'administration de la machine. Très souvent, des attaques
automatiques sont lancées contre ces machines. Même si elles échouent,
elles remplissent les journaux et déclenchent des alarmes inutiles. Je
recommande personnellement de ne jamais faire tourner le serveur SSH
sur le port 22.
Voici un exemple d'une attaque réelle (je n'ai pas modifié l'adresse IP
source de l'attaquant car, comme d'habitude, abuse n'a jamais répondu à
mon signalement (http://www.bortzmeyer.org/abuse-ne-repond-pas.html)).
Il s'agit apparemment d'une attaque par dictionnaire classique, où
l'assaillant essaie plusieurs mots de passe classiques pour des comptes
courants dans les pays anglo-saxons (john, adam, kevin) :
Dec 9 05:35:10 mon-serveur sshd[28839]: Invalid user john from 173.45.74.230
Dec 9 05:35:10 mon-serveur sshd[28839]: pam_unix(sshd:auth): check pass; user unknown
Dec 9 05:35:10 mon-serveur sshd[28839]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=e6.4a.2d.static.xlhost.com
Dec 9 05:35:11 mon-serveur sshd[28839]: Failed password for invalid user john from 173.45.74.230 port 40514 ssh2
Dec 9 05:35:12 mon-serveur sshd[28841]: Invalid user john from 173.45.74.230
Dec 9 05:35:12 mon-serveur sshd[28841]: pam_unix(sshd:auth): check pass; user unknown
Dec 9 05:35:12 mon-serveur sshd[28841]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=e6.4a.2d.static.xlhost.com
Dec 9 05:35:14 mon-serveur sshd[28841]: Failed password for invalid user john from 173.45.74.230 port 41395 ssh2
Dec 9 05:35:16 mon-serveur sshd[28843]: Invalid user kevin from 173.45.74.230
Dec 9 05:35:16 mon-serveur sshd[28843]: pam_unix(sshd:auth): check pass; user unknown
Dec 9 05:35:16 mon-serveur sshd[28843]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=e6.4a.2d.static.xlhost.com
Dec 9 05:35:18 mon-serveur sshd[28843]: Failed password for invalid user kevin from 173.45.74.230 port 42402 ssh2
Dec 9 05:35:19 mon-serveur sshd[28845]: Invalid user kevin from 173.45.74.230
Dec 9 05:35:19 mon-serveur sshd[28845]: pam_unix(sshd:auth): check pass; user unknown
Dec 9 05:35:19 mon-serveur sshd[28845]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=e6.4a.2d.static.xlhost.com
Dec 9 05:35:20 mon-serveur sshd[28845]: Failed password for invalid user kevin from 173.45.74.230 port 43071 ssh2
Dec 9 05:35:21 mon-serveur sshd[28847]: Invalid user adam from 173.45.74.230
Dec 9 05:35:21 mon-serveur sshd[28847]: pam_unix(sshd:auth): check pass; user unknown
Dec 9 05:35:21 mon-serveur sshd[28847]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=e6.4a.2d.static.xlhost.com
Dec 9 05:35:23 mon-serveur sshd[28847]: Failed password for invalid user adam from 173.45.74.230 port 43842 ssh2
Dec 9 05:35:24 mon-serveur sshd[28849]: Invalid user adam from 173.45.74.230
Dec 9 05:35:24 mon-serveur sshd[28849]: pam_unix(sshd:auth): check pass; user unknown
Dec 9 05:35:24 mon-serveur sshd[28849]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=e6.4a.2d.static.xlhost.com
Dec 9 05:35:27 mon-serveur sshd[28849]: Failed password for invalid user adam from 173.45.74.230 port 44743 ssh2
Ici, l'attaque a apparemment échoué. Mais, même si le serveur SSH a un
accès restreint (par exemple avec la directive
AllowUsers de OpenSSH),
c'est ennuyeux d'avoir ses journaux encombrés par de telles attaques,
qui sont très courantes. Un script PHP bogué,
une prise de contrôle à distance, même sans passer
root et hop, tout serveur dédié n'importe où
sur la planète commence un balayage systématique des serveurs et
routeurs, pour le compte du craqueur masqué
derrière lui.
Ma méthode préférée pour garder mes journaux courts et pour embêter un
peu les pirates est de faire tourner le serveur sur un autre port. Avec
OpenSSH, c'est :
Port 42666
dans le fichier de configuration. Et, là, plus d'attaques.
J'insiste bien sur le fait que le but principal est d'éviter
l'encombrement des journaux. Changer de port ralentit les craqueurs
mais n'est pas réellement un gros avantage en matière de sécurité
(croire cela serait croire au STO). Un craqueur compétent pourrait
faire un nmap sur le serveur et découvrir le port SSH par la bannière
envoyée :
% telnet mon-serveur 42666
Trying 2001:db8:37a::d946:bee8:232...
Connected to mon-serveur.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.1p1 Debian-5
...
Mais, en pratique, la plupart des attaques sont bêtes et massives. Pas
de subtilité, juste tester le port 22. Sur les serveurs qui écoutent
sur un autre port, on ne voit jamais, à l'heure actuelle, d'attaques
par dictionnaire.
Certaines personnes pensent que changer de port va leur compliquer la
vie à eux aussi, en les obligeant à indiquer le numéro de port à chaque
commande SSH, par exemple à taper ssh -p 42666 mon-serveur au lieu de
ssh mon-serveur. Mais non ; OpenSSH permet de mettre le numéro de port
une fois pour toutes dans le fichier ~/.ssh/config :
Host mon-serveur
Port 42666
et c'est tout, il n'y aura plus rien à taper (si on travaille sur
plusieurs machines, ce qui est mon cas, on peut synchroniser son répertoire (http://www.bortzmeyer.org/home-in-subversion.html)). Même
chose avec un client SSH comme ConnectBot (http://code.google.com/p/connectbot/) sur
Android, qui permet d'indiquer le numéro de
port lors de l'enregistrement d'un serveur.
Existe-t-il d'autres méthodes pour contrarier ce genre d'attaquants ?
Oui, bien sûr, on peut restreindre l'accès à SSH par adresse IP source.
Cela se fait souvent sur les routeurs, qu'on n'administre que depuis le
réseau interne, mais ce n'est pas toujours possible pour les serveurs,
il faut bien pouvoir se connecter à distance. Il y a aussi la
possibilité de faire du « toquage à la porte » avec un logiciel comme
knockd ou avec une solution plus simple
(http://www.debian-administration.org/articles/268). Encore une autre
solution est d'utiliser fail2ban mais je ne l'ai personnellement pas
encore tenté. En sécurité, les solutions les plus simples et les moins
fatigantes sont souvent les meilleures.
Reply to: