Renforcer la sécurité de son serveur SSH

Le pro­to­cole SSH est uti­lisé pour trans­mettre des infor­ma­tions de manière sécu­risé entre deux ter­mi­naux. Par exemple comme se loguer sur une machine dis­tante, ou échan­ger des fichiers, le tout crypté. Il est de par sa concep­tion très sécu­risé, mais une mau­vaise confi­gu­ra­tion peut tout gâcher.

Fichiers de confi­gu­ra­tion par défaut

  • /etc/ssh/sshd_config - Fichier de confi­gu­ra­tion du ser­veur SSH.
  • /etc/ssh/ssh_config - Fichier de confi­gu­ra­tion du client SSH
  • ~/.ssh/ - Répertoire de confi­gu­ra­tion SSH d'un utilisateur.
  • /etc/nologin - Si ce fichier existe, per­sonne ne peut se connec­ter à part root.
  • /etc/hosts.allow et /etc/hosts.deny : Blacklist et whitelist .
  • SSH port par défaut : TCP 22

Utiliser le pro­to­cole SSH 2

Le pro­to­cole 1 est obso­lète et vul­né­rable à de nom­breuses attaques (comme man-in-the-middle). Il doit être évité à tout pris. Vérifiez dans le sshd_config que la ligne sui­vante existe :

Protocol 2

Choisir les utilisateurs

Par défaut n'importe quel uti­li­sa­teur à le droit de se connec­ter en SSH. Par exemple un uti­li­sa­teur ftp à la pos­si­bi­lité de se connec­ter. Ce n'est pas super per­ti­nent. Alors on peut res­treindre le ser­veur SSH à n'autoriser que cer­tains compte uti­li­sa­teur. Pour ça on peut uti­li­ser (tou­jours dans le sshd_config)  :

AllowUsers root rydgel

Qui auto­rise ces 2 uti­li­sa­teurs à pou­voir se connec­ter. Inversement la com­mande DenyUsers, per­met de refu­ser la connexion.

Désactiver les fichiers .rhosts

Ces fichiers per­mettent de se connec­ter auto­ma­ti­que­ment au ser­veur sans avoir besoin de reta­per le mot de passe. Sympa pour les fei­gnants mais pas sécu­risé du tout. Donc il vaut mieux désac­ti­ver l'utilisation de ces fichiers avant que quelqu'un ne tombe dessus ;)

IgnoreRhosts yes

Ajouter un timeout sur l'inactivité

Garder la ses­sion ouverte indé­fi­ni­ment n'est pas non plus une bonne idée. Vous êtes au bou­lot, vous vous absen­tez une heure ou deux et vous oubliez de fer­mer votre ses­sion, n'importe qui peut attra­per votre shell en root et faire ce qu'il veut pen­dant votre absence.

ClientAliveInterval 360
ClientAliveCountMax 0

Désactiver le login de root

Une autre manière de sécu­ri­ser est de désac­ti­ver le login de root et d'utiliser un user avec des droits moindres + sudo.

PermitRootLogin no

Changer le port par défaut d'openSSH

Le port 22 est connu par tous les pirates pour être celui d'openSSH. Les robots scannent en prio­rité ce port, pour le chan­ger c'est tout simple :

Port 6345

N'autoriser que cer­taines IP à se connecter

Par exemple si je veux que seule­ment ces 2 adresses IP ait le droit de se connec­ter sur mon ser­veur (192.168.1.5 et 202.54.1.5). Il y a deux solu­tions. La pre­mière est d'utiliser les fichiers /etc/hosts.allow et /etc/hosts.deny. On com­mence par blo­quer toutes les IPs dans le hosts.deny, puis on auto­rise seule­ment celles que l'on veut.

dans /etc/hosts.deny :
sshd: ALL
On bloque par défaut toutes les IPs, puis dans le /etc/hosts.allow :
sshd: 192.168.1.5
sshd: 202.54.1.5

La deuxième solu­tion (et la meilleure à mon avis) est d'utiliser le fire­wall du sys­tème (iptables, pf) et d'autoriser seule­ment les IPs que l'on veut sur le port d'OpenSSH.

Utiliser un bon mot de passe

