Durcir son OS : Windows, macOS, Linux

Un RSSI me transmet la baseline de durcissement de son parc : 220 items, validée en comité, signée par la DSI, déployée par GPO. Item 1, désactiver SMBv1. Item 47, désactiver PowerShell v2. Item 89, fixer le délai de mise en veille de l’écran. Tout est juste. Sauf que le directeur général utilise son compte administrateur local au quotidien, que son mot de passe est Angers2024!, et que la machine n’a pas reçu de mise à jour de sécurité depuis cinq mois parce que les redémarrages le dérangeaient en visio. La checklist était parfaite. Le poste, ouvert comme une porte de grange.

Le piège habituel

Le durcissement d’un système d’exploitation, dans la plupart des organisations, c’est devenu un exercice de conformité documentaire. On télécharge un benchmark, on coche des cases, on produit un rapport, on archive. Le rapport dit que le poste est durci. Le poste, lui, n’a rien compris à la menace qui le vise réellement. C’est exactement le même piège que la conformitéAgence française de cybersécurité, autorité nationale de référence.Voir le lexique sans modèle de menace : un théâtre sécuritaire qui consomme du budget et produit de la fausse assurance.

Les CIS Benchmarks, les baselines Microsoft, les guides de configuration ANSSI sont des documents utiles. Ils recensent un ensemble de réglages connus pour être meilleurs que les valeurs par défaut. Ce ne sont pas des modèles de menace, et ils ne prétendent pas l’être. Un CIS Benchmark Windows compte plusieurs centaines de recommandations. Les appliquer toutes sans réfléchir revient à durcir uniformément des points dont l’importance varie d’un facteur cent. Désactiver SMBv1 sur un laptop qui ne fait jamais de partage réseau ne change rien à votre exposition. Travailler en compte administrateur tous les jours change tout. Les deux mesures ont le même poids dans le rapport de conformité. Elles n’ont pas le même poids contre un attaquant.

Le second piège est celui de la checklist géante perçue comme un gage de sérieux. Plus la liste est longue, plus elle paraît rigoureuse, et plus elle est en réalité ingérable. Une baseline de 220 items que personne ne maintient se dégrade en quelques mois : une exception accordée ici, un réglage cassé par une mise à jour là, un poste réinstallé sans le profil. Au bout d’un an, le rapport affiche toujours 220 items « conformes » alors que la moitié des postes ont dérivé. Une poignée de mesures réellement appliquées et vérifiées bat une encyclopédie de réglages théoriques. Le durcissement n’est pas un projet qu’on termine, c’est un état qu’on maintient.

Modèle de menace réel : contre quoi on durcit vraiment

Avant d’aligner des réglages, il faut savoir ce qui frappe réellement les postes. Le modèle de menace dominant n’est pas l’attaque sophistiquée de cinéma. C’est l’opportunisme industrialisé : un malware générique livré par pièce jointe ou téléchargement piégé, qui s’exécute dans le contexte de l’utilisateur courant et tente d’établir une persistance. La quasi-totalité des compromissions de poste que l’on débriefe relèvent de ce schéma, et trois faits le caractérisent.

Le vecteur d’entrée passe presque toujours par l’utilisateur. Pièce jointe ouverte, macro activée, exécutable téléchargé depuis un faux site, lien de phishingAttaque par ingénierie sociale qui pousse la cible à donner ses identifiants ou exécuter du code.Voir le lexique qui sert un installeur vérolé. Le code malveillant démarre avec les droits de la session ouverte. Si cette session est administrateur, le malware l’est aussi instantanément : il installe un ransomwareMalware qui chiffre les données et exige une rançon, souvent doublé d'une exfiltration préalable.Voir le lexique, désactive l’antivirus, pose un rootkitMalware qui s'installe en profondeur dans l'OS pour rester invisible et persistent.Voir le lexique, et le poste est perdu. Si la session est standard, le même fichier piégé est cantonné aux fichiers personnels de l’utilisateur — gênant, réparable, sans escalade vers le système.

L’attaquant moyen exploite des vulnérabilités déjà corrigées. D’après les analyses récurrentes des vecteurs d’attaque réels, l’écrasante majorité des compromissions exploitent des failles pour lesquelles un correctif existait depuis plus d’un mois. L’adversaire ordinaire ne brûle pas un 0-day sur un poste lambda : il scanne les machines en retard de patch et entre par la porte que l’éditeur a déjà documentée et fermée pour ceux qui mettent à jour. Le retard de mise à jour est, statistiquement, le premier facteur de compromission.

