Installation Ubuntu Server 24.04 LTS : la configuration minimale réellement sécurisée

Ce que « minimal » devrait signifier en production

Minimal n’est pas « l’ISO la plus petite ». Minimal, ce sont des contraintes délibérées :

• Surface d’attaque réduite : moins de démons exposés au réseau, moins d’analyseurs, moins de dépendances.
• Mises à niveau prévisibles : les correctifs de sécurité arrivent automatiquement ; les mises fonctionnelles sont planifiées.
• État auditable : vous pouvez expliquer pourquoi un paquet existe et ce qui a ouvert ce port.
• Stockage récupérable : votre disposition des disques survit aux pics de logs, aux core dumps et aux erreurs humaines.
• Ergonomie opérationnelle : journald fonctionne, la synchronisation temporelle fonctionne, le DNS fonctionne, et vous pouvez diagnostiquer sans deviner.

« Sécurisé » n’est pas non plus une case à cocher. C’est une posture : des valeurs par défaut sensées, un accès distant strict, le principe du moindre privilège, des correctifs en temps utile et suffisamment d’observabilité pour détecter les problèmes avant les clients.

Une de mes vérités préférées en production, paraphrasant une idée souvent attribuée au monde SRE : « l’espoir n’est pas une stratégie ; la fiabilité vient de boucles de rétroaction conçues ». — attribué à la communauté opérations/fiabilité proche de la pensée Google SRE.

Blague n°1 : La sécurité, c’est comme passer la soie dentaire : tout le monde admet que c’est bien, et la plupart des gens ne le font correctement qu’après que quelque chose commence à saigner.

Faits et contexte historique utiles à 2 h du matin

Un contexte court et concret vous aide à faire de meilleurs choix sous pression :

1. Cadence LTS d’Ubuntu : les versions LTS sortent tous les deux ans ; opérationnellement, ce rythme est devenu une norme d’entreprise parce qu’il correspond aux cycles budgétaires et au contrôle des changements.
2. systemd n’a pas « gagné » du jour au lendemain : il a remplacé un patchwork de scripts init par un modèle unifié (unités, dépendances, watchdogs). Cette unification explique pourquoi le diagnostic Linux moderne est si rapide — si vous apprenez les outils.
3. Les défauts d’OpenSSH se sont durcis avec le temps : les anciennes primitives cryptographiques ont été supprimées, pas « dépréciées pour toujours ». Si votre client ancien casse, c’est un indice, pas une méchanceté d’Ubuntu.
4. UFW existe parce que les humains ont besoin de garde‑fous : iptables/nftables sont puissants, mais un modèle de politique simple évite l’incident « j’ai accidentellement ouvert Redis au monde ».
5. journald a remplacé les logs éparpillés : les métadonnées structurées (unité, PID, boot ID) expliquent pourquoi « que s’est‑il passé depuis le dernier reboot ? » tient en une commande maintenant.
6. ext4 est devenu ennuyeux volontairement : il a gagné sa réputation en échouant de manière prévisible. Beaucoup d’équipes de production le choisissent non pas parce qu’il est excitant, mais parce qu’il ne les surprend pas.
7. LUKS est devenu courant d’abord sur les portables, puis sur les serveurs : le chiffrement au repos est passé de « paranoïaque » à « exigence de conformité » quand les lois sur la notification de violation et les snapshots cloud ont rendu les données au repos réelles.
8. Les secrets liés au TPM ne sont pas réservés aux postes de travail : les serveurs modernes attendent de plus en plus des racines de confiance matérielles ; les outils d’Ubuntu ont suivi cette tendance.
9. Les unattended security updates sont devenus la norme après les ères des vers : la culture opérationnelle a changé quand le « patch Tuesday » est devenu « patch maintenant ou reconstruis plus tard ».

Décisions de l’installateur qu’on ne peut pas facilement annuler

1) Choisir la bonne ISO et le bon mode d’installation

Utilisez l’installateur officiel Ubuntu Server 24.04 LTS. Si vous installez sur du matériel physique, préférez l’ISO serveur standard. Si vous provisionnez dans le cloud, votre « installateur » est surtout cloud-init plus le choix d’image.

Une configuration minimale signifie : pas d’interface graphique, pas de « rôles serveur » aléatoires au moment de l’installation, pas de snaps supplémentaires à moins que vous sachiez pourquoi.

2) Réseau : DHCP d’abord, fixe ensuite (à moins d’être un routeur)

Si ce serveur n’est pas votre infrastructure réseau, commencez par DHCP pour terminer l’installation et obtenir l’accès distant. Puis définissez une réservation statique dans le DHCP ou passez à une configuration netplan statique une fois que vous connaissez le nom de l’interface et les bons DNS.

Le mode d’échec : vous devinez une IP statique, vous vous trompez de gateway, et votre seule voie de gestion devient un crash cart. Ce n’est pas « sécurisé », c’est juste solitaire.

3) Utilisateurs : créez un seul utilisateur admin, pas de comptes partagés

Créez un utilisateur initial unique avec sudo. N’autorisez pas la connexion root directe par SSH. Traitez les comptes « admin » partagés comme une faiblesse d’audit qui attend d’arriver.

