Sécuriser un Serveur Linux en 2026 : Checklist Complète

Meta description : Guide complet pour sécuriser un serveur Linux en 2026 : SSH, firewall, fail2ban, mises à jour automatiques, monitoring et bonnes pratiques de sécurité serveur. Mots-clés : sécuriser serveur linux, hardening linux 2026, sécurité VPS, configurer firewall linux, fail2ban configuration

Un serveur Linux mal sécurisé est une cible facile. En 2026, les attaques automatisées scannent des millions d'IP par heure à la recherche de failles. Ce guide vous donne une checklist complète et actionable pour protéger votre serveur — que ce soit un VPS, un dédié ou un Raspberry Pi.

Pourquoi la Sécurité Serveur Est Critique

Les chiffres qui font peur

Ce que vous risquez

Étape 1 : Sécuriser SSH (Priorité Absolue)

SSH est la porte d'entrée principale de votre serveur. Verrouillez-la.

Désactiver l'authentification par mot de passe

# Générer une clé SSH sur votre machine locale

ssh-keygen -t ed25519 -C "votre-email@example.com"



Copier la clé publique sur le serveur


ssh-copy-id -i ~/.ssh/id_ed25519.pub user@votre-serveur



Éditer la config SSH du serveur


sudo nano /etc/ssh/sshd_config

Modifiez ces lignes :

PasswordAuthentication no

PubkeyAuthentication yes


PermitRootLogin no


MaxAuthTries 3

# Redémarrer SSH

sudo systemctl restart sshd

Important : Testez la connexion par clé AVANT de désactiver les mots de passe !

Changer le port SSH

# Dans /etc/ssh/sshd_config

Port 2222  # ou un autre port > 1024

Ça ne bloque pas un attaquant déterminé, mais élimine 99% des scans automatiques.

Limiter les utilisateurs autorisés

# Dans /etc/ssh/sshd_config

AllowUsers votre-user

Étape 2 : Firewall (UFW)

Configuration de base

# Installer et configurer UFW

sudo apt install ufw



Politique par défaut : tout bloquer


sudo ufw default deny incoming


sudo ufw default allow outgoing



Autoriser SSH (sur votre port personnalisé)


sudo ufw allow 2222/tcp



Autoriser HTTP et HTTPS


sudo ufw allow 80/tcp


sudo ufw allow 443/tcp



Activer le firewall


sudo ufw enable



Vérifier les règles


sudo ufw status verbose

Règles avancées

# Limiter les connexions SSH (anti brute-force)

sudo ufw limit 2222/tcp



Autoriser un IP spécifique seulement


sudo ufw allow from 203.0.113.50 to any port 2222



Bloquer un IP malveillant


sudo ufw deny from 192.168.1.100

Étape 3 : Fail2ban (Anti Brute-Force)

Installation et configuration

sudo apt install fail2ban

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local


sudo nano /etc/fail2ban/jail.local

Configuration recommandée :

[DEFAULT]

bantime = 3600


findtime = 600


maxretry = 3


banaction = ufw



[sshd]


enabled = true


port = 2222


maxretry = 3


bantime = 86400



[nginx-http-auth]


enabled = true



[nginx-limit-req]


enabled = true

sudo systemctl enable fail2ban

sudo systemctl start fail2ban



Vérifier le statut


sudo fail2ban-client status sshd

Étape 4 : Mises à Jour Automatiques

Les mises à jour de sécurité doivent s'installer automatiquement.

sudo apt install unattended-upgrades

sudo dpkg-reconfigure -plow unattended-upgrades

Vérifiez la configuration :

sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

Assurez-vous que ces lignes sont actives :

"${distro_id}:${distro_codename}-security";

Unattended-Upgrade::Automatic-Reboot "true";


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

Étape 5 : Utilisateurs et Permissions

Créer un utilisateur dédié (ne jamais utiliser root)

# Créer l'utilisateur

sudo adduser deploy



Ajouter au groupe sudo


sudo usermod -aG sudo deploy



