• 10 heures
  • Difficile

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 01/12/2023

Sécurisez le service réseau SSH

Une fois que le système d'exploitation a été sécurisé, il reste important que vous sécurisiez chacun des services réseau. Dans ce chapitre, vous verrez un exemple de sécurisation de SSH. OpenSSH est un service réseau qui implémente de la sécurité par défaut pour se connecter sur un système à distance, exécuter des commandes ou encore échanger des fichiers. Au delà de ses fonctions de sécurité, il est implémenté en prenant en compte la sécurité, par exemple de la séparation de privilège.

Schéma de Séparation de privilèges dans OpenSSH.
Séparation de privilèges dans OpenSSH

Cela permet de limiter les dégâts en cas de vulnérabilité : seul le démon principal de mise en écoute sur le réseau est privilégié et un processus non privilégié est créé pour gérer les opérations d'échange de clé, d'authentification ou exécuter les commandes sur le système.

Améliorez l'authentification

Pour commencer, il est assez simple d'améliorer l'authentification dans SSH. Nombreux sont les utilisateurs qui se plaignent d'avoir trop de mots de passe à retenir. Une bonne solution pour éviter cela est de les authentifier par clé et non par mot de passe. Pour cela, il faut juste désactiver l'authentification par mot de passe et préciser dans la configuration sur serveur SSH où sont définies les clés publiques des utilisateurs dans le fichier  /etc/ssh/sshd_config  .

PasswordAuthentication no
PermitRootLogin no
PermitEmptyPasswords no
AuthorizedKeysFile /etc/ssh/keys/%u

L'utilisateur pourra récupérer sa clé publique (par défaut  ~/.ssh/id_dsa.pub  ) et la communiquer à l'administrateur pour qu'il la place dans le répertoire  /etc/ssh/keys/  .

Définissez les redirections que vous acceptez

En dehors de l'exécution de commande ou l'échange de fichiers, SSH peut être utilisé pour rediriger des connexions réseau en les encapsulant dans un tunnel SSH, idem pour des connexions graphiques X11. Il est également possible d'utiliser un agent qui va relayer la demande d'authentification. En fonction de votre besoin, vous pouvez ou non les accepter :

X11Forwarding no
PermitTunnel no
GatewayPorts no
AllowTcpForwarding no
AllowAgentForwarding no

Apportez de la flexibilité et de la finesse

Parfois, vous ne pourrez pas purement et simplement désactiver une fonction telle que celles mentionnées précédemment. En effet, même si la plupart des utilisateurs n'en ont ni le besoin ni le droit, il est possible que vous ayez juste quelques utilisateurs faisant exception.

Pour ne pas adopter une configuration laxiste globalement juste à cause de quelques exceptions, vous pouvez utiliser dans la configuration du serveur SSH la directive Match, qui permettra d'affiner les règles pour un utilisateur, un groupe ou une provenance de connexion.

Dans l'exemple ci-dessous, l'utilisateur toto n'aura pas le droit de faire de forwarding TCP, sauf quand il se connecte depuis le poste ayant l'adresse 10.1.2.3.

Match User toto Address 10.1.2.3
 AllowTcpForwarding yes

Match User toto Address *
 AllowTcpForwarding no

Cela vous offre une grande flexibilité et beaucoup de finesse dans les autorisation allouées. 

Emprisonnez le SFTP

Si vous utilisez SSH pour l'échange de fichier avec le protocole SFTP, vous voudrez sûrement que l'utilisateur qui viendra récupérer des fichiers ne puisse pas accéder à l'ensemble de l'arborescence du système. Pour cela, SSH propose un mécanisme de Chroot pour SFTP. En pratique, l'utilisateur sera « dans une cage », il verra le répertoire autorisé comme si ce dernier était la racine du système. Dans l'exemple ci-dessous de configuration de  /etc/Ssh/sshd_config , tous les utilisateurs qui sont dans le groupe  sftponly  n'auront accès qu'à l'échange de fichiers dans  /data/sftp/  et ne pourront ni passer des commandes sur le système, ni relayer des connexions TCP ou X11.

 Subsystem sftp /usr/lib/ssh/sftp-server

Match Group sftponly
  ChrootDirectory /data/sftp/
  ForceCommand internal-sftp
  AllowTcpForwarding no
  X11Forwarding no
  PasswordAuthentication no

En complément de cette configuration, il faudra que le répertoire  /data/ftp  appartienne à root et au groupe  sftponly  (avec les droits d'écriture pour ce groupe si cela est souhaité).

En résumé

  • Chaque service réseau doit être configuré pour adapter le niveau de sécurité, les modalités d'authentification et les fonctions accessibles aux utilisateurs.

  • L'authentification des utilisateurs par clé est plus robuste et permet de s'affranchir des contraintes de gestion des mots de passe.

  • Certaines fonctions avancées comme la mise en cage vous offre une restriction forte des accès des utilisateurs.

Exemple de certificat de réussite
Exemple de certificat de réussite