Sécurité Linux : Durcir un Serveur en Production

Un serveur Linux exposé sur Internet reçoit ses premières tentatives d’intrusion dans les minutes qui suivent sa mise en ligne : scans de ports, essais de mots de passe SSH, exploitation de services mal configurés. La bonne nouvelle, c’est qu’une poignée de mesures simples élimine l’immense majorité de ces attaques opportunistes. Dans ce guide, nous durcissons un serveur étape par étape : SSH, pare-feu, fail2ban, mises à jour automatiques, permissions, audit et surveillance des ports. Chaque section contient les commandes exactes, testées sur Debian/Ubuntu et Rocky Linux/Fedora. Une checklist récapitulative clôt l’article.

1. Durcissement SSH

SSH est la porte d’entrée principale de votre serveur, et donc la cible numéro un. Trois mesures s’imposent : l’authentification par clés, la désactivation de la connexion root et la désactivation des mots de passe.

Authentification par clés

# Sur votre machine locale : générer une paire de clés ed25519
ssh-keygen -t ed25519 -C "admin@poste-travail"

# Copier la clé publique sur le serveur
ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@serveur.exemple.com

# Vérifier la connexion par clé AVANT de désactiver les mots de passe
ssh -i ~/.ssh/id_ed25519 admin@serveur.exemple.com

Configuration du démon SSH

Éditez /etc/ssh/sshd_config (ou mieux, créez un fichier dans /etc/ssh/sshd_config.d/) :

# /etc/ssh/sshd_config.d/10-durcissement.conf

# Interdire la connexion directe en root
PermitRootLogin no

# Désactiver l'authentification par mot de passe : clés uniquement
PasswordAuthentication no
KbdInteractiveAuthentication no

# Limiter les utilisateurs autorisés à se connecter
AllowUsers admin deploy

# Réduire la fenêtre d'authentification et les tentatives
LoginGraceTime 30
MaxAuthTries 3

# Déconnecter les sessions inactives après 15 minutes
ClientAliveInterval 300
ClientAliveCountMax 3

# Valider la syntaxe avant de recharger : une erreur peut vous enfermer dehors
sudo sshd -t

# Recharger la configuration
sudo systemctl reload ssh     # Debian/Ubuntu
sudo systemctl reload sshd    # Rocky/Fedora

Gardez toujours une session SSH ouverte pendant que vous testez la nouvelle configuration dans un second terminal. Si la nouvelle session échoue, vous pouvez corriger depuis la première.

Changer le port : utile mais pas suffisant

Déplacer SSH du port 22 vers un port non standard ne protège pas contre un attaquant ciblé, mais réduit drastiquement le bruit des scans automatiques dans vos logs.

# Dans /etc/ssh/sshd_config.d/10-durcissement.conf
Port 2222

N’oubliez pas d’ouvrir ce port dans le pare-feu avant de recharger SSH, et de le préciser ensuite à la connexion : ssh -p 2222 admin@serveur.

2. Pare-feu : ufw et firewalld

Le principe : tout bloquer en entrée par défaut, puis ouvrir uniquement les ports nécessaires.

ufw (Debian/Ubuntu)

# Installer et définir les politiques par défaut
sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing

# IMPÉRATIF : autoriser SSH avant d'activer le pare-feu
sudo ufw allow 2222/tcp comment 'SSH'

# Ouvrir les ports web
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'

# Restreindre un port à une adresse IP source (ex. base de données)
sudo ufw allow from 10.0.0.5 to any port 5432 proto tcp

# Activer le pare-feu
sudo ufw enable

# Vérifier les règles avec leurs numéros
sudo ufw status numbered

# Supprimer une règle par son numéro
sudo ufw delete 3

firewalld (Rocky Linux/Fedora)

# Vérifier que firewalld est actif
sudo systemctl enable --now firewalld

# Lister la configuration de la zone active
sudo firewall-cmd --list-all

# Ouvrir des services de façon permanente
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https

# Ouvrir un port personnalisé
sudo firewall-cmd --permanent --add-port=2222/tcp

# Retirer un service ouvert par défaut si inutile
sudo firewall-cmd --permanent --remove-service=cockpit

# Appliquer les changements permanents
sudo firewall-cmd --reload

3. fail2ban : Bannir les Attaquants

fail2ban lit les journaux, détecte les tentatives d’authentification répétées et bannit l’adresse IP fautive via le pare-feu.

# Installation
sudo apt install fail2ban          # Debian/Ubuntu
sudo dnf install fail2ban          # Rocky/Fedora

Ne modifiez jamais jail.conf : créez jail.local qui le surcharge.