4) SSH : uniquement par clés, et faites‑le tôt

Si l’installateur propose d’importer des clés SSH (par exemple, depuis une identité hébergée), faites‑le. Sinon, ajoutez votre clé publique juste après le premier démarrage. L’authentification par mot de passe sur SSH est une vulnérabilité dont vous pouvez vous passer.

5) Mises à jour : correctifs de sécurité automatiques, redémarrages réfléchis

Activez les mises à jour de sécurité automatiques. Vous ne montrez pas votre courage en approuvant manuellement chaque correctif OpenSSL. Vous créez juste un arriéré de risque.

6) Stockage : décidez de votre rayon d’explosion

Vos choix de stockage déterminent comment la machine échoue. Un système root unique est simple jusqu’à ce que les logs explosent, les conteneurs grossissent ou que quelqu’un dépose une sauvegarde dans /var/tmp.

Pour du minimal mais sûr, visez :

• Une configuration EFI propre (sur matériel moderne).
• Un /boot séparé seulement si nécessaire (par exemple, pour certains setups encrypted-root).
• Root chiffré si le modèle de menace inclut des disques volés, des drives hors service, des mains tierces ou la conformité.
• Un espace séparé pour /var ou au moins une rétention de logs sensée. Si vous exécutez des conteneurs, traitez /var/lib comme un domaine de croissance dédié.

Disposition du stockage : choix ennuyeux, moins de pannes

Soyons clairs : le stockage est l’endroit où « minimal » devient le plus souvent « fragile ». Votre CPU vous pardonnera. Votre disque ne le fera pas.

Configurations de base recommandées

Option A (simple, bon défaut) : ext4 + LUKS sur un disque unique

Convient pour : serveurs généraux, VM, nœuds mono‑disque, tout ce que vous voulez récupérer facilement.

• EFI System Partition (ESP) : ~512 MiB
• /boot (optionnel) : 1 GiB (non chiffré si nécessaire)
• Conteneur LUKS contenant LVM ou ext4 simple pour /

Pourquoi : ext4 est stable, LUKS vous protège au repos, et la récupération ne nécessite pas un doctorat.

Option B (contrôle de croissance) : ext4 + /var séparé

Convient pour : tout ce qui génère des logs, bases de données, conteneurs, runners CI.

• / (root) : taille modeste (par ex. 20–40 GiB)
• /var : plus grand, car il croîtra
• /home : petit ou absent (les serveurs ne devraient pas servir de stockage personnel)

Pourquoi : root reste sain même si /var devient en bazar. Quand /var se remplit, vous pouvez toujours vous connecter et corriger.

Option C (spécialisée) : ZFS root

Convient pour : équipes qui maîtrisent déjà ZFS sur le plan opérationnel. Ne convient pas pour « j’ai entendu dire que ZFS est cool ». ZFS est un système, pas un simple système de fichiers.

Si vous choisissez ZFS, engagez‑vous à surveiller la pression ARC, les plannings de scrub et les interactions avec le bootloader. Si vous ne voulez pas de ces devoirs, utilisez ext4 et passez à autre chose.

Options de montage qui réduisent les dégâts

Certaines options de montage sont des victoires peu coûteuses :

• nodev sur les partitions qui ne devraient pas contenir de fichiers device (souvent /home, /var/tmp).
• nosuid là où vous ne voulez pas que les exécutables setuid fonctionnent (souvent /tmp, /var/tmp).
• noexec peut aider sur /tmp, mais attention : cela peut casser des installateurs et des outils. Utilisez‑le intentionnellement.

Ces options ne « vous rendent pas sûr » à elles seules. Elles réduisent le rayon d’explosion d’une mauvaise journée.

Base post-installation : comptes, SSH, pare‑feu, mises à jour

Paquets : installer moins, supprimer plus

Commencez par ce que l’image serveur vous donne. Ajoutez seulement ce dont votre rôle a besoin. Si vous avez besoin d’un outil pour un dépannage ponctuel, installez‑le, utilisez‑le, et pensez à le supprimer ensuite. Un serveur de production n’est pas votre portable.

Renforcement SSH : auth par clé, surface minimale, valeurs par défaut fortes

État cible :

• Authentification par clé
• Pas de login root via SSH
• Utilisateurs ou groupes restreints autorisés à SSH
• Délai d’inactivité raisonnable
• Journalisation utile sans être bruyante

Pare‑feu : refuser par défaut l’entrée, autoriser seulement ce que vous serviez

Si c’est un serveur, il ne doit pas accepter de trafic entrant sauf si vous le prévoyez explicitement. C’est tout l’intérêt d’un pare‑feu.

Mises à jour de sécurité automatiques

Activez unattended upgrades pour les correctifs de sécurité. Puis décidez comment gérer les redémarrages. Pour beaucoup de flottes : mises à jour automatiques de sécurité plus fenêtres de redémarrage planifiées forment le compromis idéal.

Synchronisation temporelle : parce que des logs sans temps, c’est de la fanfiction

systemd-timesyncd (ou chrony si vous préférez) garantit que votre TLS, vos logs et vos timelines d’incident ne sont pas mauvais.

