Renforcer la sécurité de son serveur SSH

Posted on February 4, 2010 - by Jérôme M.

Renforcer la sécurité de son serveur SSH

Salut! Si tu veux suivre l'actualité de Phollow me plus facilement tu peux souscrire à mon flux RSS et tu seras mis au courant des mises à jour.

Le protocole SSH est utilisé pour transmettre des informations de manière sécurisé entre deux terminaux. Par exemple comme se loguer sur une machine distante, ou échanger des fichiers, le tout crypté. Il est de par sa conception très sécurisé, mais une mauvaise configuration peut tout gâcher.

Fichiers de configuration par défaut

/etc/ssh/sshd_config - Fichier de configuration du serveur SSH.
/etc/ssh/ssh_config – Fichier de configuration du client SSH
~/.ssh/ – Répertoire de configuration SSH d’un utilisateur.
/etc/nologin – Si ce fichier existe, personne ne peut se connecter à part root.
/etc/hosts.allow et /etc/hosts.deny : Blacklist et whitelist .
SSH port par défaut : TCP 22

Utiliser le protocole SSH 2

Le protocole 1 est obsolète et vulnérable à de nombreuses attaques (comme man-in-the-middle). Il doit être évité à tout pris. Vérifiez dans le sshd_config que la ligne suivante existe :

Protocol 2

Choisir les utilisateurs

Par défaut n’importe quel utilisateur à le droit de se connecter en SSH. Par exemple un utilisateur ftp à la possibilité de se connecter. Ce n’est pas super pertinent. Alors on peut restreindre le serveur SSH à n’autoriser que certains compte utilisateur. Pour ça on peut utiliser (toujours dans le sshd_config) :

AllowUsers root rydgel

Qui autorise ces 2 utilisateurs à pouvoir se connecter. Inversement la commande DenyUsers, permet de refuser la connexion.

Désactiver les fichiers .rhosts

Ces fichiers permettent de se connecter automatiquement au serveur sans avoir besoin de retaper le mot de passe. Sympa pour les feignants mais pas sécurisé du tout. Donc il vaut mieux désactiver l’utilisation de ces fichiers avant que quelqu’un ne tombe dessus ;)

IgnoreRhosts yes

Ajouter un timeout sur l’inactivité

Garder la session ouverte indéfiniment n’est pas non plus une bonne idée. Vous êtes au boulot, vous vous absentez une heure ou deux et vous oubliez de fermer votre session, n’importe qui peut attraper votre shell en root et faire ce qu’il veut pendant votre absence.

ClientAliveInterval 360
ClientAliveCountMax 0

Désactiver le login de root

Une autre manière de sécuriser est de désactiver 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 priorité ce port, pour le changer c’est tout simple :

Port 6345

N’autoriser que certaines IP à se connecter

Par exemple si je veux que seulement ces 2 adresses IP ait le droit de se connecter sur mon serveur (192.168.1.5 et 202.54.1.5). Il y a deux solutions. La première est d’utiliser les fichiers /etc/hosts.allow et /etc/hosts.deny. On commence par bloquer toutes les IPs dans le hosts.deny, puis on autorise seulement 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 solution (et la meilleure à mon avis) est d’utiliser le firewall du système (iptables, pf) et d’autoriser seulement les IPs que l’on veut sur le port d’OpenSSH.

Utiliser un bon mot de passe

On voit encore trop souvent des mots de passe du style ‘12345′ ou ‘admin’. Le plus simple est de se créer un mot passe aléatoirement avec des chiffres, des lettres (majuscules et minuscules) et des caractères spéciaux. http://www.goodpassword.com/ est un site qui permet de le faire pour vous :)

Personne ne doit avoir un mot de passe vide

Vérifiez que les utilisateurs de votre machine n’ont pas de mot de passe vide. On peut aussi dire à OpenSSH de ne pas accepter les connexions d’utilisateurs sans mot de passe.

PermitEmptyPasswords no

Garder OpenSSH et votre système à jour

On ne le dira jamais assez mais les mises-à-jour sont vraiment importantes. Elles corrigent la plupart du temps des failles qui peuvent être utilisées par des pirates pour compromettre votre système. Personnellement je regarde si des mises à jours de sécurité sont disponibles tous les jours.

Désactiver OpenSSH si vous ne l’utilisez pas

Ça ne sert à rien de laisser des services ouverts sur l’ordinateur si vous ne vous en servez pas. Désinstallez le serveur openSSH s’il n’est pas utilisé. Ça fera toujours une porte de moins pour accéder à votre machine.

Conclusion

Il y a encore des dizaines de manips possibles pour augmenter encore plus la sécurité, comme le chrootage des utilisateurs, la configuration d’un firewall, l’installation de fail2ban contre les attaques brute-force etc. Mais je pense que ce petit article est un bon début, pour éviter de faire des bêtises sur son serveur.

This entry was posted on Thursday, February 4th, 2010 at 14:28 and is filed under linux, tutoriel. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

31 Comments

We'd love to hear yours!