# /etc/fail2ban/jail.local
[DEFAULT]
# Bannir 1 heure après 5 échecs en 10 minutes
bantime  = 1h
findtime = 10m
maxretry = 5
# Ne jamais bannir vos propres adresses
ignoreip = 127.0.0.1/8 ::1 203.0.113.10

[sshd]
enabled = true
port    = 2222

# Activer et vérifier
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

# Débannir une adresse par erreur
sudo fail2ban-client set sshd unbanip 198.51.100.7

# Durcissement progressif : doubler la durée à chaque récidive
# (à ajouter dans [DEFAULT] de jail.local)
# bantime.increment = true
# bantime.maxtime   = 1w

4. Mises à Jour Automatiques

La plupart des compromissions exploitent des vulnérabilités déjà corrigées. Automatisez au minimum les mises à jour de sécurité.

Debian/Ubuntu : unattended-upgrades

# Installation et activation
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

# Vérifier la configuration
cat /etc/apt/apt.conf.d/20auto-upgrades
# APT::Periodic::Update-Package-Lists "1";
# APT::Periodic::Unattended-Upgrade "1";

# Tester en simulation
sudo unattended-upgrade --dry-run --debug

Dans /etc/apt/apt.conf.d/50unattended-upgrades, vous pouvez activer le redémarrage automatique en heures creuses :

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

Rocky/Fedora : dnf-automatic

sudo dnf install dnf-automatic

# Dans /etc/dnf/automatic.conf : appliquer uniquement la sécurité
# upgrade_type = security
# apply_updates = yes

sudo systemctl enable --now dnf-automatic.timer

5. Permissions et umask

Vérifier les fichiers sensibles

# Les fichiers de mots de passe doivent être strictement protégés
ls -l /etc/shadow
# Attendu : -rw-r----- root shadow (640) ou plus restrictif

# Trouver les fichiers world-writable (dangereux)
sudo find / -xdev -type f -perm -0002 -not -path "/proc/*" 2>/dev/null

# Trouver les binaires setuid (à auditer régulièrement)
sudo find / -xdev -type f -perm -4000 2>/dev/null

# Les clés SSH privées doivent être en 600
chmod 600 ~/.ssh/id_ed25519
chmod 700 ~/.ssh

umask : les permissions par défaut

Le umask détermine les permissions retirées aux nouveaux fichiers. Avec un umask de 022, un fichier est créé en 644 ; avec 027, en 640 (aucun accès pour « les autres »).

# Vérifier le umask courant
umask

# Durcir pour les nouveaux fichiers : ajouter dans /etc/profile.d/umask.sh
echo "umask 027" | sudo tee /etc/profile.d/umask.sh

umask	Fichier créé	Répertoire créé	Usage
022	644 (rw-r—r—)	755 (rwxr-xr-x)	Valeur par défaut classique
027	640 (rw-r-----)	750 (rwxr-x---)	Serveur durci recommandé
077	600 (rw-------)	700 (rwx------)	Données strictement privées

6. auditd : Tracer les Actions Sensibles

auditd enregistre les événements système au niveau du noyau : accès à des fichiers critiques, appels système, exécutions de commandes.

# Installation
sudo apt install auditd audispd-plugins   # Debian/Ubuntu
sudo dnf install audit                     # Rocky/Fedora
sudo systemctl enable --now auditd

Règles utiles dans /etc/audit/rules.d/durcissement.rules :

# Surveiller toute modification des comptes et de sudo
-w /etc/passwd -p wa -k comptes
-w /etc/shadow -p wa -k comptes
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers

# Surveiller la configuration SSH
-w /etc/ssh/sshd_config -p wa -k sshd

# Tracer les commandes exécutées en root (architecture 64 bits)
-a always,exit -F arch=b64 -F euid=0 -S execve -k commandes_root

# Charger les règles et vérifier
sudo augenrules --load
sudo auditctl -l

# Rechercher les événements par clé
sudo ausearch -k sudoers --start today

# Rapport résumé des authentifications
sudo aureport -au --summary

7. Surveillance des Ports : ss et nmap

Vue interne avec ss

# Tous les ports TCP et UDP en écoute, avec le processus associé
sudo ss -tulpn

# Uniquement les ports TCP en écoute
sudo ss -tlnp

# Connexions établies vers l'extérieur
ss -tn state established

Chaque ligne de ss -tulpn doit correspondre à un service que vous connaissez et que vous avez volontairement installé. Un port en écoute inconnu mérite une investigation immédiate.

Vue externe avec nmap

Scannez votre serveur depuis une autre machine pour voir ce qu’un attaquant voit réellement :

