Checklist de durcissement après réinstallation — quoi verrouiller en premier

L’ordre compte : principes de durcissement qui ne mentent pas

Le durcissement après une réinstallation n’est pas une activité basée sur l’ambiance. C’est un problème de séquence. Vous essayez de réduire le risque rapidement tout en gardant le système suffisamment opérationnel pour finir le travail.

Principe 1 : Fermez les portes distantes avant de décorer l’intérieur

Commencez par tout ce qui est accessible depuis l’extérieur : SSH, gestion à distance, panneaux d’administration web exposés, identifiants par défaut, ports ouverts. Si un attaquant peut obtenir un shell interactif, vos permissions de fichiers soignées ne sont qu’un ralentissement.

Principe 2 : Identité et accès sont votre premier état permanent

Utilisateurs, groupes, règles sudo, comptes de service et clés API déterminent l’utilisation du système pour l’année à venir. Votre réinstallation a effacé l’historique désordonné. Ne le réintroduisez pas par commodité.

Principe 3 : L’observabilité fait partie de la sécurité

Si vous ne pouvez pas répondre à « qu’est‑ce qui a changé ? » et « qui l’a fait ? », vous n’avez pas un système durci. Vous avez un système que vous espérez durci. Logs centralisés, pistes d’audit et synchronisation temporelle ne sont pas du décor ; ce sont des outils de réponse aux incidents.

Principe 4 : Le stockage transforme les accidents en catastrophes

La plupart des incidents de production ne sont pas des hacks hollywoodiens ; ce sont des erreurs de permissions, des journaux qui s’emballent, un système de fichiers racine plein, ou un montage « temporaire » oublié. Durcir le stockage signifie rendre les chemins d’écriture ennuyeux et prévisibles.

Principe 5 : Les baselines valent mieux que les exploitations héroïques

Après réinstallation, vous pouvez construire une baseline connue‑bonne. Cette baseline est votre future différence. Si vous ne la définissez pas maintenant, vous passerez des mois à vous disputer sur « ça fonctionnait avant ».

Une citation à garder en tête quand vous êtes tenté de bricoler : « L’espoir n’est pas une stratégie. » — attribuée à John M. Sullivan (citée couramment en opérations et planification).

Blague #1 : Un serveur fraîchement réinstallé, c’est comme un nouveau‑né — mignon, bruyant, et absolument pas prêt à être laissé seul sur Internet.

Playbook de diagnostic rapide (vérifications première/seconde/troisième)

Voici le playbook « il se passe quelque chose de bizarre après la réinstallation ». Utilisez‑le pour trouver le goulot d’étranglement rapidement et éviter d’explorer le mauvais niveau.

Première vérification : le système est‑il sain au niveau OS ?

• Pression CPU ? Vérifiez la charge, la file d’attente d’exécution et si le problème vient du CPU ou de l’iowait.
• Pression mémoire ? Contrôlez la mémoire disponible et l’activité du swap.
• Disque plein ? Racine et /var qui se remplissent sont des échecs classiques après réinstallation.
• Heure correcte ? Si les horloges dérapent, TLS échoue, les logs mentent et l’authentification devient « mystérieuse ».

Seconde vérification : le chemin réseau est‑il sain ?

• Route par défaut et DNS ? Une réinstallation réinitialise souvent les résolveurs, les routes et les noms d’interface.
• Règles de pare‑feu ? Vos services peuvent tourner mais être inaccessibles.
• Durcissement SSH trop poussé ? « Verrouillé » n’est pas la même chose que « verrouillé à l’extérieur ».

Troisième vérification : la pile de stockage fait‑elle ce que vous pensez ?

• Mounts et fstab ? Des montages manquants font écrire les applications dans la racine.
• État RAID/ZFS ? Des ensembles dégradés performent mal et tombent plus facilement.
• Permissions ? Une réinstallation peut modifier silencieusement les mappings UID/GID.

Quand vous bloquez, posez une question par couche : « est‑ce le calcul, le réseau ou le stockage ? » La plupart des heures perdues viennent de gens qui devinent la mauvaise couche et persistent.

Faits intéressants et contexte historique (pour les sceptiques)

