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. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20101217130017.ga31...@nic.fr
