Sécuriser son serveur Linux : les 10 commandements

En résumé : Au 5 septembre 2026, sécurisez d’abord l’accès SSH par clés, refusez la connexion root, n’exposez que les ports nécessaires, automatisez les correctifs de sécurité et testez une sauvegarde hors du serveur. Ma recommandation est nette : ne mettez pas un service en production tant que ces cinq contrôles ne sont pas vérifiés et qu’une alerte exploitable n’est pas configurée.

Cette checklist détaillée sert de plan d’action opérationnel pour un serveur Debian ou Ubuntu. Elle complète un guide de durcissement général en montrant les commandes, les contrôles et les points à adapter avant une mise en production.

1. Comment sécuriser l’authentification SSH par clés ?

SSH est généralement l’accès d’administration à distance de votre serveur. Une première mesure consiste à désactiver les mots de passe après avoir validé l’authentification par clé.

# Générer une paire de clés Ed25519
ssh-keygen -t ed25519 -C "[email protected]"

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

Ensuite, modifiez /etc/ssh/sshd_config :

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

La documentation officielle d’OpenSSH décrit ces directives. Avant de couper les mots de passe, ouvrez une seconde session et vérifiez que votre clé fonctionne afin de ne pas perdre l’accès au serveur.

2. Faut-il changer le port SSH par défaut ?

Le port 22 reçoit souvent des scans automatisés. Déplacer SSH vers un port non standard peut réduire le bruit dans les journaux, sans constituer une protection en soi.

# /etc/ssh/sshd_config
Port 2222

Cette mesure ne bloque pas un attaquant qui découvre le nouveau port. Considérez-la uniquement comme un moyen de réduire le bruit automatisé, en complément des contrôles réels.

3. Pourquoi désactiver la connexion root ?

Le compte root dispose de tous les privilèges et son nom est prévisible. Désactivez sa connexion SSH directe :

# /etc/ssh/sshd_config
PermitRootLogin no

Utilisez un utilisateur dédié avec des droits sudo pour les opérations d’administration :

# Créer un utilisateur dédié
adduser admin
usermod -aG sudo admin

4. Comment limiter les ports avec UFW ?

Un pare-feu hôte est indispensable lorsque le serveur est exposé. Sur Ubuntu, UFW fournit une interface simple pour configurer le filtrage réseau :

# Politique par défaut : tout bloquer en entrée
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Autoriser uniquement les ports nécessaires
sudo ufw allow 2222/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Activer le firewall
sudo ufw enable
sudo ufw status verbose

La règle d’or : autorisez uniquement ce dont vous avez besoin explicitement. Tout le reste doit être bloqué.

5. Comment bloquer les tentatives répétées avec Fail2Ban ?

Fail2Ban surveille les logs de connexion et bannit automatiquement les adresses IP qui multiplient les tentatives échouées :

sudo apt install fail2ban -y

Créez une configuration locale dans /etc/fail2ban/jail.local :