1. Les premiers Unix supposaient des réseaux de confiance. Beaucoup de réglages par défaut privilégiaient historiquement la commodité sur des réseaux internes, pas l’exposition à Internet hostile.
2. SSH a remplacé telnet pour une raison. Dans les années 1990, les connexions distantes en clair étaient normales ; SSH a rendu l’administration distante chiffrée et courante.
3. Les services par défaut ouverts ont une longue traîne. « Ça n’écoute que sur le LAN » a été une phrase récurrente avant incident depuis les premiers réseaux plats.
4. La synchronisation temporelle est devenue une fonctionnalité de disponibilité. TLS, Kerberos et de nombreux systèmes distribués se cassent de façon étrange quand les horloges dévient.
5. La rétention des logs était autrefois un problème de disque. Les petits disques imposaient des rotations agressives ; maintenant le mode défaillant est « garder tout jusqu’à ce que /var soit plein ».
6. Le principe du moindre privilège n’a pas toujours été culturellement accepté. Pendant des décennies, les équipes ops résolvaient la rapidité avec root partagé, puis ont passé des années à désapprendre cela.
7. Les pare‑feu sont passés du périmètre à l’hôte. L’essor du cloud et du zero‑trust a rendu le filtrage au niveau hôte et la segmentation normaux plutôt que paranoïaques.
8. L’infrastructure immuable a popularisé la réinstallation comme correctif. Reconstruire plutôt que réparer améliore la cohérence — mais seulement si votre baseline de durcissement est réelle.

Checklists / plan étape par étape (verrouillez d’abord)

Voici l’ordre que j’utiliserais sur un serveur Linux de production après réinstallation. Adaptez selon la distribution et l’environnement, mais ne freestylez pas la séquence.

Phase 0 : Ne briquez pas la machine

• Obtenez un accès hors bande (IPMI/iDRAC/console) ou le console série cloud avant de modifier SSH ou le pare‑feu.
• Consignez les IPs actuelles, routes, DNS et chemin d’accès SSH.
• Définissez une fenêtre de rollback : si vous vous enfermez, vous devez avoir un plan de récupération connu.

Phase 1 : Empêchez les compromissions distantes faciles

• Patcherez les paquets de base de l’OS.
• Durcissez SSH : clés, pas de login root, pas de mots de passe (quand c’est sûr), chiffrement/MACs minimal si vous avez une politique.
• Activez et validez un pare‑feu hôte : refuser par défaut en entrée, n’autoriser que l’essentiel.
• Supprimez/désactivez les services distants inutilisés (anciens consoles web, endpoints RPC, ports de dev).

Phase 2 : Rendez l’identité ennuyeuse

• Créez des comptes admins nommés ; évitez le root partagé.
• Verrouillez sudoers : groupes explicites, pas de NOPASSWD sauf raison défendable.
• Définissez une politique de mots de passe sensée quand applicable (ou des politiques d’auth centralisées).
• Inventoriez les authorized_keys SSH et tuez les clés zombies.

Phase 3 : Stockage et sécurité des données (là où habite la douleur)

• Confirmez les montages et options de système de fichiers (nodev/nosuid/noexec si approprié).
• Vérifiez la santé RAID/ZFS ; planifiez scrubs et contrôles SMART.
• Définissez permissions et propriété sur les chemins de données ; vérifiez l’alignement UID/GID pour les comptes de service.
• Configurez la rotation des logs et des garde‑fous d’usage disque.
• Sauvegardes : configurez, lancez et testez une restauration. Si vous ne testez pas, ce n’est pas une sauvegarde ; c’est un vœu.

Phase 4 : Observabilité et réponse

• Synchronisation temporelle (chrony/systemd-timesyncd) et fuseau horaire cohérent.
• Centralisez les logs ou au moins expédiez les logs critiques hors hôte.
• Activez l’audit pour les actions privilégiées si votre environnement l’exige.
• Monitoring baseline : CPU, mémoire, disque, vérifications de services et routage des alertes.

Phase 5 : Durcissement des services (défense en profondeur)

• Options de sandboxing systemd quand c’est sûr.
• Désactivez les modules noyau inutiles et renforcez sysctl pour l’exposition réseau.
• Approche de gestion des secrets (permissions fichiers, variables d’environnement, intégration Vault, rotation).

Tâches pratiques (commandes, sorties, décisions)

