Comprendre les menaces qui pèsent sur un hôte Linux

Qui attaque un serveur Linux, et pourquoi ?

Un serveur sur le réseau n'est jamais attaqué par hasard : il l'est en permanence, par des outils automatisés et par des humains, dès qu'il dispose d'une adresse routable. Les attaquants se rangent en quelques profils, chacun avec un objectif :

• Botnets opportunistes : scannent tout l'espace IPv4 à la recherche de mots de passe SSH faibles, de services exposés et de CVE connues ; leur but est le vol de ressources (cryptominage, relais de spam, puissance de DDoS).
• Groupes de rançongiciels : prennent pied, escaladent, se propagent, puis chiffrent et extorquent.
• Acteurs ciblés / étatiques : patients, en quête d'exfiltration de données et de persistance durable.
• Initiés malveillants : ont déjà un compte ; ils abusent d'un accès légitime.

Ce qu'ils exploitent tous, c'est la surface d'attaque : chaque port ouvert, service actif, paquet installé, binaire SUID, compte avec un shell, module noyau chargeable, fichier inscriptible par tous. Plus cette surface est grande, plus il y a de portes, et une installation Linux par défaut embarque énormément de surface qu'un serveur n'utilise jamais.

Comment se déroule une compromission : la kill-chain

Une compromission est rarement un événement isolé. C'est une kill-chain, une suite où chaque étape dépend de la réussite de la précédente. L'enseignement décisif : l'attaquant a besoin que chaque maillon tienne ; le durcissement brise la chaîne au plus grand nombre de maillons, pour qu'un pied dans la place reste un pied dans la place. Cette table projette chaque étape sur sa technique MITRE ATT&CK et la famille de contrôles Pavois qui la brise :

Trois scénarios concrets

1. Bruteforce SSH (T1110). Un botnet arrose sshd de mots de passe. La chaîne se brise si le login root est coupé, l'auth par clé seulement, et faillock verrouille le compte :

# attaquant
hydra -l root -P rockyou.txt ssh://victim
# hôte durci : la porte est déjà fermée
sshd -T | grep -E 'permitrootlogin|passwordauthentication'   # no / no

2. SUID writable / mauvaise config sudo (T1548). Un shell sans droits cherche un chemin vers root :

# attaquant
find / -perm -4000 -writable 2>/dev/null ; sudo -l
# hôte durci : aucun SUID parasite, sudo exige un mot de passe et un TTY

3. Faire taire la piste d'audit (T1562.001). Avant d'agir, l'intrus tente de désactiver la journalisation. Des règles d'audit immuables l'en empêchent :

# attaquant
auditctl -e 0                      # desactiver l'audit...
# hôte durci : les règles sont immuables jusqu'au redémarrage
auditctl -s | grep enabled         # enabled 2  => verrouillé

Ce que Pavois ne détecte PAS

Pavois audite la posture de configuration, pas le comportement en direct. Il ne remplace volontairement pas, et ne peut pas remplacer, la détection à l'exécution. Il ne détectera pas :

• un implant en mémoire / fileless ou un processus déjà malveillant,
• un zero-day dans une application qu'il ne modélise pas,
• une intrusion réseau en direct (ce n'est pas un IDS/EDR),
• une dépendance compromise au niveau applicatif,
• un attaquant qui respecte la config durcie mais abuse d'un accès légitime.

Pavois réduit la surface d'attaque et prouve le socle ; couplez-le à l'envoi des logs auditd et à un EDR/IDS pour la détection runtime. Cette honnêteté est le but : une note verte, c'est une configuration durcie, pas un scan d'intrusion attestant l'absence de compromission.

Ce que Pavois audite

Pavois note la configuration effective de l'hôte en fonctionnement, exactement ce que rencontre un attaquant. Là où un scan OVAL/oscap lit /etc/... et se laisse berner par les Include, drop-ins ou surcharges à chaud, Pavois interroge l'état résolu (sshd -T, sysctl -a, systemctl show). Sur les domaines qui se projettent sur la kill-chain, il couvre la réduction de surface (paquets, services, modules), le durcissement du pied dans la place (SSH, qualité des mots de passe, verrouillage), le confinement de l'escalade (sudo, UID 0, permissions, montages), le durcissement runtime et boot (sysctl, ligne de commande noyau, GRUB), la détection et la persistance (auditd, journald), et le périmètre (pare-feu, bannières). Chaque constat est noté de A à E et étiqueté avec les normes qu'il satisfait (ANSSI BP-028, CIS, PCI-DSS, NIST, STIG), pour qu'un socle au vert soit une kill-chain aux maillons brisés.

FAQ

Pavois est-il un antivirus ou un EDR ? Non. Il audite la configuration de durcissement de l'hôte (la surface d'attaque et la posture), pas les processus en cours ni le trafic réseau. Utilisez-le aux côtés d'un EDR/IDS, pas à sa place.

Pourquoi mapper les contrôles sur MITRE ATT&CK ? Parce que cela relie chaque règle de durcissement à la technique d'attaquant concrète qu'elle contrarie, de sorte qu'on raisonne sur quel maillon de la chaîne un contrôle brise, au lieu de traiter le durcissement comme une checklist opaque.

Une note verte signifie-t-elle que je ne suis pas compromis ? Non. Elle signifie que la configuration est durcie. Un intrus déjà résident, un zero-day ou un abus applicatif est hors périmètre ; c'est le rôle de la détection runtime et de l'analyse des logs.