[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 3

[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3

Ces valeurs sont un exemple, pas des réglages universels. Adaptez le port, le backend et la source des journaux à votre distribution, puis testez la configuration avant de compter sur les bannissements.

Relancez le service et vérifiez les bans actifs :

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

6. Comment maintenir les correctifs de sécurité à jour ?

Les mises à jour de sécurité réduisent l’exposition aux vulnérabilités déjà corrigées. Sur Debian ou Ubuntu :

# Mise à jour manuelle
sudo apt update && sudo apt upgrade -y

# Configuration des mises à jour automatiques de sécurité
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades

Sur Debian, vérifiez la configuration et les journaux de unattended-upgrades : le paquet peut être absent ou désactivé, et certaines mises à jour peuvent nécessiter un redémarrage de services ou du serveur.

7. Comment préparer des sauvegardes restaurables ?

Aucune stratégie de sécurité n’est complète sans sauvegarde restaurable. Conservez plusieurs copies sur des supports distincts, dont une hors du serveur et inaccessible avec les mêmes identifiants.

Pour un serveur web typique, un script de sauvegarde automatisé peut ressembler à :

#!/bin/bash
# backup.sh - Sauvegarde quotidienne
BACKUP_DIR="/backup/$(date +%Y-%m-%d)"
mkdir -p "$BACKUP_DIR"

# Sauvegarde des fichiers du site
tar -czf "$BACKUP_DIR/site.tar.gz" /var/www/

# Sauvegarde de la base de données
mysqldump --all-databases | gzip > "$BACKUP_DIR/databases.sql.gz"

# Rotation : garder les 30 derniers jours
find /backup -type d -mtime +30 -exec rm -rf {} +

# Synchronisation vers un stockage distant
rsync -avz /backup/ user@backup-server:/backups/

Planifiez l’exécution, surveillez ses erreurs et testez régulièrement une restauration. Une archive dont la restauration n’a jamais été vérifiée ne constitue pas un plan de reprise fiable.

8. Comment détecter une anomalie sur le serveur ?

La surveillance sert à détecter rapidement une panne ou un comportement inhabituel. Commencez par des contrôles simples :

Pour le système :

# Surveiller les ressources en temps réel
htop

# Analyser l'espace disque
df -h

# Vérifier les processus actifs
ps aux --sort=-%mem | head -20

Pour les logs de sécurité :

# Dernières tentatives de connexion échouées
sudo grep "Failed password" /var/log/auth.log | tail -20

# Utilisateurs actuellement connectés
who
last

Pour une surveillance continue, choisissez un outil capable d’envoyer une alerte vers un canal réellement suivi. Prometheus et Grafana conviennent à une pile autohébergée ; UptimeRobot ou Sentry répondent à d’autres besoins. L’outil importe moins que la qualité des seuils, des destinataires et des procédures de réponse.

9. Comment appliquer le moindre privilège aux fichiers ?

Les mauvaises permissions de fichiers sont une porte ouverte aux attaquants. Appliquez le principe du moindre privilège :

# Permissions pour les fichiers de configuration SSH
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

# Permissions pour les fichiers web
sudo chown -R www-data:www-data /var/www/
sudo find /var/www/ -type d -exec chmod 755 {} \;
sudo find /var/www/ -type f -exec chmod 644 {} \;

# Restreindre l'accès aux fichiers sensibles
chmod 600 /etc/shadow
chmod 644 /etc/passwd

10. Quels services et ports faut-il fermer ?

Chaque service actif peut ajouter des composants à maintenir ou un port à protéger. Inventoriez ce qui fonctionne réellement et désactivez uniquement ce dont votre serveur n’a pas besoin :

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

# Désactiver un service inutile
sudo systemctl disable --now bluetooth
sudo systemctl disable --now avahi-daemon

Vérifiez également les ports ouverts :

sudo ss -tlnp

Conclusion

Cette checklist vise la mise en production et l’exploitation quotidienne : accès administrateur, filtrage, correctifs, sauvegardes et alertes. Elle ne remplace pas un audit de l’application, du fournisseur cloud, des secrets, des conteneurs ou des obligations réglementaires.

Si personne ne peut expliquer qui reçoit une alerte, comment restaurer les données et quand les correctifs sont appliqués, le serveur n’est pas prêt. Traitez ces points avant l’incident ; faites-vous accompagner lorsque l’impact métier dépasse votre capacité à tester seul.

Sources

• Manuel officiel de configuration du serveur OpenSSH, consulté le 5 septembre 2026.
• Documentation Ubuntu sur les pare-feu et UFW, consultée le 5 septembre 2026.
• Documentation Debian sur les mises à jour périodiques, consultée le 5 septembre 2026.
• Manuel Debian de fail2ban-client, consulté le 5 septembre 2026.
• Guide NIST de planification de la continuité, consulté le 5 septembre 2026.
• Manuel officiel de systemctl, consulté le 5 septembre 2026.