Blague n°2 : Rien ne vous vieillit plus vite que déboguer des pannes « aléatoires » qui étaient en fait une dérive temporelle.

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

Ci‑dessous se trouvent des tâches réelles à effectuer sur une installation fraîche d’Ubuntu Server 24.04. Chaque entrée inclut : la commande, ce que signifie une sortie typique, et la décision à prendre ensuite. Exécutez‑les en tant qu’utilisateur admin avec sudo si nécessaire.

Tâche 1 : Confirmer ce que vous avez réellement installé

cr0x@server:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.04 LTS
Release:        24.04
Codename:       noble

Ce que cela signifie : Vous êtes sur la bonne version LTS et le bon nom de code. Pas de supposition, pas de « je croyais avoir installé 24.04 ».

Décision : Si ce n’est pas 24.04 LTS, arrêtez et corrigez votre pipeline d’images avant de durcir la mauvaise version.

Tâche 2 : Vérifier le noyau et le mode de démarrage (EFI vs legacy)

cr0x@server:~$ uname -r
6.8.0-31-generic

cr0x@server:~$ test -d /sys/firmware/efi && echo "UEFI boot" || echo "Legacy boot"
UEFI boot

Ce que cela signifie : La ligne du noyau confirme ce que vous exécutez. La présence d’UEFI est importante pour le partitionnement et le comportement du bootloader.

Décision : Si vous attendiez l’UEFI mais avez du legacy, corrigez les réglages du firmware maintenant. Les environnements mixtes causent des récupérations de boot bizarres plus tard.

Tâche 3 : Voir clairement vos disques, partitions et systèmes de fichiers

cr0x@server:~$ lsblk -e7 -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL
NAME        SIZE TYPE FSTYPE      MOUNTPOINTS MODEL
nvme0n1   476.9G disk                       Samsung SSD 980
├─nvme0n1p1  512M part vfat        /boot/efi
├─nvme0n1p2    1G part ext4        /boot
└─nvme0n1p3 475.4G part crypto_LUKS          

cr0x@server:~$ sudo cryptsetup status luks-root
/dev/mapper/luks-root is active and is in use.
  type:    LUKS2
  cipher:  aes-xts-plain64
  keysize: 512 bits
  device:  /dev/nvme0n1p3
  sector size:  512
  offset:  32768 sectors
  size:    997638144 sectors
  mode:    read/write

Ce que cela signifie : Vous voyez la carte des périphériques. LUKS2 actif indique que le chiffrement fonctionne.

Décision : Si le chiffrement était requis et que vous ne voyez pas crypto_LUKS, vous n’êtes pas conforme. Réinstallez ou migrez correctement ; ne dites pas « je réparerai plus tard ».

Tâche 4 : Vérifier l’utilisation des systèmes de fichiers avant la surprise

cr0x@server:~$ df -hT
Filesystem     Type   Size  Used Avail Use% Mounted on
/dev/mapper/vg0-root ext4    40G  3.2G   35G   9% /
/dev/nvme0n1p2 ext4  1007M  220M  720M  24% /boot
/dev/nvme0n1p1 vfat   511M  6.1M  505M   2% /boot/efi
tmpfs          tmpfs  3.1G     0  3.1G   0% /run/user/1000

Ce que cela signifie : Vous vérifiez que root n’est pas minuscule et que /boot a de la place pour les mises à jour du noyau.

Décision : Si /boot a moins d’environ ~300–400 MiB de libre, vous échouerez éventuellement les mises à jour du noyau. Redimensionnez les partitions ou nettoyez les anciens noyaux intentionnellement.

Tâche 5 : Confirmer ce qui écoute sur le réseau

cr0x@server:~$ sudo ss -tulpen
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=1020,fd=3)) uid:0 ino:27360 sk:3 cgroup:/system.slice/ssh.service

Ce que cela signifie : Seul SSH écoute. C’est une base propre.

Décision : Si vous voyez des écouteurs inattendus (base de données, serveur web, services RPC), désinstallez/désactivez ou justifiez leur présence. « Je ne savais pas que c’était lancé » n’est pas une défense.

Tâche 6 : Établir les valeurs par défaut du pare‑feu (UFW)

cr0x@server:~$ sudo ufw status verbose
Status: inactive

cr0x@server:~$ sudo ufw default deny incoming
Default incoming policy changed to 'deny'
(be sure to update your rules accordingly)

cr0x@server:~$ sudo ufw default allow outgoing
Default outgoing policy changed to 'allow'
(be sure to update your rules accordingly)

cr0x@server:~$ sudo ufw allow 22/tcp
Rule added
Rule added (v6)

cr0x@server:~$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

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    Anywhere
22/tcp (v6)                ALLOW IN    Anywhere (v6)

Ce que cela signifie : Vous avez verrouillé le trafic entrant sur SSH uniquement.

Décision : Avant d’activer UFW à distance, assurez‑vous que SSH est autorisé et que vous avez un accès console si vous vous trompez. Règle de production : ne vous coupez jamais l’accès à une machine que vous ne pouvez pas atteindre physiquement.

Tâche 7 : Durcir la configuration SSH et la valider en sécurité

cr0x@server:~$ sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

cr0x@server:~$ sudoedit /etc/ssh/sshd_config