Configurer sudo sans mot de passe (optionnel, pour l'automatisation)


echo "deploy ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/deploy

Principe du moindre privilège

Étape 6 : Sécuriser Nginx

Headers de sécurité

# Dans votre bloc server nginx

add_header X-Frame-Options "SAMEORIGIN" always;


add_header X-Content-Type-Options "nosniff" always;


add_header X-XSS-Protection "1; mode=block" always;


add_header Referrer-Policy "strict-origin-when-cross-origin" always;


add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';" always;


add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Cacher la version Nginx

# Dans nginx.conf, bloc http

server_tokens off;

Rate limiting

# Dans nginx.conf, bloc http

limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;



Dans le bloc server/location


limit_req zone=api burst=20 nodelay;

SSL/TLS avec Let's Encrypt

sudo apt install certbot python3-certbot-nginx

sudo certbot --nginx -d votre-domaine.com


sudo certbot renew --dry-run  # Vérifier le renouvellement auto

Étape 7 : Monitoring et Alertes

Surveillance des logs

# Installer logwatch

sudo apt install logwatch



Rapport quotidien par email


sudo nano /etc/logwatch/conf/logwatch.conf


Output = mail


MailTo = votre-email@example.com


Detail = Med

Monitoring des ressources

# Installer et configurer un monitoring léger

sudo apt install htop iotop nethogs



Pour un monitoring plus complet, utilisez Netdata (gratuit)


bash <(curl -Ss https://my-netdata.io/kickstart.sh)

Vérification d'intégrité des fichiers

# Installer AIDE (Advanced Intrusion Detection Environment)

sudo apt install aide


sudo aide --init


sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db



Vérification quotidienne (ajouter en cron)


sudo aide --check

Étape 8 : Backups (Votre Filet de Sécurité)

Script de backup automatisé

#!/bin/bash

backup.sh — Sauvegarde quotidienne


DATE=$(date +%Y%m%d)


BACKUP_DIR="/backups"



Backup base de données


pg_dump -U postgres votre_db | gzip > "$BACKUP_DIR/db_$DATE.sql.gz"



Backup fichiers importants


tar czf "$BACKUP_DIR/files_$DATE.tar.gz" /var/www/ /etc/nginx/ /etc/ssh/



Supprimer les backups de plus de 30 jours


find "$BACKUP_DIR" -type f -mtime +30 -delete



Sync vers un stockage externe (optionnel)


rclone sync "$BACKUP_DIR" remote:backups/
# Cron : backup quotidien à 3h du matin

echo "0 3   * /root/scripts/backup.sh" | sudo crontab -

Règle 3-2-1 : 3 copies, 2 supports différents, 1 hors-site.

Étape 9 : Docker et Conteneurs

Si vous utilisez Docker, sécurisez-le aussi :

# Ne jamais exposer le socket Docker

Ne jamais lancer de conteneurs en root



Utiliser des images officielles et les scanner


docker scout cves votre-image:latest



Limiter les ressources par conteneur


docker run --memory=512m --cpus=1 votre-image



Réseau isolé par projet


docker network create --driver bridge app-network

Pour une configuration Docker complète et sécurisée, consultez notre DevOps Starter Kit.

Checklist Rapide de Sécurité

✅ SSH par clé uniquement (mot de passe désactivé)

✅ Root login désactivé


✅ Port SSH changé


✅ Firewall UFW activé


✅ Fail2ban configuré


✅ Mises à jour automatiques


✅ Utilisateur dédié (pas root)


✅ Nginx headers de sécurité


✅ SSL/TLS avec HSTS


✅ Rate limiting activé


✅ Logs surveillés


✅ Backups automatisés et testés


✅ Docker sécurisé (si applicable)

Audit Régulier

Planifiez un audit de sécurité mensuel :

  • Vérifiez les logs — Tentatives de connexion suspectes ?
  • Mettez à jour — sudo apt update && sudo apt upgrade
  • Scannez les ports — nmap -sV votre-ip (depuis l'extérieur)
  • Testez les backups — Restaurez un backup sur un serveur de test
  • Revoyez les accès — Qui a encore accès ? Nettoyez les comptes inutilisés
  • Vérifiez les CVE — Vos logiciels ont-ils des vulnérabilités connues ?

    • FAQ

    Mon VPS à 5 €/mois a-t-il besoin de tout ça ?

    Oui. Les attaquants ne distinguent pas les petits des gros serveurs. Un VPS compromis peut servir de relais pour des attaques plus importantes.

    Fail2ban ou firewall cloud (Cloudflare, etc.) ?

    Les deux. Fail2ban protège au niveau serveur, Cloudflare au niveau DNS/CDN. Ce sont des couches complémentaires.

    Combien de temps pour sécuriser un serveur ?

    2-3 heures pour la configuration initiale avec ce guide. 30 minutes par mois pour la maintenance.

    Je ne suis pas expert sécurité, est-ce suffisant ?

    Ce guide couvre 90% des attaques automatisées. Pour une sécurité enterprise (PCI-DSS, SOC2), faites appel à un professionnel.

    Conclusion

    La sécurité serveur n'est pas optionnelle — c'est la base. Suivez cette checklist, automatisez ce qui peut l'être, et faites un audit mensuel. Votre serveur ne sera jamais impénétrable, mais il sera suffisamment durci pour décourager la grande majorité des attaquants.

    Besoin d'une infrastructure pré-configurée et sécurisée ? Découvrez notre DevOps Starter Kit avec Docker, CI/CD et monitoring inclus.

    Approfondissez vos compétences sysadmin avec les formations réseaux et DevOps de NetRevision.