Sécuriser un serveur Linux : AppArmor et durcissement

Sécuriser (durcir) un serveur Linux, c'est réduire ce qu'un attaquant pourrait exploiter : ne garder que les services utiles, appliquer les correctifs, limiter les comptes et leurs droits, verrouiller l'accès à distance, confiner les programmes et tracer les actions sensibles. Ce chapitre rassemble ces mesures en une liste de contrôle pour Debian 13, détaille AppArmor, le contrôle d'accès obligatoire activé par défaut, et montre comment vérifier le résultat avec auditd et Lynis.

La démarche

Le durcissement suit la méthode présentée dans le cours Cybersécurité des infrastructures : inventorier le rôle du serveur, réduire ce qui ne sert pas, mettre à jour, restreindre, activer les protections, vérifier et documenter. Pour Linux, deux référentiels donnent des listes précises : les Recommandations de configuration d'un système GNU/Linux de l'ANSSI, classées par niveau (minimal, intermédiaire, renforcé, élevé), et le CIS Benchmark de Debian. On ne les applique pas aveuglément : chaque mesure se teste, et chaque écart se justifie.

La liste de contrôle d'un serveur Debian 13

L'heure n'est pas un détail : des journaux horodatés de travers sont inutilisables pour reconstituer un incident, et les certificats TLS sont refusés si l'horloge dérive. timedatectl doit afficher System clock synchronized: yes. Chez Sorbier, les serveurs se synchronisent sur les contrôleurs de domaine, qui servent aussi de source de temps (ligne NTP=192.168.10.177 192.168.10.181 sous la section [Time] de /etc/systemd/timesyncd.conf.d/sorbier.conf, puis sudo systemctl restart systemd-timesyncd). Sur une machine où chrony est installé, comme srv-journaux, c'est lui qui fait ce travail à la place de systemd-timesyncd : ligne server 192.168.10.177 iburst (et la même pour .181) dans /etc/chrony/sources.d/sorbier.sources, puis sudo chronyc reload sources.

AppArmor, le contrôle d'accès obligatoire

Les droits rwx et les ACL sont un contrôle d'accès discrétionnaire (DAC) : c'est le propriétaire d'un fichier qui décide qui y accède, et un programme a tous les droits du compte qui le lance. Si nginx est détourné par une faille, il peut lire tout ce que www-data peut lire.

Un contrôle d'accès obligatoire (MAC) ajoute des règles fixées par l'administrateur, que même le propriétaire ou root ne contournent pas : chaque programme confiné n'a accès qu'aux fichiers, aux capacités et au réseau listés dans son profil. Debian et Ubuntu utilisent AppArmor, actif par défaut depuis Debian 10 ; la famille Red Hat utilise SELinux, qui suit le même principe avec des étiquettes sur chaque fichier.

Un profil fonctionne dans l'un de deux modes :

sudo aa-status                 # module chargé ? combien de profils, dans quel mode, quels processus confinés
sudo apt install apparmor-utils apparmor-profiles apparmor-profiles-extra
sudo aa-complain /etc/apparmor.d/usr.sbin.<programme>   # passer un profil en mode complain
sudo aa-enforce  /etc/apparmor.d/usr.sbin.<programme>   # le repasser en enforce
sudo systemctl reload apparmor                           # recharger tous les profils

aa-status commence par apparmor module is loaded., puis donne le nombre de profils chargés, ceux en mode enforce et complain, et la liste des processus effectivement confinés. Un service sans profil tourne non confiné : c'est le cas de nginx sur Debian, qui n'en fournit pas par défaut. Les profils sont dans /etc/apparmor.d/, nommés d'après le chemin du programme (usr.sbin.chronyd pour /usr/sbin/chronyd). Pour ajouter une autorisation à un profil fourni par un paquet, on écrit dans /etc/apparmor.d/local/<nom-du-profil>, que le profil inclut et qu'aucune mise à jour n'écrase.

Lire un refus. Quand AppArmor bloque un accès, le noyau l'écrit dans le journal :

audit: type=1400 audit(1762246812.413:58): apparmor="DENIED" operation="open" class="file" profile="/usr/sbin/chronyd" name="/srv/journaux/chrony.log" pid=811 comm="chronyd" requested_mask="wc" denied_mask="wc" fsuid=110 ouid=0

Il se lit : le programme chronyd, confiné par le profil /usr/sbin/chronyd, a voulu ouvrir en écriture et création (wc) le fichier /srv/journaux/chrony.log, et AppArmor l'a refusé. sudo journalctl -k -g 'apparmor="DENIED"' liste les refus. Face à un service qui échoue avec « Permission denied » alors que les droits du fichier sont bons, pense à ce journal.

Écrire un profil complet dépasse le niveau du BTS ; l'outil aa-genprof en génère un en observant le programme, et aa-logprof propose d'ajouter aux profils les accès refusés. La bonne réponse à un refus n'est jamais de désactiver AppArmor (aa-disable, ou apparmor=0 au démarrage) : c'est d'ajouter au profil l'accès précis dont le service a besoin, ou de ranger le fichier là où le profil l'autorise.

Tracer les actions sensibles avec auditd

auditd enregistre, au niveau du noyau, les accès à des fichiers choisis et certains appels système, avec le compte d'origine même après un sudo. On surveille par exemple les modifications des comptes et des droits :

sudo apt install auditd
sudo nano /etc/audit/rules.d/sorbier.rules

# Modifications des comptes, des groupes et des droits sudo
-w /etc/passwd -p wa -k comptes
-w /etc/shadow -p wa -k comptes
-w /etc/group -p wa -k comptes
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers
# Configuration SSH
-w /etc/ssh/sshd_config.d/ -p wa -k ssh

-w désigne le fichier ou le dossier surveillé, -p wa les opérations (écriture, changement d'attributs), -k une étiquette de recherche. sudo augenrules --load charge les règles, et sudo ausearch -k sudoers -i retrouve les événements, avec le compte d'origine (auid) en clair.

Vérifier avec Lynis

Lynis audite la configuration d'un système Linux et donne un indice de durcissement, avec la liste des avertissements et des suggestions :

sudo apt install lynis
sudo lynis audit system

Le rapport détaillé est enregistré dans /var/log/lynis-report.dat. Lancé avant et après le durcissement, il mesure le progrès ; relancé chaque mois, il repère les dérives (un service ajouté pour un test, une règle oubliée). Pour un serveur exposé, on complète par un scanner de vulnérabilités lancé avec l'accord du responsable, et par la surveillance continue d'un SIEM comme Wazuh, qui contrôle aussi l'intégrité des fichiers sensibles.

Exercices

apparmor="DENIED" operation="open" class="file" profile="/usr/sbin/named" name="/srv/dns/zones/db.sorbier.example" comm="named" requested_mask="r" denied_mask="r" fsuid=107 ouid=107