# Scan des 1000 ports TCP les plus courants
nmap serveur.exemple.com

# Scan complet de tous les ports TCP avec détection de version
nmap -p- -sV serveur.exemple.com

# Scan UDP des ports courants (lent, nécessite root)
sudo nmap -sU --top-ports 50 serveur.exemple.com

Ne scannez que des machines qui vous appartiennent ou pour lesquelles vous avez une autorisation écrite.

Désactiver les services inutiles

# Lister les services actifs
systemctl list-units --type=service --state=running

# Désactiver et arrêter un service superflu
sudo systemctl disable --now cups

8. Le Principe du Moindre Privilège

Chaque processus, utilisateur et service doit disposer uniquement des droits strictement nécessaires à sa fonction.

# Créer un utilisateur système sans shell pour un service applicatif
sudo useradd --system --no-create-home --shell /usr/sbin/nologin monapp

# Limiter sudo à une commande précise plutôt que ALL
# Dans /etc/sudoers.d/deploy (via visudo -f) :
# deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart monapp

Au niveau systemd, sandboxez vos services dans leur fichier d’unité :

# Extrait de /etc/systemd/system/monapp.service
[Service]
User=monapp
# Interdire l'acquisition de nouveaux privilèges
NoNewPrivileges=true
# Système de fichiers en lecture seule sauf exceptions
ProtectSystem=strict
ReadWritePaths=/var/lib/monapp
# /home inaccessible
ProtectHome=true
# /tmp privé
PrivateTmp=true

# Mesurer l'exposition d'un service (score de 0 à 10, plus bas = mieux)
systemd-analyze security monapp.service

Enfin, laissez SELinux (Rocky/Fedora) ou AppArmor (Debian/Ubuntu) activés : ils confinent les services compromis.

# Vérifier l'état de SELinux
getenforce
# Attendu : Enforcing

# Vérifier l'état d'AppArmor
sudo aa-status

9. Checklist de Durcissement

Mesure	Commande de vérification	État attendu
SSH par clés uniquement	sudo sshd -T | grep passwordauthentication	passwordauthentication no
Connexion root interdite	sudo sshd -T | grep permitrootlogin	permitrootlogin no
Pare-feu actif	sudo ufw status ou sudo firewall-cmd --state	active / running
Entrées bloquées par défaut	sudo ufw status verbose	deny (incoming)
fail2ban en service	sudo fail2ban-client status sshd	jail sshd active
Mises à jour de sécurité auto	systemctl status unattended-upgrades ou dnf-automatic.timer	actif
Aucun port inattendu	sudo ss -tulpn	uniquement les services connus
Aucun fichier world-writable	find / -xdev -type f -perm -0002	liste vide
umask durci	umask	0027
auditd en fonctionnement	sudo auditctl -l	règles chargées
SELinux/AppArmor actif	getenforce / aa-status	Enforcing / profils chargés
Services superflus désactivés	systemctl list-units --type=service --state=running	liste minimale

Bonnes pratiques

• Testez chaque changement SSH dans une seconde session avant de fermer la première : c’est votre filet de sécurité contre l’auto-enfermement.
• Ouvrez le port SSH dans le pare-feu avant d’activer ce dernier, jamais après.
• Ajoutez vos adresses IP d’administration dans ignoreip de fail2ban pour ne jamais vous bannir vous-même.
• Ne désactivez jamais SELinux ou AppArmor pour « résoudre » un problème : corrigez la politique à la place.
• Auditez les ports en écoute (ss -tulpn) après chaque installation de logiciel.
• Rejouez la checklist complète après chaque mise à niveau majeure du système.
• Externalisez vos journaux vers un serveur distant : un attaquant qui obtient root efface les traces locales.
• La sécurité est un processus, pas un état : planifiez une revue trimestrielle de cette checklist.

Conclusion

Durcir un serveur Linux ne demande ni outils exotiques ni budget : SSH restreint aux clés, un pare-feu en liste blanche, fail2ban, des mises à jour automatiques, des permissions strictes, auditd et une revue régulière des ports suffisent à écarter la quasi-totalité des attaques opportunistes qui balayent Internet en permanence. Le fil conducteur de toutes ces mesures est le principe du moindre privilège : chaque accès qui n’est pas indispensable est un accès à supprimer.

Appliquez la checklist de la section 9 sur chacun de vos serveurs, automatisez-la dans vos scripts de provisionnement, et vous partirez d’une base saine que les mesures avancées (SELinux affiné, journalisation centralisée, détection d’intrusion) viendront renforcer par la suite.