Auditez la sécurité d'un système d'exploitation

 Le service SSH est sûrement le service le plus critique sur le serveur. En effet, c'est le moyen le plus connu et le plus commun pour obtenir un shell distant sur le système d'exploitation. Cela est possible en se connectant via un terminal sur le service et en chiffrant les communications avec le protocole SSH. Il est donc très important de veiller à ce que ce service soit configuré de manière sécurisée. Dans ce chapitre, je vous propose d'effectuer un audit du niveau de durcissement de SSH.

Auditez les fondamentaux du service SSH

Je vous propose de l'auditer en vidéo ! Vous trouverez aussi les étapes dans le texte ci-dessous. 

Vérifiez dans un premier temps la version du protocole SSH supporté avec la commande suivante :

[root@fichesproduits ssh]# ssh -v localhost
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
...
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
..
ECDSA key fingerprint is SHA256:7H8DIiivqyhmlDIcOFc7jq3C4zna6CdPxrVH+ng5VSI.
ECDSA key fingerprint is MD5:c5:86:1e:cd:ab:69:b9:a0:6a:bf:d2:89:6e:dd:31:9f.
Are you sure you want to continue connecting (yes/no)?

Parmi les lignes affichées, vous devez retrouver Remote protocol version 2.0. La version 2 amène plus de fonctionnalités, et la version 1 du protocole est aujourd'hui obsolète.

S'il y a une chose qu'il faut absolument bannir en ce qui concerne le service SSH, c'est la possibilité de se connecter directement avec le compte root. Ce réglage est indiqué dans le fichier de configuration avec la directive PermitRootLogin :

[root@fichesproduits ~]# grep PermitRootLogin /etc/ssh/sshd_config
#PermitRootLogin yes

Sur CentOS, par défaut, cette directive possède la valeur « yes », ce qui n'est pas le cas sur Debian.

Ici, il faudrait indiquer :

PermitRootLogin no

À noter qu'il est possible de positionner cette valeur sur forced-commands-only, ce qui laisse la possibilité au compte root de lancer une commande via le service en utilisant les clés d'authentification. J'y reviens juste après.

Enfin, dernier point fondamental : le port d'écoute. Par défaut, ssh écoute sur le port 22. Il faut changer ce port afin de compliquer le travail des attaquants !

[root@fichesproduits ~]# grep Port /etc/ssh/sshd_config
#Port 22

Par exemple, on pourrait indiquer ici :

Port 6060

Auditez le durcissement avancé du service SSH

Une fois les directives basiques passées, il est temps de se pencher sur l'aspect un peu plus sécurisé de la configuration du service :

• pour empêcher des sessions connectées sans activité (idle), il faut utiliser les directives suivantes dans le fichier /etc/ssh/sshd_config :

ClientAliveInterval 300 # Timout idle max en seconde
ClientAliveCountMax 0 # Nombre de messages de continuité autorisés sans réponse du client

• pour empêcher toute connexion d'un compte utilisateur sans mot de passe, il faut positionner la directive suivante :

PermitEmptyPasswords no

• pour autoriser une seule liste d'utilisateurs ou de groupes utilisateur à se connecter, il faut positionner les directives suivantes :

AllowGroups groupe1,groupe2,...
AllowUsers user1,user2,...

• pour tracer les tentatives de connexion échouées en détail, il faut positionner la directive suivante :

MaxAuthTries 4 # Après 2 tentatives, les traces seront détaillées dans les fichiers de log

• enfin, dans le meilleur des cas, il est possible d'indiquer au service SSH de procéder à l'authentification des comptes uniquement par échange de clés de cryptographie asymétrique (duo clé privée/publique). Ces clés doivent être générées de préférence avant le déploiement du service. Elles permettent de s'authentifier sans avoir à saisir de mot de passe, ce qui complique toute tentative d'espionnage de ces mots de passe. Les directives concernées sont :

PasswordAuthentication no
PubkeyAuthentication yes

En résumé

L'audit du service SSH vient terminer cette partie autour de l'analyse des accès réseau sur le serveur. Il ne faut pas oublier que le réseau est probablement le moyen le plus simple pour un attaquant de contacter le serveur et de le corrompre. Mais ce n'est pas le seul, et les protections plus « physiques » évoquées dans les parties précédentes sont tout aussi importantes. Il me semble que nous avons fait le tour d'un audit visant à sécuriser le serveur, il est désormais temps de passer au livrable avec la rédaction du rapport d'audit !

Résumé des recommandations de cette cinquième partie :