Ci‑dessous des tâches pratiques à lancer juste après la réinstallation. Chaque item inclut : une commande, à quoi ressemble une sortie « normale », ce que cela signifie, et la décision suivante.

Task 1: Confirm what’s actually listening (and on which interfaces)

cr0x@server:~$ sudo ss -lntup
Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
tcp   LISTEN 0      4096   0.0.0.0:22         0.0.0.0:*     users:(("sshd",pid=812,fd=3))
tcp   LISTEN 0      4096   127.0.0.1:5432     0.0.0.0:*     users:(("postgres",pid=1021,fd=7))
tcp   LISTEN 0      4096   0.0.0.0:9100       0.0.0.0:*     users:(("node_exporter",pid=1102,fd=3))

Ce que ça signifie : SSH et node_exporter sont exposés sur toutes les interfaces ; Postgres écoute en loopback seulement (bon réglage par défaut).

Décision : Si 9100 ne doit pas être public, mettez‑le derrière le pare‑feu vers votre réseau de monitoring ou liez‑le à une interface privée. Si quelque chose d’inattendu écoute sur 0.0.0.0, traitez‑le comme un bug tant que ce n’est pas prouvé.

Task 2: Verify the firewall is enabled and the policy is not “shrug”

cr0x@server:~$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To                         Action      From
22/tcp                     ALLOW IN    203.0.113.10
9100/tcp                   ALLOW IN    10.10.0.0/16

Ce que ça signifie : Le refus par défaut en entrée est en place. SSH est restreint à une IP admin connue ; les métriques sont autorisées depuis une plage interne.

Décision : Si vous voyez « Default: allow (incoming) », corrigez‑le immédiatement. Si SSH est « Anywhere », réduisez‑le sauf si vous avez vraiment besoin d’un accès global admin (vous n’en avez pas besoin).

Task 3: Confirm SSH server settings won’t embarrass you later

cr0x@server:~$ sudo sshd -T | egrep '^(permitrootlogin|passwordauthentication|pubkeyauthentication|challengeresponseauthentication|x11forwarding|allowusers|allowgroups)'
permitrootlogin no
passwordauthentication no
pubkeyauthentication yes
challengeresponseauthentication no
x11forwarding no

Ce que ça signifie : Le login root et l’authentification par mot de passe sont désactivés ; l’authentification par clé est activée ; le forwarding X11 est désactivé.

Décision : Si ce serveur est un endpoint de sauvetage ou nécessite un accès « break‑glass », décidez‑le explicitement (IP source restreinte + clé séparée + alerting). Sinon, maintenez les mots de passe désactivés.

Task 4: Validate you didn’t lock yourself out (from another terminal)

cr0x@server:~$ ssh -o PreferredAuthentications=publickey -o PasswordAuthentication=no admin@server.example
Linux server 6.5.0-21-generic #21-Ubuntu SMP ...
admin@server:~$ echo OK
OK

Ce que ça signifie : La connexion par clé fonctionne comme prévu ; pas de repli mot de passe.

Décision : Ce n’est qu’après la réussite de cette vérification que vous devez fermer votre session console hors bande. Si ça échoue, ne « corrigez » pas en direct aveuglément — examinez sshd_config et authorized_keys.

Task 5: Inventory privileged access (sudo) and remove surprises

cr0x@server:~$ sudo getent group sudo
sudo:x:27:admin,deploy

Ce que ça signifie : Le groupe sudo contient les comptes admin et deploy.

Décision : Décidez si deploy a vraiment besoin d’un sudo complet. Souvent il n’a besoin que de commandes spécifiques, pas du mode dieu.

Task 6: Check for passwordless sudo (it spreads)

cr0x@server:~$ sudo grep -R --line-number -E 'NOPASSWD|ALL=\(ALL\) ALL' /etc/sudoers /etc/sudoers.d 2>/dev/null
/etc/sudoers:27:%sudo   ALL=(ALL:ALL) ALL
/etc/sudoers.d/deploy:1:deploy ALL=(root) NOPASSWD:/usr/bin/systemctl restart myapp.service

Ce que ça signifie : L’utilisateur deploy peut redémarrer un service sans mot de passe. C’est restreint et défendable.

