Manuel de durcissement

Tout le sujet du durcissement, des menaces et des principes de défense au pourquoi/comment durcir chaque composant Linux, et ce que Pavois audite.

Fondations

12 chapitres

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

Qui attaque un serveur, comment la **surface d'attaque** les fait entrer, comment se déroule la **kill-chain**, projetée sur **MITRE ATT&CK**, et pourquoi un socle durci brise la chaîne à chaque maillon.

Pourquoi on durcit →

Une installation neuve livre des **réglages permissifs**. Durcir réduit la **surface d'attaque** et le **rayon d'impact** d'une compromission, et rend le système **auditable** et **reproductible**.

Les principes de défense derrière chaque règle →

Chaque règle Pavois est un **principe** rendu concret : **défense en profondeur**, **moindre privilège**, **réduction de la surface d'attaque**, **valeurs sûres par défaut**, **séparation des rôles**, **traçabilité**.

Configuration effective : la vérité qu'aucun fichier ne contient →

Pavois lit la configuration qu'un service **résout réellement**, pas les fichiers qui tentent de la fixer. Le drop-in est le cas facile ; le vrai sujet, c'est l'état qui n'est dans **aucun fichier** : défauts compilés, précédence résolue, valeurs noyau et unités générées.

Les normes que Pavois cartographie →

CIS, ANSSI-BP-028, NIST 800-53/171, PCI-DSS et STIG décrivent le même durcissement sous des angles différents. Pavois conserve **une règle neutre** et traite chaque norme comme une **vue**, avec une **force** de correspondance déclarée.

Modèle d'identifiant de contrôle SOCLE →

Chaque contrôle Pavois porte un identifiant SOCLE stable, **`SOCLE-<DOMAINE>-<FAMILLE>-<NUMÉRO>`**. Comment le lire, les vrais domaines et familles, et les règles de stabilité qui permettent de le citer.

Preuves & exports →

Ce qu'un scan Pavois produit pour un auditeur : **checks effectifs**, rapports notés, exports machine (**JSON/SARIF/JUnit/CSV**) et **baseline OSCAL**, et les limites à énoncer honnêtement.

Comment la note A-E est calculée →

Une seule lettre **A-E** ne vaut que si l'on peut la **recalculer à la main**. Pavois publie la formule complète : pénalités pondérées par sévérité, plafonds par bande, et un **échec critique force la note E**.

Ce qu'un PASS prouve : le verdict qualifié →

La plupart des scanners répondent par un bit : réussite ou échec. Pavois qualifie chaque PASS sur **deux axes**, quelle preuve il a lue et s'il **survit à un redémarrage**, et le verdict alimente la **note A-E**.

Modèle de confiance du bundle de preuve →

Un bundle est inviolable en soi ; il ne devient une preuve opposable qu'une fois signé sous une politique de confiance que votre organisation accepte. Qui signe, avec quelle identité, comment les clés tournent, et comment vérifier hors ligne.

SOCLE, n'est-ce pas votre propre norme ? (gouvernance & la question de la circularité) →

Pavois se dit profil Linux exécutable de SOCLE, une norme du même auteur. Cela paraît circulaire. La réponse honnête : ce qu'est SOCLE, ce qu'il n'est explicitement **pas**, et pourquoi l'autorité d'un contrôle repose sur des **normes externes**, pas sur la parole de SOCLE.

Ce que Pavois couvre, et ce qu'il ne couvre pas →

Une référence inspire confiance par ce qu'elle admet ne pas savoir faire. La carte honnête : les domaines de durcissement hôte que Pavois audite **en profondeur**, ceux encore **minces**, et ce qui est **hors périmètre** par conception.

Domaines

18 chapitres

Durcir SSH →

SSH est la porte d'entrée d'un serveur. Durcissez le démon pour qu'un pied dans la place ne devienne pas un contrôle total, et vérifiez la config **effective**, pas le fichier.

Durcir PAM →

**PAM** est le poste de garde par lequel passe chaque connexion. Réglez ses modules pour que mots de passe faibles, réutilisation et brute-force n'atteignent jamais un shell, et verrouillez les comptes après des échecs répétés.

Contrôle d'accès obligatoire (SELinux / AppArmor) →

Le contrôle d'accès obligatoire confine chaque service au **moindre privilège** pour qu'un processus compromis ne puisse pas parcourir tout le système. Le seul état qui protège réellement est le mode **enforcing**.

