Faire tourner sshd sur un autre port que 22

Le
Stephane Bortzmeyer
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æ.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æ.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æ.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æ.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æ.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æ.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-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20101217130017.GA31515@nic.fr
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Daniel Huhardeaux
Le #22934741
Bonjour

Le 17/12/2010 14:00, Stephane Bortzmeyer a écrit :
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.




Cela fait des années que j'applique cette règle et ne m'en porte que mieux

[...]
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




Tout à fait. Mais attention, cela ne fonctionne pas avec scp

[...]

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.



Fail2ban est parfait pour bloquer ce genre d'attaques. Il ne faut pas
oublier que certains services se doivent de tourner sur le port qui leur
est défini (IAX, SIP, H323, ...). Fail2ban est alors le compagnon
indispensable. Combien de serveurs VOIP sont attaqués et ce avec
réussite, la légèreté de programmation des règles du dialplan et de la
définition des clients étant dans la très grande majorité des cas
responsable de la cette réussite.

--
Daniel

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
giggzounet
Le #22934881
Bonjour,

[snip]

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.




Mon pc s'intègre au réseau de l'université où je bosse. Je ne peux
malheureusement pas changé de port pour ssh (sinon je ne peux plus me
connecter de l'extérieur...). J'ai adopté fail2ban et ça marche très
bien. J'ai de la visite sur mon port ssh 3 à 4 fois par jour et fail2ban
me vire tout ça fissa et m'envoie un mail.

le changement de port j'ai fait ça à la maison et ça marche super bien
aussi.

Bye

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/iefqr5$uoq$
Alain Vaugham
Le #22935731
Le Friday 17 December 2010 14:00:17 Stephane Bortzmeyer, vous avez écrit  :

Existe-t-il d'autres méthodes pour contrarier ce genre d'attaquants ?



Voici ce que j'utilise :

Pour ssh
En plus de changer le port d'écoute par défaut, j'interdit l'accès ro ot et
j'oblige l'identification par clefs.
$ ssh -ple-bon-port commande

Pour scp
$ scp -Ple-bon-port -rCp la-source la-cible


--
Alain Vaugham
Clef GPG : 0xD26D18BC

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Yves Rutschle
Le #22935741
On Fri, Dec 17, 2010 at 03:07:32PM +0100, giggzounet wrote:
Mon pc s'intègre au réseau de l'université où je bosse. Je ne peux
malheureusement pas changé de port pour ssh (sinon je ne peux plus me
connecter de l'extérieur...).



On peut le mettre derrière un port connu (par exemple 443),
ça peut aider.

Y.

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Daniel Huhardeaux
Le #22935801
Le 17/12/2010 18:19, Yves Rutschle a écrit :
On Fri, Dec 17, 2010 at 03:07:32PM +0100, giggzounet wrote:

Mon pc s'intègre au réseau de l'université où je bosse. Je ne peux
malheureusement pas changé de port pour ssh (sinon je ne peux plus me
connecter de l'extérieur...).



On peut le mettre derrière un port connu (par exemple 443),
[...]



Mais non, déjà pris par OpenVPN ;-)
--
Daniel

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Nicolas KOWALSKI
Le #22935861
Stephane Bortzmeyer
En sécurité, les solutions les plus simples et les moins fatigantes
sont souvent les meilleures.



Le petit script iptables ci-dessous met dehors toutes les attaques par
dictionnaire (plus de 3 connexions par minutes sur le ssh, et l'IP
source est bloquée), sans avoir besoin de changer le port d'écoute du
serveur. On peut whitelister également une IP, avant la règle du DROP,
comme indiqué. Coût (temps, logiciel, ...) de maintenance, zéro.

# iptables-save
# Generated by iptables-save v1.4.2 on Fri Dec 17 18:45:42 2010
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s <ip-whitelistee>/32 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource
-A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH --rsource -j DROP
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT


Simple, non ? ;-)

--
Nicolas

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Stephane Bortzmeyer
Le #22935971
On Fri, Dec 17, 2010 at 02:15:43PM +0100,
Daniel Huhardeaux a message of 65 lines which said:

Host mon-serveur
Port 42666




Tout à fait. Mais attention, cela ne fonctionne pas avec scp



Je regrette mais c'est tout à fait faux (et je viens de re-tester, et
ça marche, et -v indique bien le port utilisé).

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Jean-Michel OLTRA
Le #22936221
Bonjour,


Le vendredi 17 décembre 2010, Stephane Bortzmeyer a écrit...


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.



J'utilise :

- L'authentification par clefs ;
- fail2ban ;
- ossec hids et la réponse active ;
- iptables avec ipset pour bloquer les méchants pendant un certain temps.

--
jm

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Stephane Bortzmeyer
Le #22936401
On Fri, Dec 17, 2010 at 06:37:53PM +0100,
Alain Vaugham a message of 29 lines which said:

j'oblige l'identification par clefs.



C'est sûr que c'est sûr mais cela peut entrainer le blocage de
l'administrateur hors de son propre serveur, s'il n'a pas son
ordinateur sous la main (on peut voir ça comme un avantage pour la
sécurité : l'administrateur ne devrait pas se loguer en SSH en
utilisant une machine quelconque).

Ceci dit, sur Android, je ne connais aucun client SSH qui puisse
utiliser les clés pour l'authentification.

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Julien
Le #22936461
--=-Yxy3oSBBs60RRGCa5b+t
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le vendredi 17 décembre 2010 à 21:55 +0100, Jean-Michel OLTRA a écrit :
- iptables avec ipset pour bloquer les méchants pendant un certain
temps.




merci pour ipset ça a l'air puissant.

--=-Yxy3oSBBs60RRGCa5b+t
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEABECAAYFAk0L2egACgkQIBi0W4jHPjDNiACffZzMH+d8M7YOmAHRS5ZyMMYp
5k0Ani3g1PIK6Xe3w1kRLDhY0zssxJT4
=ObJ2
-----END PGP SIGNATURE-----

--=-Yxy3oSBBs60RRGCa5b+t--

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Publicité
Poster une réponse
Anonyme