Lignes minimales durs à définir (ajustez les noms d’utilisateurs/groupes) :

cr0x@server:~$ sudo grep -nE '^(PermitRootLogin|PasswordAuthentication|KbdInteractiveAuthentication|AllowUsers|AllowGroups|X11Forwarding|ClientAliveInterval|ClientAliveCountMax)' /etc/ssh/sshd_config
33:PermitRootLogin no
57:PasswordAuthentication no
58:KbdInteractiveAuthentication no
89:X11Forwarding no
101:ClientAliveInterval 300
102:ClientAliveCountMax 2

cr0x@server:~$ sudo sshd -t

cr0x@server:~$ sudo systemctl reload ssh

Ce que cela signifie : sshd -t sans sortie signifie succès. Reload applique les changements sans couper les sessions existantes.

Décision : Si sshd -t affiche des erreurs, ne rechargez pas. Corrigez la config d’abord. Les erreurs de syntaxe sont un classique auto‑infligé.

Tâche 8 : Confirmer les méthodes d’authentification SSH via les logs

cr0x@server:~$ sudo journalctl -u ssh -n 20 --no-pager
Aug 01 10:12:44 server sshd[1442]: Accepted publickey for cr0x from 10.0.0.50 port 50192 ssh2: ED25519 SHA256:Qm...
Aug 01 10:13:02 server sshd[1461]: Connection closed by authenticating user ubuntu 10.0.0.51 port 55322 [preauth]

Ce que cela signifie : Vous voyez des connexions par clé réussies. Vous pouvez aussi repérer des tentatives suspectes ou des noms d’utilisateur inattendus.

Décision : Si vous voyez encore des acceptations par mot de passe, votre config SSH n’est pas appliquée ou vous éditez le mauvais fichier sshd include. Réparez cela maintenant.

Tâche 9 : Activer unattended-upgrades et vérifier le comportement

cr0x@server:~$ sudo apt update
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Hit:2 http://security.ubuntu.com/ubuntu noble-security InRelease
Reading package lists... Done
Building dependency tree... Done
All packages are up to date.

cr0x@server:~$ sudo apt install -y unattended-upgrades
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  unattended-upgrades
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.

cr0x@server:~$ sudo systemctl status unattended-upgrades --no-pager
● unattended-upgrades.service - Unattended Upgrades Shutdown
     Loaded: loaded (/usr/lib/systemd/system/unattended-upgrades.service; enabled)
     Active: inactive (dead)

Ce que cela signifie : Le service s’exécute via des timers et des hooks de shutdown ; « inactive » peut être normal.

Décision : Assurez‑vous que le timer est activé, et confirmez que seules les sources de sécurité sont sélectionnées si vous voulez des changements minimaux.

Tâche 10 : Vérifier les timers apt et le dernier run

cr0x@server:~$ systemctl list-timers --all | grep -E 'apt|unattended'
Fri 2026-02-06 06:12:21 UTC  10h left   Thu 2026-02-05 06:13:02 UTC  13h ago  apt-daily.timer             apt-daily.service
Fri 2026-02-06 06:45:10 UTC  10h left   Thu 2026-02-05 06:45:22 UTC  13h ago  apt-daily-upgrade.timer     apt-daily-upgrade.service

cr0x@server:~$ sudo tail -n 30 /var/log/unattended-upgrades/unattended-upgrades.log
2026-02-05 06:45:23,121 INFO Starting unattended upgrades script
2026-02-05 06:45:23,210 INFO No packages found that can be upgraded unattended

Ce que cela signifie : Les timers sont programmés et se sont exécutés. Les logs montrent si des mises à jour ont eu lieu.

Décision : Si les timers manquent, vous êtes peut‑être sur une image allégée ou les timers sont désactivés par une politique — corrigez cela intentionnellement, pas accidentellement.

Tâche 11 : Confirmer l’état de la synchronisation temporelle

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

Ce que cela signifie : L’horloge est synchronisée et le service NTP est actif. UTC est un choix serveur sensé.

Décision : Si la synchronisation est « no », réparez le temps avant de déboguer autre chose. TLS et systèmes cluster se comportent mal avec une dérive.

Tâche 12 : Vérifier DNS et routage rapidement (sanité réseau)

cr0x@server:~$ ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
enp1s0           UP             10.0.10.25/24 fe80::a00:27ff:fe4e:66a1/64

cr0x@server:~$ ip r
default via 10.0.10.1 dev enp1s0
10.0.10.0/24 dev enp1s0 proto kernel scope link src 10.0.10.25

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.0.10.2
       DNS Servers: 10.0.10.2 10.0.10.3

Ce que cela signifie : L’interface est up, la route par défaut existe, les serveurs DNS sont configurés.

Décision : Si le DNS est incorrect, corrigez netplan ou les options DHCP ; ne « contournez » pas avec des hacks /etc/hosts sauf si c’est un mappage de service délibéré.

Tâche 13 : Confirmer les paquets installés (repérer le gonflement accidentel)

