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