Je vais être honnête. La plupart des guides de hardening Linux partent en vrille au bout de 12 lignes. Ils te balancent 40 acronymes, 15 outils, 3 frameworks, et à la fin tu as surtout durci… ton envie de le faire.
Là, on va faire l’inverse. Une checklist courte, réaliste, et surtout applicable en 2026, sur des serveurs et des VM qui doivent juste tourner. Et si tu es comme moi, tu veux pouvoir revenir dans 6 mois, relire, et te dire : « ok, je sais ce que j’ai fait et pourquoi ».
Petite note : je parle surtout Linux serveur (Debian, Ubuntu, RHEL like). Mais la logique marche aussi sur un poste.
Objectif : réduire l’exposition, limiter l’impact si ça casse, et rendre l’attaque plus chère. Sans transformer ta machine en bunker ingérable.
0. règle de base avant tout : savoir ce qu’on protège
Avant iptables, avant SELinux, avant « zéro trust », il y a deux questions simples.
- Ce serveur fait quoi, exactement ?
- Et qui doit y accéder ?
Écris ça dans un coin, littéralement. Un petit fichier /root/README-hardening.txt suffit.
Exemple :
- Rôle : reverse proxy + app Node
- Accès admin : moi + CI (clé SSH)
- Exposition : 80/443 public, 22 via VPN uniquement
- Données : logs + secrets via vault
C’est bête, mais ça évite le hardening « au hasard ».
1. mises à jour : la sécurité la moins sexy et la plus rentable
En 2026, la majorité des compromissions « simples » viennent encore de là. Un service exposé, une CVE connue, pas patché.
ce que je fais (minimal mais sérieux)
- Activer les mises à jour de sécurité automatiques.
- Garder un cycle de reboot maîtrisé (pas tous les jours, mais pas tous les 9 mois non plus).
- Avoir un inventaire des paquets critiques.
Sur Debian ou Ubuntu :
bash apt update apt install unattended-upgrades apt-listchanges dpkg-reconfigure unattended-upgrades
Sur RHEL like, regarde dnf-automatic.
Et surtout, checke que ça tourne vraiment :
bash systemctl status unattended-upgrades grep -i upgraded /var/log/unattended-upgrades/unattended-upgrades.log | tail
Mini règle perso : si c’est exposé internet, patch de sécurité sous 72 heures max. Sinon tu joues à la loterie.
2. comptes et mots de passe : moins de portes, meilleures serrures
2.1 supprimer les habitudes dangereuses
- Désactiver le login SSH root.
- Interdire l’auth par mot de passe sur SSH si possible.
- Supprimer les comptes inutiles, verrouiller ceux qui doivent exister.
Dans /etc/ssh/sshd_config :
text PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes
Puis :
bash sshd -t && systemctl reload ssh
2.2 sudo propre, pas freestyle
- Pas de
NOPASSWDpour « gagner du temps », sauf cas ultra justifié. - Un groupe
sudoou une règle minimale.
Et si tu as besoin d’un accès « break glass » (incident) : fais le proprement, documenté, avec une procédure.
3. SSH : le premier mur, facile à rendre solide
Tu peux durcir SSH en 10 minutes sans te tirer une balle.
checklist SSH rapide
- Port 22 : tu peux le laisser si filtré réseau, sinon tu peux changer. Ce n’est pas une sécurité en soi, mais ça réduit le bruit.
AllowUsersouAllowGroupspour limiter.- Désactiver les algos archaïques (selon distro, c’est déjà le cas).
Exemple :
text AllowGroups sshadmins MaxAuthTries 3 LoginGraceTime 20 ClientAliveInterval 300 ClientAliveCountMax 2
Et surtout : fail2ban ou équivalent, si SSH est exposé.
bash apt install fail2ban systemctl enable --now fail2ban
4. firewall : autoriser le strict nécessaire, point
Je vois encore trop de serveurs avec « ça écoute partout » et « on verra plus tard ».
Choisis ton outil : ufw, firewalld, nftables direct. Peu importe. Le principe compte.
exemple simple avec ufw (Debian ou Ubuntu)
bash apt install ufw ufw default deny incoming ufw default allow outgoing
ufw allow 80/tcp ufw allow 443/tcp ufw allow from 10.0.0.0/24 to any port 22 proto tcp
ufw enable ufw status verbose
Règle mentalité : pas d’ouverture « temporaire ». Si c’est temporaire, tu oublies. Donc soit c’est justifié, soit non.
5. services : couper ce qui ne sert pas, et vérifier ce qui sert
Le hardening le plus propre, c’est de ne pas avoir le service, du tout.
5.1 faire l’inventaire des ports
bash ss -tulpn
Tu listes, tu identifies, tu justifies. Tout port inconnu, c’est une alarme.
5.2 systemd : désactiver clairement
bash systemctl disable --now avahi-daemon 2>/dev/null systemctl disable --now cups 2>/dev/null
Je caricature, mais tu vois l’idée.
5.3 isoler les services
Quand c’est possible, conteneurise. Sinon, utilise les options systemd pour réduire la surface.
Exemple d’options utiles dans un override systemd :
NoNewPrivileges=truePrivateTmp=trueProtectSystem=strictProtectHome=true(selon besoin)RestrictAddressFamilies=…
Ça peut casser, oui. Donc tu appliques sur les services les plus exposés d’abord (reverse proxy, API, etc).
6. permissions et fichiers sensibles : arrêter l’hémorragie silencieuse
En incident, ce qui fait mal, c’est souvent l’accès aux secrets.
6.1 secrets : un minimum syndical
- Pas de secrets en clair dans un repo git.
- Pas de secrets dans l’historique bash (évite de taper des tokens en ligne).
- Droits stricts sur
.env, clés privées, configs.
Exemples :
bash chmod 600 /etc/ssh/ssh_host_*_key chmod 600 /opt/app/.env chown root:root /opt/app/.env
6.2 umask raisonnable
Pour des serveurs, un umask 027 est déjà un bon garde fou. À adapter selon ton contexte.
7. logs et audit : sans visibilité, tu sécurises à l’aveugle
Je sais, personne n’aime lire des logs. Mais tu veux au moins pouvoir répondre à : « qu’est-ce qui s’est passé ? »
7.1 journald et rotation
Vérifie que tu ne perds pas tout au reboot, si tu en as besoin.
Dans /etc/systemd/journald.conf :
Storage=persistent- limites raisonnables (
SystemMaxUse=…)
7.2 logs minimum à surveiller
- Auth SSH :
/var/log/auth.log(Debian) oujournalctl -u ssh - sudo
- accès web (nginx, apache)
- changements de services systemd
7.3 auditd (optionnel mais utile)
Si tu veux un cran au dessus sans faire un SOC.
bash apt install auditd systemctl enable --now auditd
Tu mets 2 ou 3 règles simples (ex : surveiller /etc/passwd, /etc/ssh/sshd_config, /etc/sudoers), et déjà tu gagnes.
8. sauvegardes : ton vrai plan de reprise, pas juste un dossier
Un serveur durci qui ne peut pas être restauré vite, c’est fragile. Parce que l’incident arrive toujours à 2 h du matin.
Checklist minimaliste backup :
- 3 copies
- 2 supports différents
- 1 hors site (ou objet S3 compatible)
- tests de restauration, vraiment
Et chiffre ce qui sort de la machine.
Astuce simple : si tu fais du rsync vers un autre serveur, utilise SSH avec clé dédiée, sans shell, et permissions minimales.
9. chiffrement : à appliquer là où ça a du sens
9.1 disque
Sur des VM cloud, le chiffrement disque est souvent fourni par la plateforme. Sur du bare metal ou du VPS plus artisanal, LUKS reste la base, mais attention à la gestion des clés et au reboot sans console.
9.2 trafic
- TLS partout où ça parle.
- Certbot ou ACME automatique si web.
- Désactiver les vieux protocoles côté serveur si tu exposes du TLS.
Et si tu termines TLS sur un reverse proxy, assure toi que l’interne n’est pas en clair sur un réseau hostile.
10. kernel et sysctl : quelques réglages qui ne cassent pas tout
On évite la liste de 80 paramètres copiée collée.
Quelques basiques qui passent bien dans beaucoup de contextes (à tester) :
Dans /etc/sysctl.d/99-hardening.conf :
text net.ipv4.icmp_echo_ignore_broadcasts = 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.ipv4.conf.default.send_redirects = 0 kernel.kptr_restrict = 2 kernel.dmesg_restrict = 1 fs.protected_hardlinks = 1 fs.protected_symlinks = 1
Puis :
bash sysctl --system
Ce n’est pas magique. Mais c’est un bon « socle ».
11. confinement : apparmor ou selinux, sans se raconter d’histoires
En 2026, ça vaut toujours le coup. Mais seulement si tu l’assumes.
- Ubuntu et Debian : AppArmor est souvent plus simple à vivre.
- RHEL, Fedora : SELinux est mature, puissant, mais demande une discipline.
Approche minimaliste :
- activer
- mettre en mode enforce
- corriger les blocages réels, pas tout désactiver à la première alerte
Si tu n’as pas le temps maintenant, ok. Mais note le comme dette technique, pas comme « plus tard » flou.
12. durcir la chaîne de déploiement : parce que l’attaque vient souvent de là
On parle beaucoup du serveur, pas assez de comment on y déploie.
Checklist rapide :
- CI avec secrets stockés correctement (vault, secret manager).
- clé SSH de déploiement dédiée, limitée.
- pas de connexion SSH interactive depuis un laptop random en wifi public.
- journaux de déploiement consultables.
Et si tu fais du Docker :
- images minimales (distroless ou alpine quand c’est adapté)
- scan d’image (même basique)
- pas de
:latesten prod
13. petite checklist « en 30 minutes » si tu es pressé
Si tu dois faire le strict minimum aujourd’hui :
- mises à jour auto de sécurité
- SSH : root off, password off, allowlist users
- firewall deny par défaut, ouvrir seulement ce qui doit l’être
- inventaire ports avec
ss -tulpn - fail2ban si SSH exposé
- backups testés
- logs persistants (journald)
C’est déjà énorme.
14. la routine mensuelle (la partie qui change tout)
Ce qui marche, ce n’est pas un hardening « one shot ». C’est la routine.
Une fois par mois :
- vérifier les services actifs
- vérifier les ports ouverts
- vérifier les comptes et clés SSH
- relire les logs d’auth rapidement
- tester une restauration de sauvegarde (même partielle)
- appliquer les updates, planifier reboot si kernel
Tu peux en faire une page checklist dans Notion, Obsidian, ou… un bête fichier markdown dans ton repo infra.
15. un mot sur mon blog, et pourquoi j’insiste sur le minimalisme
Sur Le Blog Tech Pro de Samyn-Antoy ABASSE (https://monblog-sa-abasse.blogspot.com), je partage souvent ce genre de trucs « pratiques d’abord ». Pas parce que c’est plus cool. Juste parce que c’est ce qui se fait vraiment quand tu gères plusieurs projets, de la prod, et un peu de growth à côté.
Si tu veux, tu peux aussi aller voir les pages « Mes services » et le portfolio. Je mets à jour des méthodes de travail, des ressources, et des checklists justement pensées pour être réutilisées sans douleur.
conclusion : durcir, c’est surtout décider
Le hardening minimaliste, c’est une série de décisions claires : qui a accès, à quoi, par où. Puis tu retires le reste.
Et le truc un peu contre intuitif, c’est que tu n’as pas besoin d’être parfait. Tu as besoin d’être cohérent, et régulier.
Si tu ne devais retenir qu’une ligne : réduis la surface, limite l’impact, garde de la visibilité. Le reste, tu l’empiles au fil de l’eau. Pas dans la panique. Pas dans la honte. Juste, proprement.
Questions fréquemment posées
Quel est l'objectif principal du hardening Linux selon ce guide ?
L'objectif principal est de réduire l'exposition des serveurs, limiter l'impact en cas de problème, et rendre une attaque plus coûteuse sans transformer la machine en bunker ingérable.
Pourquoi est-il important de savoir ce que l'on protège avant de commencer le hardening ?
Avant d'appliquer des mesures comme iptables ou SELinux, il faut définir précisément le rôle du serveur et qui doit y accéder. Cela évite un durcissement au hasard et permet d'adapter les protections à la réalité du service.
Quelles sont les bonnes pratiques recommandées pour la gestion des mises à jour de sécurité ?
Activer les mises à jour automatiques de sécurité, garder un cycle de reboot maîtrisé, avoir un inventaire des paquets critiques, et appliquer les correctifs sous 72 heures maximum si le service est exposé à Internet.
Comment durcir les comptes utilisateurs et mots de passe sur un serveur Linux ?
Supprimer les habitudes dangereuses comme le login SSH root ou l'authentification par mot de passe sur SSH, supprimer ou verrouiller les comptes inutiles, utiliser une configuration sudo stricte sans NOPASSWD sauf cas justifié.
Quelles recommandations pour sécuriser SSH efficacement ?
Limiter l'accès via AllowUsers ou AllowGroups, désactiver les algorithmes obsolètes, configurer MaxAuthTries et LoginGraceTime pour limiter les tentatives, utiliser fail2ban ou équivalent pour bloquer les attaques répétées.
Comment configurer un firewall simple mais efficace sur Linux ?
Choisir un outil comme ufw, firewalld ou nftables, refuser tout trafic entrant par défaut, autoriser uniquement le strict nécessaire (exemple : ports 80/443 TCP pour HTTP/HTTPS et port 22 TCP depuis une plage IP interne), afin d'éviter que le serveur écoute partout.
0 Commentaires