Durcissement Debian selon l’ANSSI
Voici des applications concrètes sous Debian du durcissement Linux préconisé par l’ANSSI.
R1 : Minimisation des services installés
Posez-vous la question suivante : Quels services sont lancés au démarrage ? (en particulier ceux qui écoutent en réseau).
Typiquement ai-je besoin d’un serveur SMTP, NTP, … et si oui, doivent-ils être en écoute sur le réseau ou uniquement sur 127.0.0.1 ?
Lister les services actifs et désactiver ceux qui ne devraient pas l’être est un bon début.
systemctl list-unit-files | grep enabled
On peut également lister les services et ports ouverts sur le réseau :
ss -lntp
R2 : Minimisation des configurations
Pour les services légitimes, il faut maintenant penser à ne configurer que les fonctionnalités strictements nécessaires, autrement dit durcir la configuration des services.
J’en avais déjà parlé au sujet d’Apache, Nginx et SSH mais tout service doit être durci.
R3 : Moindre privilège
Fini le temps du compte root partagé par toute l’équipe d’admins avec un mot de passe identique sur chaque serveur.
Pour éviter qu’une vulnérabilité prenne des proportions trop grandes, il faut limiter l’espace de chaque objet (utilisateur, processus, fichier).
Un compte root ne devrait dans l’idéal n’avoir aucune utilité sur un serveur, il faut que chaque processus soit associé à un compte utilisateur limité.
En complément Linux propose des systèmes plus fins comme AppArmor ou SELinux.
R4 : Utilisation des fonctionnalités de contrôle d’accès
Fini également le temps où l’on hébergeait plusieurs services sur une même machine. Nous sommes à l’ère des microservices.
On peut isoler les processus dans des containers Docker, chroot, LXC, pour éviter d’accéder au système d’exploitation directement.
R5 : Défense en profondeur
La défense en profondeur est la prise en compte de la sécurité à tous les niveaux de l’infrastructure.
On ne compte pas sur une boite magique qui va résoudre tous les problèmes de sécurité.
La sécurité se prend en compte du niveau applicatif (le classique XSS dans une appli Web) au niveau matériel (failles Spectre et Meltdown) en passant par toutes les couches du système d’exploitation, du réseau, de la cryptographie, …
R6 : Cloisonnement des services réseau
Comme je le disais plus haut, le fait d’isoler les services permet d’éviter qu’un problème se propage.
Cela permet également de mieux debugger en cas de problème.
R7 : Journalisation de l’activité des services
Il faut savoir ce qui se passe sur la machine et avoir des remontées d’alertes en cas de problème.
Pour ça, rien de tel qu’une analyse de logs (à affiner selon les besoins) avec Logwatch.
Dans l’idéal un SIEM est très utile pour avoir une vision globale des problèmes dans votre SI.
Utile aussi, Debsecan vous dit ce qui est vulnérable sur votre système.
R8 : Mises à jour régulières
Aujourd’hui les mises à jour sont quasi quotidiennes sur tous les OS, donc n’attendez pas, mettez en place un système de mise à jour automatique.
J’en avais déjà parlé pour Linux et FreeBSD.
Le mot de la fin
Regardez sur CVE Details si les logiciels que vous utilisez sont souvent sujets à des failles importantes. Si tel est le cas, remettez en cause le choix de votre logiciel.