Décision : Conservez‑le s’il est requis pour l’automatisation et bien limité. Si vous trouvez NOPASSWD:ALL, supprimez‑le et attendez‑vous à découvrir une « automatisation » qui était en fait « quelqu’un était pressé ».

Task 7: Confirm automatic security updates (or your patch pipeline)

cr0x@server:~$ systemctl status unattended-upgrades --no-pager
● unattended-upgrades.service - Unattended Upgrades Shutdown
     Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled)
     Active: active (running) since Tue 2026-02-03 11:14:26 UTC; 1 day ago

Ce que ça signifie : Les mises à jour automatiques sont activées et en cours.

Décision : Dans des environnements très contrôlés, vous pouvez désactiver ceci et patcher via votre pipeline. Dans tous les cas, choisissez une approche et respectez‑la. « On patch parfois manuellement » est la manière de se faire posséder par une vulnérabilité avec un joli logo.

Task 8: Confirm kernel and OS version match your baseline

cr0x@server:~$ uname -a
Linux server 6.5.0-21-generic #21-Ubuntu SMP PREEMPT_DYNAMIC x86_64 GNU/Linux

Ce que ça signifie : C’est le noyau en cours d’exécution. Il doit correspondre à ce que vos pilotes, votre politique de sécurité et vos outils attendent.

Décision : Si vous avez besoin d’une ligne de noyau spécifique (ex. pour les drivers HBA de stockage), corrigez‑le maintenant — pas après avoir chargé des données et regretté.

Task 9: Check time sync (security and sanity)

cr0x@server:~$ timedatectl
               Local time: Wed 2026-02-04 09:22:11 UTC
           Universal time: Wed 2026-02-04 09:22:11 UTC
                 RTC time: Wed 2026-02-04 09:22:10
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Ce que ça signifie : L’horloge est synchronisée ; le service NTP est actif ; UTC est utilisé (admirablement ennuyeux).

Décision : Si System clock synchronized: no, corrigez‑le avant de déboguer TLS, des memberships de cluster ou des échecs d’authentification « aléatoires ».

Task 10: Check disks, filesystems, and what’s mounted where

cr0x@server:~$ lsblk -f
NAME   FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1 vfat   FAT32       2F1A-9C2B                              512M     2% /boot/efi
├─sda2 ext4   1.0         6f8d1c6a-1f6a-4b6c-9f0a-1f7c6e2a1b4a   18G     21% /
└─sda3 ext4   1.0         41b2b9b0-9a1f-4b57-9b0d-0d8d1d7b6e2e  820G     9% /srv

Ce que ça signifie : Racine et /srv sont séparés. C’est bon : les données applicatives ne prendront pas instantanément la totalité du système.

Décision : Si /var n’est pas séparé et que vous attendez beaucoup de logs, envisagez de le séparer ou au moins d’appliquer une rotation agressive et un monitoring.

Task 11: Verify fstab won’t surprise-reboot you

cr0x@server:~$ sudo cat /etc/fstab
UUID=6f8d1c6a-1f6a-4b6c-9f0a-1f7c6e2a1b4a /     ext4 defaults,errors=remount-ro 0 1
UUID=41b2b9b0-9a1f-4b57-9b0d-0d8d1d7b6e2e /srv  ext4 defaults,noatime         0 2

Ce que ça signifie : Les montages utilisent des UUID (stables). errors=remount-ro protège la racine contre la corruption silencieuse en la passant en lecture seule en cas d’erreur.

Décision : Si vous avez des montages « temporaires », décidez s’ils doivent être nofail. Pour des données critiques, n’utilisez pas nofail ; échouez rapidement plutôt que de booter dans un état à moitié fonctionnel.

Task 12: Check filesystem usage and find the first “why is this full?”

cr0x@server:~$ df -hT
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda2      ext4   20G  4.2G   15G  23% /
/dev/sda3      ext4  900G   80G  774G  10% /srv
tmpfs          tmpfs 3.1G     0  3.1G   0% /run/user/1000

Ce que ça signifie : Beaucoup d’espace libre pour l’instant. L’idée est d’établir la baseline avant que le système ne commence à pourrir.

Décision : Mettez des alertes à 70/80/90 % selon le taux de croissance. Si / est petit, soyez plus agressif.

Task 13: Confirm log rotation is enabled and not fantasy