On voit encore trop sou­vent des mots de passe du style '12345' ou 'admin'. Le plus simple est de se créer un mot passe aléa­toi­re­ment avec des chiffres, des lettres (majus­cules et minus­cules) et des carac­tères spé­ciaux. http://www.goodpassword.com/ est un site qui per­met de le faire pour vous :)

Personne ne doit avoir un mot de passe vide

Vérifiez que les uti­li­sa­teurs de votre machine n'ont pas de mot de passe vide. On peut aussi dire à OpenSSH de ne pas accep­ter les connexions d'utilisateurs sans mot de passe.

PermitEmptyPasswords no

Garder OpenSSH et votre sys­tème à jour

On ne le dira jamais assez mais les mises-à-jour sont vrai­ment impor­tantes. Elles cor­rigent la plu­part du temps des failles qui peuvent être uti­li­sées par des pirates pour com­pro­mettre votre sys­tème. Personnellement je regarde si des mises à jours de sécu­rité sont dis­po­nibles tous les jours.

Désactiver OpenSSH si vous ne l'utilisez pas

Ça ne sert à rien de lais­ser des ser­vices ouverts sur l'ordinateur si vous ne vous en ser­vez pas. Désinstallez le ser­veur openSSH s'il n'est pas uti­lisé. Ça fera tou­jours une porte de moins pour accé­der à votre machine.

Conclusion

Il y a encore des dizaines de manips pos­sibles pour aug­men­ter encore plus la sécu­rité, comme le chroo­tage des uti­li­sa­teurs, la confi­gu­ra­tion d'un fire­wall, l'installation de fail2ban contre les attaques brute-force etc. Mais je pense que ce petit article est un bon début, pour évi­ter de faire des bêtises sur son serveur.



Post comment as twitter logo facebook logo
Sort: Newest | Oldest

Pour l'histoire du mot de passe, le mieux est évidement de ne travailler que par clef.
Sinon pour générer un mot de passe "aléatoire", tu as la commande pwgen

L'authentification par clé public et clé privée serait un plus également.
Si tu veux limiter l'accès à une adresse ip ou à un sous réseau, il faut passer par une configuration de iptables me semble t il.

Tu aurais aussi put parler du port knocking, un bon moyen de se protéger tout en laissant ouvert un accès de n'importe ou.

Le SPA (single packet authorization) pallie à de nombreux défaut du port-knocking.
Sujet intéressant car c'est un grand classique.

Merci pour tous ces rappels, c'est toujours mieux en français et avec quelques phrases d'explications ;)

Autoriser root à se connecter est une mauvaise idées, il y des bots qui bruteforces les mots de passes (d'ou l'intérêt de fail2ban) et avoir un user aussi commun que root autorisé, surtout avec les droits que ça impliques, c'est prendre un risque inutile... donc allowRootLogin = False ;)
je vois moins l'intérêt du changement de port, c'est juste de l'obscurité, mais bon....

Waip j'en ai parlé de ça :)

Ben le changement de port ça sert déjà à éviter tous les bots qui tentent des centaines d'users et de login sur des centaines de machines, au hasard.

la partie «N’autoriser que certaines IP à se connecter» est fausse, en aucun cas la directive ListenAdress ne limite les IPs qui sont autorisée à se connectées sur un serveur SSH.

+1 pour le Listen Adress. Il permet juste de spécifier les interfaces d'écoute.
Celà dit tu as raison, il faut aussi filtrer les IPs entrantes.
Je pense qu'il faudrait également penser à désactiver le tunneling, SFTP, et SCP s'il y en a pas besoin et forcer explicitement l'utilisation d'algorithme de chiffrement authentification le plus robustes.

Autant pour moi, je corrigerai ça ce soir.

"Il doit être éviter à tout pris" -> Il doit être évité à tout prix
Bookmarked !

presque, SSH pas SSL ;-)
Bonne journée

"Le protocole openSSH est utiliser "
-> utilisé
-> OpenSSH n'est pas un protocole

Simple, basique mais hyper pratique ^^ -> à mettre en favoris ;-)

le changement de port ça te protège des script kiddies tout au plus non? :-)
J'aurai bien ajouté qu'un petit fail2ban ne fait pas de mal ^_^

Waip j'en parle à la fin de fail2ban ;)
Mais je pense qu'il mérite à lui seul un billet, tellement on peut s'amuser avec :D