La persistance se cache dans des emplacements prévisibles. Un malware qui veut survivre au redémarrage s’inscrit dans des mécanismes connus : clés Run du registre Windows, tâches planifiées, services, LaunchAgents et LaunchDaemons sur macOS, units systemd et cron sur Linux. Et il s’installe dans des répertoires accessibles sans droits élevés : %TEMP%, %APPDATA%, le dossier utilisateur. Durcir efficacement, c’est rendre ces emplacements et ces mécanismes inhospitaliers, pas réciter un benchmark.

La bonne approche : durcir par impact, pas par exhaustivité

La bascule pragmatique consiste à classer les mesures par leur effet réel sur le modèle de menace ci-dessus, puis à appliquer d’abord celles qui bloquent le plus de scénarios pour le moins d’effort. Une dizaine de mesures, transverses ou par OS, font l’essentiel du travail. Le reste est de l’ajustement fin réservé aux profils qui en ont besoin.

Le socle transverse, valable sur les trois OS

Compte standard pour le quotidien, administrateur réservé aux installations. C’est la mesure de durcissement la plus efficace et la moins appliquée. Elle casse net l’escalade automatique du malware : un fichier piégé ouvert en session standard ne peut pas s’installer dans le système, désactiver les protections, ni se rendre persistant à l’échelle de la machine. Sur Windows, créez un compte standard pour travailler et un compte administrateur distinct pour installer. Sur macOS, même logique — un compte standard travaille, les actions système réclament un mot de passe administrateur ponctuel. Sur Linux, c’est déjà le défaut de toute distribution sérieuse ; le piège est de le casser en accordant un sudo permanent et large.

Mises à jour automatiques, sans exception ni report. Puisque le retard de patch est le premier facteur de compromission, l’automatisation est le contrôle au meilleur rapport effort/effet. Windows Update en mode automatique avec fenêtre de redémarrage imposée. macOS avec installation automatique des mises à jour système et applicatives cochée. Linux avec unattended-upgrades sur Debian/Ubuntu ou dnf-automatic sur Fedora/RHEL, testés avec --dry-run avant activation. La règle culturelle qui compte : un redémarrage en attente n’est pas négociable, même pour un dirigeant en visio.

Chiffrement de disque avec secret utilisateur, pas seulement matériel. BitLockerSolution Microsoft de chiffrement de disque intégrée à Windows Pro/Enterprise.Voir le lexique, FileVaultChiffrement de disque intégré à macOS depuis OS X Lion.Voir le lexique ou LUKSStandard de chiffrement de disque sur Linux, généralement via cryptsetup et dm-crypt.Voir le lexique actif ne suffit pas : il faut un PIN ou une passphrase, pas le seul déverrouillage par TPMPuce cryptographique soudée à la carte mère qui stocke les clés et atteste l'intégrité du boot.Voir le lexique. Le détail des modes, des états de veille et de la gestion des clés de récupération fait l’objet d’un article dédié — c’est le complément naturel du durcissement, et l’erreur de déploiement la plus fréquente sur ce point est le BitLocker en mode TPM seul.

Verrouillage d’écran rapide et démarrage vérifié. Verrouillage automatique sous deux minutes d’inactivité, déverrouillage par mot de passe ou biométrie — pas seulement une mise en veille. Secure BootMécanisme UEFI qui vérifie cryptographiquement la chaîne de démarrage.Voir le lexique activé dans l’UEFI pour empêcher le chargement d’un bootloader ou d’un noyau non signé. Ces deux réglages coûtent zéro et ferment des vecteurs d’accès physique courants.

Windows : les réglages additionnels qui comptent

Au-delà du socle transverse, Windows offre quatre leviers à fort effet que la plupart des baselines noient au milieu de centaines d’items mineurs.