Durcir le pare-feu local →

Le pare-feu local est le dernier verrou devant chaque service en écoute. **Refusez par défaut** en entrée pour que seuls les ports choisis soient joignables, et autorisez SSH *avant* de l'activer.

Durcir sudo →

sudo est le pont contrôlé d'un compte utilisateur vers **root**. Durcissez la politique pour qu'une session volée ne devienne pas un root silencieux, sans authentification ni traçabilité, et journalisez chaque élévation.

Permissions et propriété des fichiers →

Des fichiers sensibles comme `/etc/shadow`, les clés SSH et les tâches cron ne valent que ce que valent leurs **bits de permission**. Resserrez les droits, posez un **UMASK** strict, éliminez les fichiers **modifiables par tous** et passez en revue les **SUID/SGID** pour qu'un compte peu privilégié ne puisse ni lire de secrets ni s'élever.

Durcir les montages et le système de fichiers →

Isolez les répertoires à risque sur leurs propres montages et bridez-les avec `nodev`, `nosuid`, `noexec` pour qu'un coin inscriptible du disque ne devienne pas une rampe de lancement.

Durcir les modules noyau →

Chaque module chargeable est du **code en mode noyau** prêt à s'exécuter. Désactivez les systèmes de fichiers et protocoles réseau inutilisés pour qu'une socket égarée ou une image disque forgée ne les fasse pas surgir.

Durcir le noyau et le réseau avec sysctl →

Les paramètres dynamiques du noyau décident comment l'hôte route les paquets et expose sa propre mémoire. Resserrez-les pour que la pile réseau et le noyau cessent d'aider un attaquant, et rendez le changement persistant au redémarrage.

Journalisation d'audit avec auditd →

Sans **piste d'audit** inviolable, impossible de dire qui a fait quoi. **auditd** enregistre, au niveau du **noyau**, les commandes privilégiées, les changements d'identité et de permissions, les changements d'heure et les chargements de modules, pour la **traçabilité** et l'**investigation**.

Durcir la journalisation avec journald et rsyslog →

Les journaux sont la **boîte noire** d'un serveur. Rendez-les **persistants**, **infalsifiables** et **exportés hors machine** pour qu'un incident puisse être reconstitué après coup.

Durcir les services systemd →

Chaque démon en cours d'exécution est une **surface d'attaque** accessible. Éteignez les unités inutiles et **confinez** celles que vous gardez, puis mesurez l'exposition de chacune.

Hygiène des paquets →

Chaque paquet installé est du code exploitable. Retirez l'**inutile et le dangereux**, gardez le reste **corrigé automatiquement**, et vérifiez que les paquets sont **signés** et réellement présents.

Durcir le chargeur d'amorçage (GRUB) →

GRUB s'exécute avant le système et avant tout contrôle du système. Protégez-le par un **mot de passe**, verrouillez `grub.cfg`, et passez des options de durcissement sur la **ligne de commande du noyau**.

Synchroniser l'heure →

Une horloge exacte est une **tuyauterie invisible** de la sécurité : journaux, certificats et Kerberos cassent dès qu'elle dérive. Gardez **une source NTP de confiance et authentifiée** qui discipline l'horloge système.

Bannières de connexion et MOTD →

Une bannière de connexion est à la fois l'avis légal à afficher avant authentification et l'endroit où un système divulgue discrètement son OS et la version du noyau : corriger les deux.

Contrôler l'accès à cron et at →

Les tâches planifiées sont le moyen préféré d'un attaquant pour **rester**. Verrouillez qui peut utiliser `cron` et `at` avec une **liste d'autorisation en interdiction par défaut** pour qu'un pied dans la place ne se transforme pas en persistance silencieuse.

Durcir le bureau GNOME (dconf) →

Sur les postes de travail, **verrouillez** les réglages GNOME avec dconf pour qu'un utilisateur, ou un malware dans sa session, ne puisse pas affaiblir les défenses du bureau (verrou d'écran, supports amovibles, bannière).

Outillage

5 chapitres

Annuler un durcissement : les points de restauration →

Pavois photographie l'état antérieur avant de converger, et sait le remettre. Mesuré sur un hôte réel : 597 des 620 contrôles reviennent à leur état exact, et les 23 qui n'y reviennent pas sont nommés. Voici comment, et ce qu'il ne sait honnêtement pas défaire.