Hub de Connaissances DevOps
Hub de Connaissances DevOps

10 bonnes pratiques essentielles pour le durcissement de votre serveur SSH

Sécurisez immédiatement votre environnement d'accès à distance grâce à ce guide complet sur le durcissement du serveur SSH. Découvrez 10 bonnes pratiques essentielles, notamment le changement du port par défaut, la désactivation de l'authentification root et par mot de passe au profit des clés SSH, et la mise en œuvre de règles de pare-feu robustes. Apprenez à limiter l'accès des utilisateurs, à utiliser des phrases de passe solides et à déployer Fail2Ban pour la protection contre les attaques par force brute. Des conseils essentiels sur la mise à jour des logiciels et la surveillance des journaux complètent ce guide pratique, garantissant que vos serveurs sont protégés contre les attaques courantes et les accès non autorisés.

38 vues

10 Bonnes Pratiques Essentielles pour Sécuriser Votre Serveur SSH

Secure Shell (SSH) est l'épine dorsale de l'administration de serveurs à distance, fournissant un protocole réseau cryptographique pour une communication de données sécurisée, l'exécution de commandes à distance et d'autres services réseau. Cependant, sa nature omniprésente en fait également une cible privilégiée pour les attaquants. Un serveur SSH mal sécurisé peut ouvrir une vulnérabilité critique, entraînant un accès non autorisé, des violations de données et un compromis du système. La protection de votre environnement d'accès à distance n'est pas seulement une bonne pratique ; c'est une nécessité.

Cet article présente 10 bonnes pratiques essentielles pour renforcer la configuration de votre serveur SSH. En mettant en œuvre ces directives de configuration critiques, les paramètres d'autorisation recommandés et les conseils de sécurité, vous pouvez renforcer considérablement les défenses de votre serveur contre les accès non autorisés et les vecteurs d'attaque courants comme les tentatives de force brute et le bourrage d'identifiants. Le respect de ces directives contribuera à garantir que votre administration à distance reste sécurisée et que votre infrastructure serveur est protégée.

1. Changer le Port SSH par Défaut

Le port SSH par défaut est 22. Il est universellement connu et constamment scanné par des robots automatisés à la recherche de serveurs vulnérables. Changer le port par défaut offre une couche d'obscurité simple, mais efficace. Bien que ce ne soit pas une mesure de sécurité en soi, cela réduit considérablement le bruit des analyses automatisées et aide à éviter de nombreuses attaques opportunistes.

Pour changer le port, modifiez le fichier sshd_config, généralement situé à l'emplacement /etc/ssh/sshd_config.

sudo nano /etc/ssh/sshd_config