Le premier, ce sont les règles ASR (Attack Surface Reduction) de Windows Defender, largement sous-utilisées alors qu’elles sont gratuites et déployables par GPO ou Intune. Trois règles valent immédiatement leur activation : bloquer les processus enfants lancés par les applications Office (un Word qui démarre PowerShell, c’est presque toujours une attaque), bloquer l’exécution de scripts obfusqués, et bloquer le lancement de binaires depuis les dossiers temporaires et de téléchargement. Ces trois règles couvrent à elles seules la chaîne d’infection la plus courante : pièce jointe, macro, script, charge utile dans %TEMP%.

Le deuxième, c’est le blocage des macros Office non signées. Dans le Trust Center de chaque application Office, sélectionnez « Désactiver toutes les macros sauf les macros signées numériquement ». Les documents Word et Excel piégés reçus par mail restent un vecteur actif, et la macro reste l’outil de prédilection des campagnes de masse parce qu’elle s’exécute sans installer quoi que ce soit. Microsoft bloque désormais par défaut les macros des fichiers provenant d’Internet, mais cette protection se contourne et se désactive : ne comptez pas dessus seule.

Le troisième, c’est l’UAC réglé sur « Toujours notifier ». Oui, c’est plus intrusif que le réglage par défaut « Notifier uniquement quand des applications tentent de modifier le système ». Et oui, c’est précisément ce surcroît de notification qui vous donne la chance de remarquer une élévation de privilèges que vous n’avez pas déclenchée.

Le quatrième, réservé aux postes sensibles sous Windows Enterprise ou Education, c’est l’allow-listing applicatif via AppLocker ou Windows Defender Application Control. Le principe : ne laisser tourner que les exécutables, scripts et DLL explicitement autorisés. Le déploiement se fait en deux temps — d’abord en mode audit pendant deux à trois semaines, qui journalise sans bloquer et permet de cartographier les faux positifs et les outils métiers légitimes, puis en mode enforce une fois la liste stabilisée. Sauter l’étape audit, c’est se garantir une vague de tickets et un retour en arrière précipité.

macOS : Gatekeeper, SIP et la boîte à outils Objective-See

macOS arrive avec un socle de protection solide, et l’essentiel du durcissement consiste à ne pas le saboter. Gardez Gatekeeper en mode strict (App Store et développeurs identifiés), le réglage par défaut depuis plusieurs versions : il refuse les applications non signées et non notarisées. Le seul moment où l’on est tenté de le contourner, c’est pour installer un logiciel douteux récupéré sur un forum — c’est exactement le moment de ne pas le faire.

Ne désactivez jamais SIP (System Integrity Protection), quels que soient les tutoriels qui le réclament « temporairement » pour faire fonctionner tel utilitaire. SIP protège les répertoires système contre toute modification, y compris par root. C’est l’un des mécanismes qui empêche un malware ayant obtenu des droits élevés de s’incruster durablement dans le système. Un SIP désactivé et oublié transforme un incident mineur en compromission profonde.

Ajoutez ensuite la suite gratuite d’Objective-See, maintenue par Patrick Wardle, ancien de la NSA, qui produit les meilleurs outils défensifs spécifiques à macOS. LuLu est un pare-feu applicatif qui vous demande si une nouvelle connexion sortante est légitime : il coupe le « téléphone maison » d’un malware qui tenterait de joindre son serveur de commande. BlockBlock surveille en temps réel les mécanismes de persistance courants — LaunchAgents, LaunchDaemons, cron — et alerte quand quelque chose tente de s’y installer. KnockKnock dresse l’inventaire de tout ce qui est configuré pour s’exécuter au démarrage ; lancez-le après chaque installation d’application pour voir ce qui a été ajouté à votre insu.

Enfin, pour les profils réellement exposés à des attaques ciblées — journalistes, dirigeants, activistes —, le Lockdown Mode désactive ou restreint un ensemble de fonctionnalités historiquement exploitées par les logiciels espions de type Pegasus : compilation JIT WebKit, aperçus de liens dans Messages, connexions filaires vers des appareils inconnus quand le Mac est verrouillé, certaines API. Le coût ergonomique est réel — navigation plus lente sur certains sites, fonctionnalités en moins — et ne se justifie que pour qui a un vrai profil de cible. L’activer « au cas où » sur un poste lambda, c’est de la friction sans bénéfice.

Linux : ne pas saboter ce qui protège déjà

La sécurité d’un poste Linux dépend fortement de la distribution, de l’environnement de bureau et de qui administre la machine. Le durcissement consiste d’abord à ne pas désactiver les protections actives par défaut.