cr0x@server:~$ sudo logrotate -d /etc/logrotate.conf | tail -n 8
reading config file /etc/logrotate.conf
including /etc/logrotate.d
reading config file apt
reading config file rsyslog
Handling 2 logs
rotating pattern: /var/log/syslog  weekly (4 rotations)
renaming /var/log/syslog to /var/log/syslog.1

Ce que ça signifie : Logrotate peut parser la config et prévoit de faire la rotation de syslog chaque semaine avec 4 rotations.

Décision : Si vous vous fiez uniquement à journald, réglez SystemMaxUse et SystemMaxFileSize dans /etc/systemd/journald.conf. Sinon /var finira par déclarer la grève.

Task 14: Check journald persistence and size limits

cr0x@server:~$ sudo journalctl --disk-usage
Archived and active journals take up 384.0M in the file system.

Ce que ça signifie : Les journaux occupent de l’espace disque. C’est acceptable — jusqu’à ce que ça ne le soit plus.

Décision : Si cela monte de façon imprévisible, limitez‑le et expédiez les logs hors hôte. Si vous gardez tout volatile, acceptez qu’un reboot efface votre scène de crime.

Task 15: Find services that start automatically (and shouldn’t)

cr0x@server:~$ systemctl list-unit-files --type=service --state=enabled
UNIT FILE                         STATE   PRESET
cron.service                      enabled enabled
ssh.service                       enabled enabled
unattended-upgrades.service       enabled enabled
postgresql.service                enabled enabled
apache2.service                   enabled enabled

Ce que ça signifie : Apache est activé. Peut‑être intentionnel. Peut‑être laissé par des paquets de test rapides.

Décision : Si un service ne fait pas partie du rôle du système, désactivez‑le et supprimez‑le. Chaque démon activé est un abonnement potentiel à une CVE.

Task 16: Verify TLS private keys and secrets aren’t world-readable

cr0x@server:~$ sudo find /etc/ssl -type f -name '*.key' -printf '%m %u %g %p\n'
640 root ssl-cert /etc/ssl/private/server.key

Ce que ça signifie : Mode 640, propriété root, groupe ssl-cert. Typique sur Debian/Ubuntu.

Décision : Assurez‑vous que seul le groupe du service peut lire la clé. Si vous voyez 644 ou une propriété aléatoire, corrigez immédiatement et auditez qui y a accédé.

Task 17: Verify storage health (SMART) before trusting the machine

cr0x@server:~$ sudo smartctl -H /dev/sda
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.5.0-21-generic] (local build)
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Ce que ça signifie : Le disque déclare une santé OK (pas une garantie, mais une baseline).

Décision : Si ça échoue ou que les secteurs réalloués augmentent, remplacez le disque avant de commencer à croire que la réinstallation a tout résolu.

Task 18: If you use ZFS, confirm pool status and schedule scrubs

cr0x@server:~$ sudo zpool status
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 00:12:44 with 0 errors on Sun Feb  1 03:10:02 2026
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          sdb       ONLINE       0     0     0
          sdc       ONLINE       0     0     0

errors: No known data errors

Ce que ça signifie : Le pool est en ligne, le dernier scrub n’a trouvé aucune erreur.

Décision : Si l’état est DEGRADED, traitez‑le comme urgent. Confirmez aussi que des scrubs sont planifiés (cron/systemd timer) pour que la bit rot ne devienne pas un hobby surprise.

Task 19: Confirm permissions on critical data paths (and UID/GID consistency)

cr0x@server:~$ sudo stat -c '%U %G %a %n' /srv /srv/myapp /srv/myapp/data
root root 755 /srv
myapp myapp 750 /srv/myapp
myapp myapp 700 /srv/myapp/data

Ce que ça signifie : Les données sont restreintes. Le compte de service possède ses données. Bien.

Décision : Si vous voyez des répertoires de données appartenant à root pour des services applicatifs, vous allez probablement « régler » ça plus tard avec chmod -R et causer des dommages collatéraux. Définissez la propriété correctement maintenant.

Task 20: Verify backups exist and are restorable (the only test that counts)

cr0x@server:~$ sudo restic -r /backups/restic repo snapshots
repository 2f1a... opened (version 2, compression level auto)
ID        Time                 Host        Tags        Paths
c31e9f5a  2026-02-04 02:00:12  server                  /etc /srv/myapp