cr0x@server:~$ apt list --installed | head -n 15
Listing... Done
adduser/noble,now 3.137ubuntu1 all [installed]
apt/noble-updates,now 2.7.14 amd64 [installed]
base-files/noble,now 13ubuntu10 amd64 [installed]
bash/noble,now 5.2.21-2ubuntu4 amd64 [installed]
bsdutils/noble,now 1:2.39.3-9ubuntu6 amd64 [installed]

Ce que cela signifie : Vous pouvez voir rapidement l’univers de paquets que vous devez maintenir.

Décision : Si vous voyez des rôles serveur non prévus (base de données, stack mail), supprimez‑les ou reconstruisez. Les démons cachés deviennent des « ports mystères ».

Tâche 14 : Confirmer qu’AppArmor est actif

cr0x@server:~$ sudo aa-status
apparmor module is loaded.
45 profiles are loaded.
45 profiles are in enforce mode.
0 profiles are in complain mode.
0 processes are unconfined but have a profile defined.

Ce que cela signifie : Le contrôle d’accès obligatoire est présent et en mode enforce pour les profils connus.

Décision : Si AppArmor est désactivé, vous choisissez une base plus faible. Réactivez‑le sauf si vous avez une incompatibilité prouvée et un plan d’atténuation.

Tâche 15 : Vérifier les privilèges utilisateur et supprimer les défauts risqués

cr0x@server:~$ id
uid=1000(cr0x) gid=1000(cr0x) groups=1000(cr0x),27(sudo)

cr0x@server:~$ sudo -l
Matching Defaults entries for cr0x on server:
    env_reset, mail_badpass, secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

User cr0x may run the following commands on server:
    (ALL : ALL) ALL

Ce que cela signifie : Votre utilisateur admin peut s’élever, et la politique sudo est par défaut.

Décision : En environnement d’entreprise, privilégiez le moindre privilège via des politiques sudoers. Pour un serveur mono‑usage, limitez les admins et rendez‑les traçables.

Tâche 16 : Repérer les problèmes de santé disque avant les « crashes aléatoires »

cr0x@server:~$ sudo apt install -y smartmontools
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  smartmontools

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | head -n 20
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.8.0-31-generic] (local build)
=== START OF INFORMATION SECTION ===
Model Number:                       Samsung SSD 980
Serial Number:                      S64...
Firmware Version:                   2B4QFXO7
NVMe Version:                       1.4
Total NVM Capacity:                 500,107,862,016 [500 GB]

Ce que cela signifie : Vous pouvez confirmer le périphérique, le firmware, et plus tard vérifier les compteurs d’erreurs.

Décision : Si les données smart montrent des erreurs média ou des warnings critiques, remplacez le disque. Ne discutez pas la physique.

Playbook de diagnostic rapide (trouver le goulot vite)

Ceci est le playbook « le serveur est lent » qui fonctionne en exploitation réelle. L’objectif est d’identifier la ressource limitante en quelques minutes, pas de collecter des trivia.

Première étape : confirmer que ce n’est pas le réseau ou le DNS

• Vérifier routes et lien : ip -br a, ip r
• Vérifier DNS : resolvectl status
• Vérifier backlog/socket : ss -s, ss -tulpen

Si le DNS est cassé, tout paraît lent. Installations de paquets, handshakes TLS, appels API — douleur partout.

Deuxième étape : trouver le processus chaud et ce sur quoi il attend

• Vue haute niveau : top ou htop (si installé)
• Pression système : uptime (load average), vmstat 1
• IO par processus : pidstat -d 1 (depuis sysstat) si nécessaire

Cherchez : CPU saturé (compute), forte charge avec CPU faible (souvent IO wait), pression mémoire (swap), ou une horde de processus.

Troisième étape : déterminer si le stockage est le goulot

• IO wait et périphériques bloc : iostat -xz 1 (sysstat)
• Systèmes de fichiers pleins : df -hT
• Erreurs disque : dmesg -T | tail, journalctl -k -n 200

Signal classique : load average élevé, CPU au repos, et temps de réponse mauvais. C’est souvent la latence stockage.

Quatrième étape : confirmer que la mémoire n’est pas silencieusement écrasée

• Vue mémoire : free -h
• Évidence OOM : journalctl -k | grep -i oom

Si le noyau tue des processus, traitez cela comme un problème de capacité ou de fuite, pas comme des « crashes aléatoires ».

Cinquième étape : vérifier systemd pour unités en échec et services qui flappent

• Services en échec : systemctl --failed
• Erreurs récentes : journalctl -p err..alert -b

Les démons qui bounce peuvent créer de la charge, des tempêtes de logs, l’épuisement de ports, et des faux symptômes. systemd vous le dira si vous lui demandez directement.

Erreurs courantes : symptômes → cause principale → correctif

1) « J’ai activé UFW et je me suis fait verrouiller »

Syndromes : SSH coupe, reconnexion impossible, la console fonctionne toujours.

Cause principale : Pare‑feu activé avant d’autoriser SSH, ou mauvaise interface/port autorisé.

Correctif : Depuis la console : sudo ufw disable. Puis réappliquez dans le bon ordre : allow SSH d’abord, confirmez, puis enable. En environnements avec ports SSH non standards, autorisez explicitement ce port et vérifiez avec ss -tulpen avant d’activer.

2) « Les mises à niveau du noyau échouent car /boot est plein »