Ne désactivez ni AppArmor (Debian/Ubuntu) ni SELinux (RHEL/Fedora). Ces systèmes de contrôle d’accès obligatoire confinent chaque processus à ce dont il a besoin, et constituent une raison majeure de la meilleure résistance de Linux aux exploits locaux par rapport à beaucoup de configurations Windows. Le réflexe « je désactive SELinux parce qu’il bloque mon application » est une erreur : la bonne réponse est d’écrire la politique adaptée, pas de tout ouvrir.

Réduisez la durée de cache de sudo. Par défaut, sudo conserve les droits une quinzaine de minutes après authentification ; sur un poste partagé ou exposé, ramenez cette valeur à quelques minutes, voire à zéro avec Defaults timestamp_timeout=0 dans /etc/sudoers. Et n’accordez sudo qu’aux comptes qui en ont un besoin documenté, sans règle permissive « tout autorisé sans mot de passe » qui annule l’intérêt du compte standard.

Vérifiez enfin que le swap est chiffré. Un swap en clair peut recueillir des fragments de mémoire — clés, secrets, données déchiffrées — et les conserver sur disque. Sur une configuration LVM-on-LUKS, où tout le groupe de volumes est dans un conteneur LUKS, le swap est protégé automatiquement ; sinon, contrôlez avec lsblk -f que la partition de swap apparaît bien comme chiffrée.

Ce qui est performatif et ne change rien

Une part du « durcissement » que l’on voit appliqué ne sert à rien d’autre qu’à remplir un rapport. Savoir reconnaître ces mesures permet de ne pas y consacrer de temps et de ne pas s’en croire protégé.

Renommer le compte administrateur. C’est de la security by obscurity à l’état pur. Un attaquant qui a un pied sur la machine énumère les comptes en deux secondes, identifiant unique compris. Rebaptiser « Administrator » en « JeanDupont » ne retarde personne et complique l’administration légitime.

Désactiver complètement PowerShell « pour la sécurité ». PowerShell est un outil d’administration légitime et puissant. Le supprimer crée des problèmes d’exploitation sans arrêter les attaquants, qui se rabattent sur cmd.exe, WScript, ou un binaire système détourné. La bonne approche n’est pas la désactivation mais le Constrained Language Mode, la journalisation des blocs de script (ScriptBlock Logging) et la signature des scripts internes.

Désactiver le Bluetooth ou le Wi-Fi par principe. Couper une radio dont vous n’avez pas l’usage réduit marginalement la surface, et c’est une habitude raisonnable. Ce n’est pas une mesure de sécurité décisive : un attaquant déterminé avec accès physique ou réseau ne sera pas stoppé par l’absence de Bluetooth. Ranger cette action dans la case « hygiène » plutôt que « protection forte ».

Changer le port SSH ou multiplier les réglages cosmétiques. Déplacer SSH du port 22 vers un autre réduit le bruit des scanners automatisés dans les logs, rien de plus. La protection vient de l’authentification par clé, de la désactivation du login root et du mot de passe, pas du numéro de port. Confondre le silence dans les logs avec une amélioration de sécurité est une erreur classique.

Accumuler des outils de sécurité sans réduire la surface. Empiler antivirus, EDR, pare-feu tiers et utilitaires de « nettoyage » sur un poste où l’utilisateur reste administrateur, c’est traiter le symptôme en laissant la cause. Un malware lancé avec des droits élevés neutralise ces outils avant qu’ils n’alertent. La détection complète la réduction de surface ; elle ne la remplace jamais.

Qubes OS : la compartimentation, et pour qui

Quand le profil de menace est très élevé, le durcissement classique atteint sa limite : tout vit dans le même système, et une compromission du navigateur peut, en chaînant les exploits, atteindre les documents sensibles. Qubes OS répond à ce problème par l’architecture. Construit sur l’hyperviseur Xen, il exécute chaque domaine d’usage dans une machine virtuelle isolée : une VM pour le navigateur, une pour les emails, une pour les documents sensibles, une jetable pour ouvrir une pièce jointe douteuse. La compromission d’une VM ne donne pas accès aux autres.