Recherchez la ligne Port 22 (ou ajoutez-la si elle n'existe pas) et remplacez 22 par un numéro de port non standard et non attribué (par exemple, 2222, 49152-65535 sont des ports utilisateurs/dynamiques).

#Port 22
Port 2222

Après avoir enregistré le fichier, redémarrez le service SSH. N'oubliez pas de mettre à jour vos règles de pare-feu pour autoriser le trafic sur le nouveau port et bloquer l'ancien.

sudo systemctl restart sshd
# Pour UFW (Uncomplicated Firewall) :
sudo ufw allow 2222/tcp
sudo ufw deny 22/tcp
sudo ufw reload
# Pour Firewalld :
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --permanent --remove-port=22/tcp
sudo firewall-cmd --reload

Astuce : Laissez toujours au moins une session SSH ouverte tout en testant les modifications de configuration. Si vous êtes bloqué, vous pouvez annuler les modifications dans la session active.

2. Désactiver la Connexion Root

La connexion directe en tant que root via SSH est fortement déconseillée. L'utilisateur root dispose de privilèges illimités, ce qui en fait une cible de choix pour les attaquants. Si un attaquant obtient l'accès root, il a le contrôle total de votre système. Connectez-vous plutôt en tant qu'utilisateur régulier sans privilèges, puis utilisez sudo pour effectuer des tâches administratives.

Dans sshd_config, trouvez la directive PermitRootLogin et définissez-la sur no.

PermitRootLogin no

Enregistrez et redémarrez le service SSH :

sudo systemctl restart sshd

3. Utiliser l'Authentification par Clé

L'authentification par mot de passe est susceptible aux attaques par force brute et aux attaques par dictionnaire, surtout si les utilisateurs choisissent des mots de passe faibles. L'authentification par clé SSH est une alternative bien plus sûre. Elle utilise une paire de clés cryptographiques : une clé publique stockée sur le serveur et une clé privée conservée sur votre machine locale. Seuls les clients possédant la clé privée correspondante peuvent s'authentifier.

Étapes pour implémenter l'authentification par clé (brièvement) :

  1. Générez une paire de clés sur votre machine locale :
    bash ssh-keygen -t ed25519 -b 4096 -C "[email protected]"
    • ed25519 est un algorithme moderne et sécurisé. rsa est également courant, souvent avec -b 4096 pour la robustesse de la clé.
  2. Copiez la clé publique sur votre serveur :
    bash ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your_server_ip
    Alternativement, ajoutez manuellement le contenu de ~/.ssh/id_ed25519.pub au fichier ~/.ssh/authorized_keys sur le serveur pour l'utilisateur sous lequel vous souhaitez vous connecter.

  3. Assurez-vous que les autorisations sont correctes sur le serveur :

    • Répertoire ~/.ssh : 700 (lecture/écriture/exécution uniquement pour le propriétaire)
    • Fichier ~/.ssh/authorized_keys : 600 (lecture/écriture uniquement pour le propriétaire)

    bash chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys

4. Désactiver l'Authentification par Mot de Passe

Une fois que vous avez configuré et testé avec succès l'authentification par clé pour tous les utilisateurs nécessaires, vous devez désactiver complètement l'authentification par mot de passe. Cela supprime le maillon faible de la sécurité SSH en rendant impossibles les attaques par force brute de mots de passe.

Dans sshd_config, définissez PasswordAuthentication sur no.

PasswordAuthentication no

Enregistrez et redémarrez le service SSH :

sudo systemctl restart sshd

Avertissement : Ne désactivez jamais l'authentification par mot de passe avant d'avoir vérifié que l'authentification par clé fonctionne correctement pour tous les utilisateurs ayant besoin d'un accès. Sinon, vous risquez de vous enfermer hors du serveur.

5. Limiter l'Accès Utilisateur

Par défaut, tout compte utilisateur sur le serveur peut tenter de se connecter via SSH. Vous pouvez restreindre l'accès SSH uniquement à des utilisateurs ou groupes spécifiques, minimisant ainsi la surface d'attaque.

Utilisez les directives AllowUsers ou AllowGroups dans sshd_config.

Pour autoriser uniquement des utilisateurs spécifiques (par exemple, adminuser, devuser) :

AllowUsers adminuser devuser

Pour autoriser uniquement les membres d'un groupe spécifique (par exemple, sshusers) :

AllowGroups sshusers

Astuce : Il est généralement préférable d'utiliser AllowGroups si vous avez plusieurs utilisateurs. Créez un groupe dédié pour l'accès SSH et ajoutez-y les utilisateurs autorisés.

sudo groupadd sshusers
sudo usermod -aG sshusers adminuser
sudo usermod -aG sshusers devuser

Après avoir effectué les modifications, enregistrez et redémarrez SSH.

6. Utiliser des Phrases Secrètes Fortes pour les Clés SSH

Bien que l'authentification par clé soit robuste, votre clé privée reste un atout critique. Si un attaquant accède à votre machine locale, il pourrait voler votre clé privée. Une phrase secrète forte chiffre votre clé privée, nécessitant la phrase secrète pour la déverrouiller avant utilisation. Cela ajoute une couche de sécurité supplémentaire, protégeant votre clé même si elle tombe entre de mauvaises mains.

Lors de la génération de votre clé SSH (comme à l'étape 3), il vous sera demandé une phrase secrète. Choisissez une phrase secrète longue, complexe et mémorable, différente de tout autre mot de passe que vous utilisez.

7. Implémenter la Limitation du Taux de Connexion (Fail2Ban)

Même avec l'authentification par clé, un serveur SSH est toujours soumis à des tentatives de connexion. Des outils comme Fail2Ban peuvent surveiller activement les journaux SSH pour détecter des tentatives de connexion infructueuses répétées à partir de la même adresse IP et bloquer automatiquement cette adresse IP à l'aide de règles de pare-feu pendant une période définie.

Installation (exemple pour Debian/Ubuntu) :

sudo apt update
sudo apt install fail2ban

Fail2Ban fonctionne dès l'installation avec les règles SSH par défaut, mais vous pouvez personnaliser sa configuration en copiant jail.conf dans jail.local et en l'éditant.

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Dans jail.local, vous pouvez ajuster bantime, findtime et maxretry pour la section [sshd].

[sshd]
enabled = true
port = 2222 # Votre nouveau port SSH
logpath = %(sshd_log)s
maxretry = 3
bantime = 1h # Bannir pendant 1 heure
findtime = 10m # Rechercher 3 échecs dans un délai de 10 minutes

Redémarrez Fail2Ban après les modifications de configuration :

sudo systemctl restart fail2ban

8. Maintenir Votre Logiciel Serveur SSH à Jour

Des vulnérabilités logicielles sont constamment découvertes et corrigées. L'exécution d'un logiciel de démon SSH (OpenSSH) obsolète signifie que vous pourriez être exposé à des exploits connus. La mise à jour régulière des logiciels de votre serveur, y compris le paquet OpenSSH server, est cruciale pour corriger les failles de sécurité.

# Pour Debian/Ubuntu :
sudo apt update && sudo apt upgrade

# Pour CentOS/RHEL :
sudo yum update
# ou
sudo dnf update

Configurez votre système pour appliquer les mises à jour de sécurité automatiquement lorsque cela est approprié, ou établissez une routine pour les mises à jour manuelles.

9. Surveiller les Journaux SSH pour Activité Suspecte

Même avec des mesures préventives robustes, la vigilance est essentielle. Examinez régulièrement les journaux d'authentification SSH pour détecter des schémas inhabituels, des tentatives de connexion infructueuses ou des tentatives d'accès non autorisées. Cela vous aide à identifier des compromissions potentielles ou des attaques en cours.

Les journaux SSH se trouvent généralement dans :

  • /var/log/auth.log (Debian/Ubuntu)
  • /var/log/secure (CentOS/RHEL)
  • En utilisant journalctl (systèmes systemd) :
    bash sudo journalctl -u sshd -f

Recherchez les tentatives d'authentification échouées répétées, les connexions provenant d'adresses IP inhabituelles ou les connexions réussies par des utilisateurs inconnus. Des outils comme Logwatch ou Elastic Stack (ELK) peuvent automatiser l'analyse des journaux et les alertes pour les environnements plus vastes.

10. Configurer les Règles de Pare-feu pour Restreindre l'Accès

Un pare-feu est votre première ligne de défense. Par défaut, il doit bloquer tout trafic entrant, à l'exception des services que vous avez explicitement besoin d'exposer. Pour SSH, cela signifie autoriser les connexions uniquement sur le port que vous avez choisi (par exemple, 2222) et, idéalement, uniquement à partir d'adresses IP ou de réseaux de confiance spécifiques.

Exemple utilisant UFW (Uncomplicated Firewall) :

Autoriser SSH à partir d'une adresse IP spécifique 192.168.1.100 sur le port 2222 :

sudo ufw allow from 192.168.1.100 to any port 2222

Autoriser SSH à partir d'un sous-réseau spécifique 192.168.1.0/24 :

sudo ufw allow from 192.168.1.0/24 to any port 2222

Exemple utilisant Firewalld (CentOS/RHEL) :

Autoriser SSH à partir d'une adresse IP spécifique 192.168.1.100 sur le port 2222 :

sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.1.100" port port=2222 protocol="tcp" accept'
sudo firewall-cmd --reload

Avertissement : Si vous gérez un serveur depuis une adresse IP dynamique, soyez prudent avec les règles de pare-feu strictes. Vous pourriez avoir besoin d'autoriser l'accès à partir d'une plage plus large ou d'utiliser un VPN.

Conseils de Durcissement Supplémentaires

Au-delà des 10 essentiels, envisagez ces directives pour une sécurité encore accrue :

  • MaxAuthTries : Limite le nombre de tentatives d'authentification par connexion. La valeur par défaut est 6. La réduire (par exemple à 3) diminue les chances de force brute. Définie dans sshd_config.
    config MaxAuthTries 3
  • LoginGraceTime : Limite le temps autorisé pour qu'un utilisateur s'authentifie. La valeur par défaut est de 2 minutes. La réduire (par exemple à 30s) réduit la fenêtre pour les attaques lentes.
    config LoginGraceTime 30s
  • ClientAliveInterval et ClientAliveCountMax : Empêchent les sessions SSH inactives de rester ouvertes indéfiniment. ClientAliveInterval envoie un paquet nul toutes les X secondes. Si ClientAliveCountMax (par défaut 3) réponses sont manquées, la connexion est terminée.
    config ClientAliveInterval 300 ClientAliveCountMax 0 # Désactive la vérification du client actif si vous souhaitez que les sessions persistent indéfiniment
  • Banner : Affiche un message d'avertissement avant l'authentification. Cela sert d'avis légal aux utilisateurs non autorisés potentiels.
    config Banner /etc/issue.net
    Créez le fichier /etc/issue.net avec le message d'avertissement souhaité.

Conclusion

Le renforcement de votre serveur SSH est un processus continu, pas une configuration unique. En mettant en œuvre ces 10 bonnes pratiques essentielles – du changement des ports par défaut et de la désactivation de la connexion root à l'application de l'authentification par clé et au déploiement de pare-feu – vous établissez une posture de sécurité robuste pour votre accès à distance. N'oubliez jamais de tester soigneusement les changements, de maintenir vos systèmes à jour et de surveiller régulièrement les journaux pour toute activité suspecte. Une vigilance constante est essentielle pour maintenir un environnement d'administration à distance sécurisé et fiable.

Ces pratiques sont fondamentales pour tout administrateur de serveur et réduiront considérablement votre exposition aux menaces cybernétiques courantes, protégeant votre infrastructure serveur contre l'accès non autorisé et les compromissions potentielles.