Ce que ça signifie : Un snapshot existe. Ce n’est pas encore une confiance.

Décision : Effectuez un test de restauration ciblé dans un répertoire temporaire et vérifiez les checksums/le démarrage du service. Les sauvegardes sans restauration sont de l’art performant.

Blague #2 : Si vous n’avez jamais testé une restauration, votre stratégie de sauvegarde est essentiellement « prières et pensées avec du disque en plus ».

Trois mini‑histoires d’entreprise (comment ça échoue en vrai)

1) Incident causé par une mauvaise hypothèse : « c’est seulement accessible en interne »

Une entreprise de taille moyenne a reconstruit un serveur de métriques après une panne de disque. L’ingénieur a fait ce que beaucoup d’entre nous font quand ils sont fatigués : installé l’exporter, confirmé que les tableaux de bord étaient au vert, et passé à autre chose. L’hypothèse était que le serveur se trouvait « sur le réseau privé ».

En réalité, un peu. L’image cloud avait une IP publique assignée par défaut, et les groupes de sécurité avaient été copiés depuis un template utilisé pour un autre rôle. L’exporter écoutait sur 0.0.0.0:9100. Pas d’auth. Pas de règle de pare‑feu sur l’hôte. Le tableau de bord fonctionnait, donc tout était « bien ».

En quelques jours, le serveur a montré des pics étranges et du trafic sortant. Rien de dramatique, juste assez pour déclencher une alerte de facturation. L’investigation a trouvé des scanners opportunistes récupérant des métadonnées et testant des endpoints faibles connus. L’exporter n’était pas un trésor, mais une fuite d’inventaire : versions de noyau, systèmes de fichiers montés, interfaces réseau, et parfois des détails d’environnement via des collecteurs textfile.

La cause racine n’était pas l’exporter. C’était l’hypothèse que le placement réseau équivaut à la sécurité. La correction a été simple : refuser par défaut en entrée au pare‑feu hôte, binder les services internes sur des interfaces internes, et gérer explicitement les règles cloud par rôle — pas de templates « assez proches ».

La leçon est restée : « interne » n’est pas une propriété de vos sentiments. C’est une propriété des tables de routage, des règles de pare‑feu et de ce qui écoute réellement.

2) Optimisation qui s’est retournée : désactiver les mises à jour pour « éviter les reboots »

Une équipe fintech avait une culture de haute disponibilité et la peur des mises à jour noyau surprises. Après réinstallation, ils ont désactivé les unattended upgrades et se sont dit qu’ils patcheraient pendant une fenêtre mensuelle. Puis le mensuel est devenu trimestriel, parce qu’il y avait toujours une campagne et une raison.

Ils ont optimisé pour moins de reboots et ont obtenu exactement cela. Ils ont aussi obtenu un userspace de plus en plus obsolète, y compris une build OpenSSL vulnérable. Personne n’a remarqué parce que tout fonctionnait, et le monitoring se focalisait sur la latence, pas sur les CVE.

Finalement, un scan de sécurité routinier a mis le feu aux poudres. La réaction : patchs d’urgence, reboots d’urgence, approbations de changement d’urgence. L’« optimisation » a produit ce qu’elle essayait d’éviter, sauf que c’est arrivé à 2h du matin avec la direction sur la conférence.

La correction n’a pas été « rallumez les updates et priez ». Ils ont mis en place un pipeline de patch : staging d’abord, production ensuite, cadence prévisible et plan de rollback. La culture a changé : les reboots programmés sont devenus la norme, et les reboots surprises un symptôme d’incident plutôt qu’un risque accepté.

Si vous désactivez les mises à jour automatiques, vous vous engagez à être meilleur que l’automatisation. La plupart des organisations ne le sont pas.

3) Pratique ennuyeuse mais correcte qui a sauvé la mise : montages séparés et propriété stricte

Une entreprise de logistique avait une flotte de serveurs applicatifs qui étaient souvent reconstruits — swaps matériels, upgrades d’OS, vous connaissez la suite. Leur baseline incluait des systèmes de fichiers séparés : / petit et stable, /srv pour les données applicatives, et /var dimensionné pour les logs. C’est le genre de configuration dont personne ne se vante en conférence.