Agréable à lire ton article et bon mémo.
Pour ma part je laisse en port 22, c'est chiant quand on fait des "scp" ou "shh" de toujours devoir spécifier les ports. Un bon mot de passe c'est presque incassable, root interdit avec un seul utilisateur admis.
En plus j'utilise iptables pour bloquer le brut force: au tout début de mon script Firewall j'interdis tout puis je mets les lignes si dessous.
Le principe 3 tentatives de connexions sans succès -> adresse ip bloquer 600 secondes(10min) avec log IP bloques dans /var/log/syslog .
iptables est implémenté dans le noyau donc prioritaire sur OpenSSHd. Quand iptables bloque l'IP, SSHd ne sait même pas que cette ip essaye encore de se connecter!
Simple et super efficace. Pas besoin de fail2ban
parametres important:
-dport: numéro port SSHd
-seconds: nombre de secondes de bannissement
-hitcount: nombre de tentatives acceptable avant banissement
Attention respecter l'ordre des lignes "iptables"
### Acces SSH et BLOCAGE IP après 3 tentatives de connexions
# DROP acces SSH si force brut
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 600 --hitcount 3 --name NMAP -j LOG --log-prefix " IP BANISE SSH FORCE BRUTE "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 600 --hitcount 3 --name NMAP -j DROP
iptables -A INPUT -p tcp --dport 22 -m recent --set --name NMAP -j ACCEPT
# SSH
iptables -t filter -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
iptables -t filter -A OUTPUT -o eth0 -p tcp --dport 22 -j ACCEPT

Merci pour ces infos !

Pour l'histoire du mot de passe, le mieux est évidement de ne travailler que par clef.
Sinon pour générer un mot de passe "aléatoire", tu as la commande pwgen

L'authentification par clé public et clé privée serait un plus également.
Si tu veux limiter l'accès à une adresse ip ou à un sous réseau, il faut passer par une configuration de iptables me semble t il.

@feilong +1
cles + iptables ... y a que ca de vrai.

Tu aurais aussi put parler du port knocking, un bon moyen de se protéger tout en laissant ouvert un accès de n'importe ou.

Le SPA (single packet authorization) pallie à de nombreux défaut du port-knocking.
Sujet intéressant car c'est un grand classique.

Merci pour tous ces rappels, c'est toujours mieux en français et avec quelques phrases d'explications ;)

Autoriser root à se connecter est une mauvaise idées, il y des bots qui bruteforces les mots de passes (d'ou l'intérêt de fail2ban) et avoir un user aussi commun que root autorisé, surtout avec les droits que ça impliques, c'est prendre un risque inutile... donc allowRootLogin = False ;)
je vois moins l'intérêt du changement de port, c'est juste de l'obscurité, mais bon....

Waip j'en ai parlé de ça :)

Ben le changement de port ça sert déjà à éviter tous les bots qui tentent des centaines d'users et de login sur des centaines de machines, au hasard.

la partie «N’autoriser que certaines IP à se connecter» est fausse, en aucun cas la directive ListenAdress ne limite les IPs qui sont autorisée à se connectées sur un serveur SSH.

+1 pour le Listen Adress. Il permet juste de spécifier les interfaces d'écoute.
Celà dit tu as raison, il faut aussi filtrer les IPs entrantes.
Je pense qu'il faudrait également penser à désactiver le tunneling, SFTP, et SCP s'il y en a pas besoin et forcer explicitement l'utilisation d'algorithme de chiffrement authentification le plus robustes.

Autant pour moi, je corrigerai ça ce soir.

"Il doit être éviter à tout pris" -> Il doit être évité à tout prix
Bookmarked !

presque, SSH pas SSL ;-)
Bonne journée

"Le protocole openSSH est utiliser "
-> utilisé
-> OpenSSH n'est pas un protocole

Simple, basique mais hyper pratique ^^ -> à mettre en favoris ;-)

le changement de port ça te protège des script kiddies tout au plus non? :-)
J'aurai bien ajouté qu'un petit fail2ban ne fait pas de mal ^_^

Waip j'en parle à la fin de fail2ban ;)
Mais je pense qu'il mérite à lui seul un billet, tellement on peut s'amuser avec :D