Syndromes : erreurs lors de apt upgrade, échecs DKMS, paquets noyau anciens accumulés.

Cause principale : partition /boot trop petite ou anciens noyaux non nettoyés.

Correctif : Supprimez les anciens noyaux soigneusement : dpkg -l 'linux-image-*', puis purge des versions obsolètes (pas le noyau en cours). À plus long terme : allouez un /boot plus grand ou évitez un /boot séparé sauf si nécessaire.

3) « Les clés SSH ne fonctionnent pas ; la connexion par mot de passe est toujours proposée »

Syndromes : l’auth publickey échoue, le serveur demande un mot de passe, les logs montrent Failed publickey.

Cause principale : mauvaises permissions sur ~/.ssh ou authorized_keys, mauvais utilisateur, ou édition d’un include de sshd non actif.

Correctif : Assurez‑vous que ~/.ssh est 700, authorized_keys est 600, appartenant à l’utilisateur. Validez la config avec sshd -T et sshd -t. Puis reload ssh.

4) « Les apt update se bloquent aléatoirement »

Syndromes : apt update plante, surtout sur des résolutions DNS ou l’accès aux miroirs.

Cause principale : DNS cassé, proxy captif, ou problèmes de chemin IPv6.

Correctif : Vérifiez resolvectl status et le routage. Testez la résolution avec getent hosts archive.ubuntu.com. Si IPv6 est cassé, corrigez le réseau proprement au lieu de désactiver IPv6 aveuglément (la désactivation peut casser des environnements modernes aussi).

5) « Le disque se remplit pendant la nuit et la machine devient hantée »

Syndromes : services qui ne démarrent pas, SSH lent, logs qui s’arrêtent, journald se plaint.

Cause principale : croissance de /var (logs, couches conteneurs, dumps) sur un filesystem root unique sans quotas ni séparation.

Correctif : Identifiez les coupables (du -xh --max-depth=1 /var). Ajoutez de la rétention de logs, séparez /var lors d’une reconstruction, et envisagez le tuning de l’espace réservé du filesystem. Si vous exécutez des conteneurs, traitez /var/lib comme un domaine de capacité dédié.

6) « La machine est lente, mais le CPU est au repos »

Syndromes : load average élevé, CPU au repos significatif, temps de réponse mauvais.

Cause principale : latence stockage, IO wait, ou processus bloqué sur IO (par ex. fsync synchrone d’une base de données).

Correctif : Utilisez iostat -xz 1 et vérifiez l’utilisation et l’attente disque. Cherchez des erreurs dans journalctl -k. Si c’est une VM, contrôlez le stockage hôte et les voisins bruyants aussi.

7) « Les unattended upgrades ont cassé mon service »

Syndromes : service en échec après des mises à jour nocturnes ; problèmes de compatibilité.

Cause principale : vous avez autorisé plus que les mises à jour de sécurité (ou une mise à jour de sécurité a changé un comportement).

Correctif : Pincez unattended‑upgrades aux seuls pockets de sécurité, et mettez en scène les updates dans un canari. Si un service est extrêmement sensible, gérez ce paquet via un contrôle de changement explicite — mais gardez le reste patché.

Trois mini-récits d’entreprise du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

L’entreprise avait une image standard « minimal Ubuntu ». Elle bootait vite, faisait tourner une application, et passait le scan de sécurité. Tout le monde s’est félicité et est passé à autre chose, ce qui annonce toujours la page suivante.

Une équipe a déployé une nouvelle fournée de serveurs et a activé le chiffrement disque complet. Ils ont supposé que le layout de l’installateur protégerait root. Ils n’ont pas séparé /var, n’ont pas fixé de limites journald, et n’ont pas validé les hypothèses sur le volume de logs. L’application avait un bug qui augmentait la verbosité des logs lors d’une erreur transitoire. Vous devinez la suite.

En quelques heures, les disques se sont remplis. Une fois / plein, l’échec a cascaded : journald ne pouvait plus écrire, les services ne pouvaient plus créer de fichiers temporaires, les gestions de paquets ne pouvaient plus tourner, et même les connexions SSH sont devenues erratiques car l’authentification écrit aussi sur disque. L’ingénieur on‑call a vécu l’expérience classique de tenter de réparer un système qui ne pouvait pas enregistrer qu’il était en panne.

Le postmortem ne portait pas sur le bug applicatif ; ces choses arrivent. La vraie mauvaise hypothèse était « l’image minimal = risque minimal ». Ils avaient besoin d’un layout isolant la croissance (un /var séparé) et d’une politique de logs traitant le disque comme une ressource finie, pas une suggestion.

La correction fut ennuyeuse : guide de partitionnement, limites de logs, et un test pre‑deploy qui spamme volontairement les logs pour prouver que le serveur reste récupérable. Ce test est maintenant la raison pour laquelle leur image « minimal » mérite ce nom.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Un groupe orienté performance a décidé que « le chiffrement est un overhead » et a retiré LUKS d’une flotte de serveurs sur NVMe rapides. Ils ont mesuré un bench qui s’est amélioré légèrement. La diapositive était convaincante. Elle l’est toujours.

