Hardening baseline Linux : updates, users et services
À la fin de ce tutoriel hardening linux, vous saurez poser une baseline post-lot1 : inventaire des unités/services et comptes, unattended-upgrades (Debian/Ubuntu) avec note dnf-automatic, verrouillage de comptes inutiles et revue sudoers.d, désactivation prudente de services lab (
disable/mask), et un drop-in sysctl léger — le tout sur VM jetable avec console de secours. Ce n’est pas un CIS complet, ni Lynis exhaustif, ni AppArmor (autre chapitre), ni un redo nft / fail2ban / SSH 2FA.Niveau : Intermédiaire+ · Temps estimé : 45–55 min · Versions testées : Ubuntu 22.04 / 24.04, Debian 12 ; notes Rocky/Alma 9 · Dernière vérification : 2026-09-11
Slug proposé :
linux-hardening-baseline· Série : Linux Réseau & Sécurité · Remplace / fusionne : N/A — création (lot 2, chapitre hardening baseline)
Prérequis
- Hub Linux Réseau & Sécurité ; lot 1 terminé idéalement (nftables, fail2ban, TLS certbot, SSH hardening)
- Socle Linux Basics : utilisateurs & sudo, paquets, processus & systemd
- Chapitre voisin utile : auditd (suivi fichiers) — complémentaire, pas un prérequis bloquant
- Console provider, IPMI ou SSM ouverte avant de
mask/ couper un service critique - Lab sous
/tmp/lab-hardening;sudo; pas de secrets dans le dépôt
Coût : 0 €. Risque : mask sur sshd / network = lock-out. Snapshot + console = non négociable.
Ce que nous allons construire
Inventaire : units enabled · users · reboot pending
→ Updates auto : unattended-upgrades (apt) · note dnf-automatic
→ Comptes & sudo : lock inutiles · revue sudoers.d
→ Services : disable/mask lab (bluetooth, cups, avahi…)
→ Sysctl léger : drop-in 99-lab-hardening.conf
→ Checklist + rollback
(Schéma à remplacer par une image locale Excalidraw / draw.io, alt : « Hardening baseline : updates, users, services, sysctl lab — suite lot 1 Sécurité ».)
Chapitre lot 2 : après avoir durci le réseau et SSH, on réduit la surface OS — packages à jour, moins de daemons, moins de comptes « oubliés », quelques knobs kernel sûrs. On reste pragmatique DevOps : checklist reproductible, pas un audit CIS de 200 contrôles.
Règle d’or : ne désactivez jamais
ssh,sshd,systemd-networkd/NetworkManager,systemd-logindsans console ouverte et plan de rollback.
Étape 1 — Inventaire baseline (avant de toucher)
Créez le lab et photographiez l’état.
mkdir -p /tmp/lab-hardening && cd /tmp/lab-hardening
date -Is | tee inventory-started.txt
# Unités enabled (aperçu)
systemctl list-unit-files --type=service --state=enabled --no-pager | tee units-enabled.txt
# Comptes humains typiques (UID >= 1000) + shell
getent passwd | awk -F: '$3>=1000 && $3<65534 {print $1,$3,$7}' | tee users-lab.txt
# Reboot / updates en attente (Debian/Ubuntu)
test -f /var/run/reboot-required && cat /var/run/reboot-required || echo "no reboot-required flag"
command -v apt >/dev/null && apt list --upgradable 2>/dev/null | head -30 | tee apt-upgradable.txt || true
Lisez units-enabled.txt : chaque service enabled est une porte potentielle. Notez ce qui est légitime (ssh, cron/timers utiles, votre stack) vs bruit (impression, bluetooth sur un VPS headless).
| Signal | Interprétation |
|---|---|
Beaucoup d’enabled inconnus |
Surface large — candidat disable |
Compte UID≥1000 avec /bin/bash oublié |
Compte à lock ou à documenter |
reboot-required |
Kernel/libc majeurs — planifiez la fenêtre |
Étape 2 — Updates automatiques (sécurité des paquets)
Sans patch régulier, le reste du hardening est cosmétique. Sur Debian/Ubuntu :
# Debian / Ubuntu
sudo apt update
sudo apt install -y unattended-upgrades apt-listchanges
# Activer (interactive sur certaines images ; sinon drop-in)
sudo dpkg-reconfigure -plow unattended-upgrades || true
# Drop-in lab : sécurité auto, pas de reboot silencieux agressif
sudo tee /etc/apt/apt.conf.d/52-lab-unattended >/dev/null << 'EOFAPT'
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
EOFAPT
# Dry-run / statut
sudo unattended-upgrade --dry-run --debug 2>&1 | tail -40 | tee /tmp/lab-hardening/uu-dryrun.txt
systemctl is-enabled unattended-upgrades 2>/dev/null || true
Rocky / Alma 9 : équivalent typique = dnf-automatic (sudo dnf install -y dnf-automatic puis timer dnf-automatic.timer). Préférez le mode download + notify ou security-only avant d’autoriser un reboot auto en lab.
Ne forcez pas Automatic-Reboot "true" sur un VPS sans fenêtre de maintenance et healthcheck. Les updates de sécu + reboot planifié battent le reboot surprise à 3 h du matin.
Étape 3 — Comptes et sudo : réduire les identités
# Lister comptes avec shell de login (hors nologin/false)
getent passwd | awk -F: '$7 !~ /(nologin|false)$/ {printf "%-16s UID=%-5s %sn",$1,$3,$7}'
# Exemple lab : verrouiller un compte de test créé pour l’exo (PAS votre user admin)
# sudo useradd -m -s /bin/bash labghost 2>/dev/null || true
# sudo passwd -l labghost
# passwd -S labghost
# Revue sudoers drop-ins (ne pas écraser sudoers principal)
sudo ls -la /etc/sudoers.d/ | tee /tmp/lab-hardening/sudoers-d.txt
# Valider syntaxe si vous éditez un drop-in :
# sudo visudo -cf /etc/sudoers.d/99-lab
| Action | Quand | Attention |
|---|---|---|
passwd -l user |
Compte inutile encore présent | Gardez un admin sudo valide |
Shell nologin |
Service account | Ne cassez pas un daemon qui attend un shell |
Drop-in sudoers.d |
Droits granulaires | Jamais NOPASSWD:ALL en prod ; lab OK si documenté et jetable |
Compte root SSH |
Déjà traité en SSH hardening | Ici on parle comptes locaux / sudo |
Notez dans /tmp/lab-hardening/accounts-notes.txt qui a sudo et quels comptes sont lockés.
Étape 4 — Services : disable puis mask (avec prudence)
Ciblez des daemons typiquement inutiles sur un VPS/lab headless. Adaptez : si cups vous sert, ne le coupez pas.
# Candidats fréquents (ignorer si unit absente)
CANDIDATES=(bluetooth.service cups.service cups-browsed.service avahi-daemon.service ModemManager.service)
for u in "${CANDIDATES[@]}"; do
if systemctl list-unit-files "$u" &>/dev/null; then
echo "=== $u ==="
systemctl is-enabled "$u" 2>/dev/null || true
systemctl is-active "$u" 2>/dev/null || true
fi
done | tee /tmp/lab-hardening/candidates.txt
# Disable + stop (réversible) — UN service à la fois, vérifiez SSH encore OK
# Exemple :
# sudo systemctl disable --now avahi-daemon.service 2>/dev/null || true
# Mask = empêche même un start manuel / dépendance surprise (lab agressif)
# sudo systemctl mask avahi-daemon.service 2>/dev/null || true
# Vérif
systemctl is-enabled avahi-daemon.service 2>/dev/null || echo "avahi absent ou déjà traité"
ss -tlnp | head -20 | tee /tmp/lab-hardening/listen-after.txt
| Commande | Effet | Rollback |
|---|---|---|
systemctl disable --now UNIT |
Plus d’auto-start + stop maintenant | enable --now |
systemctl mask UNIT |
Symlink vers /dev/null |
unmask puis enable --now |
systemctl cat UNIT |
Voir le unit réel | — |
Interdits lab sans console : masquer ssh.service / sshd.service, stack réseau, systemd-logind. Si un service est requis par votre appli (docker, nginx), laissez-le et durcissez plutôt la config (nginx rate-limit).
Étape 5 — Sysctl léger (drop-in, pas un CIS kernel)
On pose quelques réglages réseau / info leak courants. Le deep-dive modules/sysctl Admin est un autre chapitre (linux-kernel-sysctl).
sudo tee /etc/sysctl.d/99-lab-hardening.conf >/dev/null << 'EOFSYS'
# Lab hardening baseline — VM jetable
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
EOFSYS
# Appliquer tous les drop-ins
sudo sysctl --system | tee /tmp/lab-hardening/sysctl-apply.txt
# Vérifier
sysctl net.ipv4.tcp_syncookies net.ipv4.conf.all.rp_filter kernel.kptr_restrict
Si une clé est refusée (conteneur / kernel custom), documentez et retirez-la : la baseline doit échouer doucement.
Étape 6 — Checklist de validation et rollback
cd /tmp/lab-hardening
{
echo "## Checklist hardening baseline"
echo "- unattended-upgrades / dnf-automatic : $(systemctl is-enabled unattended-upgrades 2>/dev/null || echo n/a)"
echo "- ssh listening :"
ss -tlnp | grep -E ':22|:2222' || echo "WARN: pas de :22 visible"
echo "- sysctl drop-in present : $(test -f /etc/sysctl.d/99-lab-hardening.conf && echo yes || echo no)"
echo "- sudoers.d count : $(ls /etc/sudoers.d 2>/dev/null | wc -l)"
} | tee CHECKLIST.txt
# Rollback sysctl lab
# sudo rm -f /etc/sysctl.d/99-lab-hardening.conf && sudo sysctl --system
# Rollback mask exemple
# sudo systemctl unmask avahi-daemon.service
# sudo systemctl enable --now avahi-daemon.service
# Rollback unattended drop-in
# sudo rm -f /etc/apt/apt.conf.d/52-lab-unattended
echo "Baseline lab OK si SSH toujours joignable + checklist remplie"
Validé si : inventaire archivé, updates auto configurés (ou note Rocky), au moins un service inutile traité ou justifié, sysctl drop-in appliqué (ou écart documenté), SSH/console toujours OK.
Erreurs fréquentes
| Symptôme | Cause | Correction |
|---|---|---|
| Plus d’accès SSH | mask sshd / firewall trop tôt |
Console ; unmask + enable --now ssh/sshd |
sysctl ignore une clé |
Conteneur, kernel sans option | Documenter ; retirer la ligne du drop-in |
| Reboots intempestifs | Automatic-Reboot true |
Remettre false ; planifier reboot manuel |
| Compte admin locké | passwd -l sur le mauvais user |
Console ; passwd -u |
| Service revient au boot | disable sans mask + dépendance |
Identifier systemctl list-dependencies ; mask si lab |
| Redo SSH AllowUsers ici | Confusion chapitres | SSH serveur = ssh hardening |
Quiz (3 questions)
1. Pourquoi préférer un drop-in sysctl.d plutôt que d’éditer /etc/sysctl.conf seul ?
– A. C’est plus lent
– B. Isolation lab / paquet : fichier dédié, rollback = supprimer le drop-in
– C. Ça désactive SSH
2. Différence clé disable vs mask ?
– A. Aucune
– B. mask empêche tout démarrage (symlink /dev/null) ; disable retire surtout l’auto-start
– C. mask installe des updates
3. Que faire avant de masquer un service réseau ou ssh ?
– A. Rien
– B. Ouvrir console/SSM, vérifier une session filet, avoir la commande unmask sous la main
– C. Supprimer unattended-upgrades
Réponses : 1‑B · 2‑B · 3‑B
FAQ
Faut-il appliquer un CIS Level 2 complet ?
Non ici : l’objectif est une baseline DevOps reproductible. CIS/Lynis = piste ultérieure.
unattended-upgrades remplace-t-il les backups ?
Non. Les patches réduisent les CVE connues ; backups rsync et tests de restore restent indispensables.
Où s’arrête ce tuto vs AppArmor / auditd ?
Ici : updates, comptes, services, sysctl léger. auditd = journalisation d’accès fichiers ; AppArmor = profils de confinement — chapitres dédiés.
Pour aller plus loin
man unattended-upgrade,man sysctl.d,man systemctl- Précédent lot 2 : auditd · suivant : nginx rate-limit
- Lot 1 rappel : SSH hardening · hub Linux Réseau & Sécurité
- Cross cloud : Security Groups ≠ baseline OS — les deux se complètent (AWS SG/NACL)
Maillage série Linux Réseau & Sécurité
| ← Précédent | Audit Linux : auditd |
| → Suivant | Pare-feu applicatif : nginx rate-limit |
| Hub | Linux Réseau & Sécurité |
| Lot 1 voisin | SSH hardening |
Meta publication (à remplir dans Rank Math / SEO)
- Title SEO : Hardening baseline Linux : updates, users, services (2026)
- Meta description (≤ 155) : Baseline hardening Linux : updates auto, comptes, services inutiles, sysctl léger. Suite lot 1 Sécurité — DevOps 2026.
- Focus keyphrase : hardening linux
- KW secondaires : unattended-upgrades, désactiver services, sysctl, baseline sécurité linux
- Schemas Rank Math : Article + HowTo (étapes lab) + FAQ (3 questions ci-dessus)
- Image mise en avant :
assets/web/devopelastichayway/cover-linux-hardening-baseline-1200x630.webp(Visuels Linux — WebP 1200×630) - Catégorie : Linux · Niveau : Intermédiaire+
- Slug :
linux-hardening-baseline - Statut : HOLD — draft only (ne pas publier)
← Retour parcours Linux — Basics, Admin, Réseau & Sécurité, Shell & Automation.