Un weekend, une nouvelle release est sortie avec le mode debug laissé activé par erreur. Le volume de logs a explosé. Sur une configuration mono‑partition, c’est la chaîne classique : / se remplit, les services tombent, SSH devient instable, et la récupération devient une course parce que vous ne pouvez même pas écrire un fichier temporaire.

Ici, /var s’est rempli, les alertes ont sonné, l’application a été dégradée, et l’OS est resté sain. SSH est resté stable. Ils ont fait la rotation des logs, remis le niveau de log, et le système a récupéré sans corruption du système de fichiers ni reconstruction d’urgence.

Le postmortem a été court. Pas parce que rien ne s’est passé — parce que le rayon d’explosion était limité par des décisions ennuyeuses prises lors de la réinstallation des mois plus tôt. Montages séparés, rotation sensée et bonnes propriétés ne sont pas glamour. Ce sont les choses qui vous permettent de survivre à votre propre logiciel.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom: “SSH worked yesterday, now I’m locked out”

Cause racine : Pare‑feu resserré sans validation depuis l’IP admin réelle ; ou PasswordAuthentication désactivé avant déploiement des clés ; ou AllowUsers mal configuré.

Correction : Utilisez l’accès console pour revenir en arrière. Validez sshd -T et tentez une connexion key‑only depuis une seconde session avant de fermer la console. Restreignez SSH par IP source seulement après avoir confirmé des chemins d’accès stables.

2) Symptom: “Service is running but unreachable”

Cause racine : Processus lié à 127.0.0.1 ou mauvaise interface après réinstallation ; ou pare‑feu hôte en mode deny par défaut sans allow explicite ; ou incohérence des règles cloud.

Correction : Vérifiez ss -lntup pour confirmer les adresses de bind. Confirmez les règles de pare‑feu sur l’hôte et dans le cloud. Ne supposez pas que « en cours d’exécution » signifie « joignable ».

3) Symptom: “Disk space keeps vanishing”

Cause racine : journald ou logs applicatifs non bornés ; core dumps volumineux ; fichiers tmp qui s’accumulent ; fichiers supprimés mais encore ouverts.

Correction : Limitez l’usage de journald, configurez logrotate, et utilisez lsof +L1 pour trouver les fichiers supprimés encore ouverts. Placez les chemins à écriture intensive sur des montages séparés et alertez tôt.

4) Symptom: “Permissions are correct but app can’t read/write”

Cause racine : Mismatch UID/GID après réinstallation ; volumes de conteneur montés avec propriété root ; ACLs manquantes ; SELinux/AppArmor qui refuse.

Correction : Vérifiez id myapp et la propriété sur le disque. Si vous utilisez SELinux/AppArmor, vérifiez les refus et étiquetez correctement plutôt que de chmod aveuglément.

5) Symptom: “TLS suddenly fails: certificate not yet valid / expired”

Cause racine : Heure non synchronisée ; confusion de fuseau ; RTC mal configuré ; NTP bloqué.

Correction : Corrigez la synchronisation temporelle d’abord (timedatectl, chrony). Ne roulez pas des certificats tant que l’horloge n’est pas saine sous peine de courir après des fantômes.

6) Symptom: “Performance is terrible after reinstall”

Cause racine : Mauvais driver de stockage, firmware manquant, RAID/ZFS dégradé, ou réglages d’ordonnanceur IO/queue réinitialisés ; ou thrashing swap dû à des paramètres mémoire modifiés.

Correction : Commencez par iostat, vmstat et des contrôles de santé du stockage. Vérifiez l’état RAID/ZFS. Confirmez que vous êtes sur le noyau/stack de drivers attendu.

7) Symptom: “Backups succeed but restores fail”

Cause racine : Sauvegardes capturant de mauvais chemins, permissions/ACLs manquantes, clés de chiffrement mal stockées ; procédure de restauration jamais validée.

Correction : Faites un exercice de restauration : restaurez dans un chemin temporaire, validez l’intégrité et démarrez le service avec la configuration restaurée. Traitez les étapes de restauration comme du code et automatisez‑les.

FAQ

1) Que dois‑je verrouiller en premier après une réinstallation ?

Exposition SSH et politique réseau entrante. Patch du système de base, durcissement SSH (clés, pas de root, pas de mots de passe quand possible) et définition d’un pare‑feu par défaut « deny » avec des autorisations explicites.