Des mois plus tard, un workflow de mise hors service a envoyé des disques à un recycleur tiers. Un lot n’a pas été correctement effacé ; une lacune de processus, pas une intention malveillante. Mais l’intention importe peu quand un disque contenant des données clients quitte l’entreprise. La réponse à l’incident fut brutale : légal, conformité, communications clients, et le type de réunions internes où chaque phrase devient une pièce à conviction.

Techniquement, ce n’était pas une compromission hacker. C’était pire d’une autre manière : c’était évitable. Le chiffrement aurait transformé cet événement en non‑événement, à condition que les clés aient été gérées correctement et pas collées sur le châssis.

Le retour de bâton n’était pas seulement « on a perdu la sécurité ». C’était un frein opérationnel. Ils ont dû implémenter des contrôles d’effacement d’urgence, réauditer la gestion des actifs, et rétrofiter le chiffrement dans un environnement déjà rempli de données. Rétrofiter à grande échelle est toujours plus dur que le faire à l’installation.

La leçon est tombée : optimisez là où c’est important et où vous pouvez prouver la sécurité. Si l’optimisation fait gagner 2 % et crée une falaise de conformité, ce n’est pas une optimisation. C’est un incident futur avec un joli marketing.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre organisation avait une politique peu glamour : chaque build serveur doit passer un « listen test » et un « patch test ». Le listen test consiste simplement à lister tous les ports écoutés et expliquer chacun. Le patch test : prouver que les mises à jour de sécurité sont activées et programmées, et montrer le dernier run réussi.

Les gens levaient les yeux au ciel. Ça semblait du travail administratif. Cela prenait aussi environ trois minutes quand automatisé correctement, ce qui est moins de temps que d’en débattre.

Un jour, une nouvelle image de base incluait accidentellement un agent de télémétrie ouvrant une UI web locale liée à 0.0.0.0. Personne n’avait l’intention d’exposer cela ; il était simplement empaqueté ainsi. Dans beaucoup d’environnements, cela serait arrivé en production et attendu qu’un scanner le découvre.

Le listen test a échoué immédiatement. L’ingénieur a pointé ss -tulpen, identifié le process, et bloqué la release. Ils ont retiré l’agent, reconstruit l’image, et sont passés à autre chose. Aucun incident. Pas de communication publique. Pas de réparation nocturne.

Voilà le gain silencieux : une habitude terne qui attrape les problèmes pointus. Les meilleures pannes sont celles que vous n’avez jamais à rédiger.

Listes de contrôle / plan étape par étape

Phase 0 : Avant de démarrer l’installateur (10 minutes qui évitent les regrets)

• Décidez : le chiffrement disque est‑il requis ? Si oui, planifiez la saisie/récupération des clés dans votre environnement (console, KVM distant, ou intégration TPM si applicable).
• Décidez : avez‑vous besoin d’un /var séparé (recommandé pour la plupart des serveurs) ? Si oui, dimensionnez‑le selon logs + données applicatives + croissance conteneurs.
• Décidez : comment accèderez‑vous au serveur si le réseau est cassé ? IPMI/iDRAC/iLO, console virtuelle, ou accès physique.
• Préparez les clés SSH pour l’utilisateur admin initial.
• Notez : hostname, stratégie IP prévue (DHCP/statique), serveurs DNS, attentes NTP.

Phase 1 : Choix de l’installateur (restez minimal, restez récupérable)

1. Installez Ubuntu Server 24.04 LTS (sans GUI).
2. Créez un utilisateur admin unique (sudo activé).
3. Importez ou ajoutez le support de clés SSH pendant l’installation si proposé.
4. Sélectionnez le stockage :
   • Utilisez LUKS si requis.
   • Privilégiez ext4 sauf si vous avez déjà un modèle opérationnel ZFS.
   • Considérez fortement un /var séparé pour les serveurs avec toute charge d’écriture.
5. Sauter les rôles serveur supplémentaires sauf si c’est une installation dédiée et que vous savez exactement pourquoi vous en avez besoin.

Phase 2 : Premier démarrage – baseline (le minimum sécurisé)

1. Mettre à jour les listes de paquets : sudo apt update.
2. Installer l’automatisation de sécurité : sudo apt install unattended-upgrades ; confirmer les timers.
3. Durcir SSH : désactiver l’auth par mot de passe, désactiver le login root, recharger ssh, confirmer que la connexion par clé fonctionne.
4. Activer UFW avec par défaut deny inbound ; n’autoriser que les ports requis.
5. Confirmer la synchronisation temporelle : timedatectl montre « synchronized ».
6. Confirmer les écouteurs : sudo ss -tulpen est exactement ce que vous vouliez.
7. Enregistrer l’état : capturer les sorties de lsblk, df -hT, systemctl --failed.

Phase 3 : Durcissement sans s’auto‑saboter

• Appliquez des options de montage pour /tmp et /var/tmp de façon réfléchie. Testez vos logiciels ; ne cassez pas silencieusement des installateurs.
• Limitez la rétention de journald pour que les logs n’engouffrent pas les disques : plafonnez par taille et durée selon votre environnement.
• Utilisez le durcissement des services systemd pour vos unités d’application (NoNewPrivileges, ProtectSystem, PrivateTmp). Faites‑le progressivement et testez.
• Décidez d’une politique de redémarrage : fenêtre de maintenance planifiée ou redémarrages automatisés quand nécessaire. Dans tous les cas, soyez explicite.