Visit My Website
February 4, 2010
Permalink
phollow said:

Renforcer la sécurité de son serveur SSH http://goo.gl/fb/0bSC
This comment was originally posted on Twitter
Reply
Visit My Website
February 4, 2010
Permalink
gonzague said:

RT @phollow: Renforcer la sécurité de son serveur SSH http://goo.gl/fb/0bSC
This comment was originally posted on Twitter
Reply
Visit My Website
February 4, 2010
Permalink
cr0vax said:

RT @phollow: Renforcer la sécurité de son serveur SSH http://goo.gl/fb/0bSC
This comment was originally posted on Twitter
Reply
Visit My Website
February 4, 2010
Permalink
Gonzague said:

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 ^_^
Reply
- Visit My Website
  February 4, 2010
  Permalink
  Jérôme M. said:
  
  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
  Reply
Visit My Website
February 4, 2010
Permalink
LGnap said:

Simple, basique mais hyper pratique ^^ -> à mettre en favoris ;-)
Reply
Visit My Website
February 4, 2010
Permalink
kmb said:

« Le protocole openSSH est utiliser »
-> utilisé
-> OpenSSH n’est pas un protocole
Reply
- Visit My Website
  February 4, 2010
  Permalink
  Jérôme M. said:
  
  fixed ;)
  thanks
  Reply
Visit My Website
February 4, 2010
Permalink
kmb said:

presque, SSH pas SSL ;-)
Bonne journée
Reply
Visit My Website
February 4, 2010
Permalink
pydubreucq said:

RT @phollow: Renforcer la sécurité de son serveur SSH http://goo.gl/fb/0bSC
This comment was originally posted on Twitter
Reply
Visit My Website
February 4, 2010
Permalink
Edouard said:

« Il doit être éviter à tout pris » -> Il doit être évité à tout prix
Bookmarked !
Reply
Visit My Website
February 4, 2010
Permalink
hobbestigrou said:

RT @phollow: Renforcer la sécurité de son serveur SSH http://goo.gl/fb/0bSC
This comment was originally posted on Twitter
Reply
Visit My Website
February 4, 2010
Permalink
Nicolas said:

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.
Reply
- Visit My Website
  February 4, 2010
  Permalink
  Axel said:
  
  +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.
  Reply
- Visit My Website
  February 4, 2010
  Permalink
  Jérôme M. said:
  
  Autant pour moi, je corrigerai ça ce soir.
  Reply
Visit My Website
February 4, 2010
Permalink
DuaelFr said:

RT @phollow: Renforcer la sécurité de son serveur SSH http://goo.gl/fb/0bSC
This comment was originally posted on Twitter
Reply
Visit My Website
February 4, 2010
Permalink
Alex57185 said:

RT @talktweetmeme Renforcer la sécurité de son serveur SSH http://goo.gl/fb/0bSC
This comment was originally posted on Twitter
Reply
Visit My Website
February 4, 2010
Permalink
tshirtman said:

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….
Reply
- Visit My Website
  February 4, 2010
  Permalink
  Jérôme M. said:
  
  Waip j’en ai parlé de ça :)
  Reply
- Visit My Website
  February 5, 2010
  Permalink
  louiz’ said:
  
  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.
  Reply
  - Visit My Website
    February 5, 2010
    Permalink
    Jérôme M. said:
    
    Tout à fait !
    Reply
Visit My Website
February 4, 2010
Permalink
Logive said:

RT @phollow: Renforcer la sécurité de son serveur SSH http://goo.gl/fb/0bSC
This comment was originally posted on Twitter
Reply
Visit My Website
February 4, 2010
Permalink
S4RuM4N said:

RT @phollow: Renforcer la sécurité de son serveur SSH http://goo.gl/fb/0bSC
This comment was originally posted on Twitter
Reply
Visit My Website
February 4, 2010
Permalink
Edouard said:

à tout priX ;)
Reply
Visit My Website
February 4, 2010
Permalink
Bristow said:

Merci pour tous ces rappels, c’est toujours mieux en français et avec quelques phrases d’explications ;)
Reply
Visit My Website
February 4, 2010
Permalink
bartounet said:

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.
Reply
- Visit My Website
  February 11, 2010
  Permalink
  Alex said:
  
  Le SPA (single packet authorization) pallie à de nombreux défaut du port-knocking.
  Sujet intéressant car c’est un grand classique.
  Reply
Visit My Website
February 5, 2010
Permalink
feilong said:

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.
Reply
Visit My Website
February 5, 2010
Permalink
lepingouin said:

Renforcer la sécurité de son serveur SSH | Phollow.me http://bit.ly/cMFkh0
This comment was originally posted on Twitter
Reply
Visit My Website
February 5, 2010
Permalink
dk88 said:

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
Reply
Visit My Website
February 15, 2010
Permalink
Darth_K0d3R said:

RT @talktweetmeme Renforcer la sécurité de son serveur SSH http://goo.gl/fb/0bSC
This comment was originally posted on Twitter
Reply