2) Dois‑je désactiver immédiatement l’authentification par mot de passe sur SSH ?

Seulement après avoir vérifié l’accès par clé depuis une session séparée et disposer d’un accès console. Désactivez les mots de passe tôt, mais ne le faites pas comme premier changement sur un hôte accessible uniquement à distance.

3) Est‑ce acceptable d’autoriser SSH depuis n’importe où si j’utilise des clés fortes ?

C’est vivable, pas optimal. Les clés fortes réduisent les attaques par credential, mais vous subirez toujours du bruit de bruteforce, des tentatives d’exploit et une exposition accrue. Restreignez par IP source ou VPN quand c’est possible.

4) Comment choisir entre UFW, nftables et firewalld ?

Choisissez l’outil que votre équipe peut opérer de manière cohérente. UFW est simple et courant sur Ubuntu. nftables est puissant et direct. firewalld convient aux environnements déjà standardisés dessus. La cohérence prime sur la préférence.

5) Après réinstallation, pourquoi mes permissions applicatives se cassent même si les fichiers semblent corrects ?

La dérive UID/GID est classique. Le nom d’utilisateur peut correspondre, mais les IDs numériques pas. Vérifiez aussi les ACLs et les refus SELinux/AppArmor. Corrigez d’abord le mapping d’identité ; évitez chmod -R comme « solution ».

6) Dois‑je chiffrer les disques sur les serveurs ?

Si vous avez un risque d’accès physique, des préoccupations multi‑tenant, des exigences de conformité, ou que vous expédiez des disques pour RMA, oui. LUKS ajoute de la complexité opérationnelle (déverrouillage au boot, gestion des clés). Décidez délibérément, puis testez le démarrage et la récupération.

7) Quelle quantité de journalisation est « suffisante » après réinstallation ?

Assez pour répondre : qui s’est connecté, qu’est‑ce qui a changé, qu’est‑ce qui a échoué et que faisait le système avant l’échec. Au minimum : logs d’auth, logs système, logs de services et synchronisation temporelle. Expédiez hors hôte si le risque de compromission est réel.

8) Quel est le moyen le plus rapide pour détecter un service accidentellement exposé ?

ss -lntup sur l’hôte, plus un scan de ports externe depuis un point de vue connu. La vue hôte vous dit ce qui écoute ; le scan externe vous dit ce qui est joignable à travers les pare‑feu.

9) Ai‑je vraiment besoin d’un test de restauration juste après la réinstallation ?

Oui. La réinstallation est le moment où les hypothèses changent : chemins, permissions, clés de chiffrement, noms de services. Un test de restauration maintenant est peu coûteux. En incident, c’est la différence entre récupération et regret.

10) Quel est le changement de durcissement que les gens poussent trop loin ?

Les en‑têtes de sécurité et le réglage crypto avant d’avoir verrouillé l’identité, les mises à jour, le pare‑feu et les sauvegardes. Vous ne gagnez rien à polir la serrure pendant que la porte du garage reste ouverte.

Étapes pratiques suivantes

1. Exécutez l’inventaire des ports à l’écoute et justifiez chaque port ouvert.
2. Définissez par défaut : refuser en entrée sur le pare‑feu hôte et autorisez explicitement SSH depuis des sources connues.
3. Durcissez SSH avec des clés, pas de login root et pas de mots de passe (après validation).
4. Établissez une baseline d’identité : comptes admin, règles sudo et utilisateurs de service avec moindre privilège.
5. Rendez le stockage ennuyeux : vérifiez montages, permissions, rotation et contrôles de santé disque.
6. Prouvez vos sauvegardes en restaurant quelque chose de réel et en démarrant un service depuis cette restauration.
7. Activez les signaux ennuyeux : synchronisation temporelle, limites de rétention de logs et expédition hors hôte quand nécessaire.
8. Consignez la baseline : sorties des commandes clés, versions, règles de pare‑feu et attentes de propriété — pour que le vous futur puisse diff‑checker l’intention.

Si vous ne faites rien d’autre : verrouillez l’accès distant, mettez un pare‑feu par défaut « deny », et testez une restauration. Tout le reste est plus facile quand vous n’êtes pas en feu.