Sécurisez des systèmes et applications

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.

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.