C’est, sur le papier, la conception la plus solide pour un poste de travail. C’est aussi la plus exigeante : courbe d’apprentissage réelle, compatibilité matérielle limitée (tous les laptops ne conviennent pas), certaines applications difficiles à intégrer, performances en retrait. Qubes se justifie pour les journalistes d’investigation, les chercheurs en sécurité, ou les profils à menace étatique qui ont le temps d’investir dans l’adoption — et qui appliquent déjà rigoureusement le socle des autres OS. L’installer « parce que c’est plus sécurisé » sans comprendre le modèle de compartimentation produit une fausse impression de sécurité et une vraie perte de productivité.

Ce que ça implique concrètement

Erreurs qu’on voit tout le temps

• Travailler en compte administrateur au quotidien. L’erreur la plus simple à corriger et la plus répandue : on la retrouve sur la majorité des postes audités. Un seul fichier piégé ouvert en session admin, et le malware hérite de tous vos droits sans rien demander.
• Appliquer un CIS Benchmark sans modèle de menace. Désactiver SMBv1 sur un poste qui ne partage rien rassure le rapport et ne change rien à l’exposition. Comprendre pourquoi chaque item existe vaut mieux que tout cocher.
• Reporter les mises à jour « quand j’aurai le temps ». En pratique, jamais dans les 30 jours. Le retard de patch est le premier facteur de compromission, loin devant l’absence de réglage exotique.
• Confondre la longueur de la checklist avec le niveau de sécurité. Une baseline de 220 items jamais maintenue dérive en quelques mois. Dix mesures appliquées et vérifiées battent une encyclopédie théorique.
• Désactiver les protections « parce qu’elles dérangent ». SIP coupé sur macOS, UAC baissé sur Windows, SELinux désactivé sur Linux, alertes Gatekeeper/SmartScreen ignorées par réflexe : chaque désactivation rouvre exactement le vecteur que le contrôle bloquait.
• Croire que l’EDR remplace le durcissement. Un malware lancé en administrateur neutralise l’EDR avant qu’il n’alerte. La détection ne remplace pas la réduction de surface ; elle la complète.
• Faire de la security by obscurity. Renommer le compte « Administrator », changer le port SSH : un attaquant qui a un pied sur la machine lit la configuration en deux secondes. Ça n’arrête personne.

Checklist actionnable

• N1 Travailler en compte utilisateur standard, compte administrateur séparé réservé aux installations
• N1 Activer les mises à jour automatiques OS et applications, redémarrages non négociables
• N1 Chiffrer le disque avec PIN/passphrase (FileVault, BitLocker+PIN, LUKS), clé de récupération hors appareil
• N1 Verrouillage d'écran automatique sous 2 minutes et Secure Boot activé dans l'UEFI
• N2 Activer le pare-feu OS et, sur macOS, installer LuLu pour contrôler les connexions sortantes
• N2 Bloquer les macros Office non signées et activer les règles ASR de Windows Defender
• N2 Adopter CIS Benchmark Level 1 comme baseline, Level 2 pour les postes des fonctions sensibles
• N2 Mesurer automatiquement la conformité du parc au niveau cible et suivre la dérive mensuellement
• N2 Réduire les comptes à droits administrateur local et auditer sudo/AppArmor/SELinux sur Linux
• N3 Déployer AppLocker ou WDAC en allow-list (audit puis enforce) sur les postes Windows sensibles
• N3 Activer Lockdown Mode et installer BlockBlock + KnockKnock pour les profils à risque ciblé (macOS)
• N3 Évaluer Qubes OS pour les profils très exposés disposant des compétences techniques

Pour aller plus loin

Les références du frontmatter cadrent le durcissement sans le réduire à de la conformité : les CIS Benchmarks et les security baselines Microsoft donnent les référentiels Level 1/Level 2, les recommandations de l’ANSSI complètent côté configuration de postes, et la suite Objective-See outille concrètement macOS. La documentation Qubes OS éclaire le choix d’une architecture par compartimentation pour les profils très exposés.

Le durcissement de l’OS n’a de sens qu’articulé avec le reste de la chaîne du poste. Le complément immédiat est Le chiffrement de disque, vraiment ?, qui détaille les états de protection et la gestion des clés de récupération. Pour l’authentification résistante au phishing qui protège les comptes derrière l’OS, voir YubiKey et FIDO2. Et pour transposer ces mesures à un poste qui sort du périmètre maîtrisé, lisez Le laptop de voyage.