Phase 4 : Opérabilité (parce que « sécurisé » et « diagnostiqueable » vont ensemble)

• Installez des hooks de monitoring basiques : usage disque, santé SMART/NVMe, unités systemd en échec, statut des mises à jour.
• Assurez‑vous que les logs sont accessibles à distance (centralisation) si vous gérez plus d’un serveur.
• Réalisez un exercice de panne : remplissez /var (safely, en staging), vérifiez que le serveur reste récupérable et que les alertes se déclenchent.

FAQ

Ai‑je vraiment besoin d’un pare‑feu si seul SSH écoute ?

Oui. « Seul SSH écoute » est un instantané, pas une garantie. Le pare‑feu est le filet de sécurité pour les futurs paquets installés, services accidentels et erreurs humaines.

Désactiver l’authentification par mot de passe SSH est‑il toujours la bonne décision ?

Pour les serveurs accessibles depuis Internet : oui, presque toujours. Pour les réseaux de labo isolés : toujours recommandé. Si vous devez garder les mots de passe (conformité ou legacy), imposez MFA via une méthode prise en charge et limitez fortement le débit. Mais reconnaissez que vous augmentez le risque.

Dois‑je changer le port SSH ?

Ça réduit le bruit de balayage automatique, pas les attaquants déterminés. Si vous le faites, faites‑le pour la propreté des logs, pas comme « sécurité ». La vraie sécurité, ce sont les clés, le contrôle d’accès et le patching.

Dois‑je installer Fail2ban ?

Ce n’est pas indispensable si vous avez désactivé l’auth par mot de passe et restreint les utilisateurs SSH. Il peut être utile pour réduire le bruit et ralentir les tentatives bruteforce, mais ce n’est pas un substitut à une politique d’authentification correcte.

Le chiffrement complet du disque vaut‑il la peine sur des serveurs ?

Oui quand le modèle de menace inclut des disques perdus, des mains tierces, le risque de colocation, des erreurs de mise hors service ou des snapshots hors de votre contrôle. Le coût opérationnel est la gestion des clés et le déverrouillage au boot. Planifiez cette partie, ne l’improvisez pas pendant un incident.

ext4 ou XFS pour une configuration minimale sécurisée ?

ext4 est le choix conservateur et facile à récupérer. XFS convient pour de grands filesystem et certaines charges, mais ext4 remporte le concours « ennuyeux et prévisible » pour les serveurs généraux.

Comment empêcher les logs de remplir le disque ?

Utilisez deux leviers : limites journald et logrotate (pour les logs traditionnels). Isolez aussi la croissance : un /var séparé ou au moins une surveillance dédiée. Si vos apps sont bavardes, corrigez le logging applicatif.

Dois‑je installer plein d’outils de dépannage dès le départ ?

Non. Installez une base minimale plus ce dont votre modèle opérationnel a besoin (souvent : smartmontools, peut‑être sysstat). Tout le reste peut être installé temporairement. Chaque paquet en plus est du code que vous devrez patcher indéfiniment.

Quel est le minimum de preuves à capturer après installation ?

Au minimum : version OS, disposition disque, utilisation des filesystems, ports à l’écoute, règles de pare‑feu, statut des timers de mise à jour, statut de la synchronisation temporelle, et unités systemd en échec. Cela prouve à la fois la posture de sécurité et l’opérabilité.

Comment savoir si mon système est suffisamment sécurisé ?

Posez des questions concrètes : Quelqu’un peut‑il brute‑forcer SSH par mot de passe ? Les ports entrants sont‑ils restreints ? Les mises à jour de sécurité sont‑elles automatiques ? AppArmor est‑il en mode enforce ? Un remplissage de disque peut‑il mettre à bas toute la machine ? Si vous pouvez répondre avec des commandes et des configs, vous faites de la vraie sécurité.

Prochaines étapes à faire réellement

Voici la liste pratique de clôture — la partie qui sépare « installé » de « prêt pour la production » :

1. Verrouillez SSH et testez depuis une seconde session avant de vous déconnecter.
2. Activez UFW avec deny inbound par défaut et des autorisations explicites uniquement.
3. Activez unattended security updates et confirmez que les timers ont tourné au moins une fois.
4. Vérifiez la disposition du stockage avec lsblk et df -hT ; assurez‑vous que /boot et /var ne vous surprendront pas.
5. Fixez la rétention journald à un plafond raisonnable pour la taille du disque et vos besoins de logs.
6. Documentez la « listen list » : quels ports sont ouverts et pourquoi. Traitez tout écouteur inconnu comme un bloqueur de release.
7. Exécutez le playbook de diagnostic rapide une fois sur un système sain pour savoir à quoi ressemble la normale.
8. Décidez de votre stratégie de redémarrage avant que le premier correctif noyau ne force la discussion au pire moment.

Minimal est une discipline. Sécurisé est une habitude. Ubuntu Server 24.04 LTS vous donne de bons primitives — mais vous devez quand même conduire la voiture.