Durcissement de serveurs Linux : guide pratique

Avoir un serveur exposé à Internet sans une configuration de sécurité minimale, c’est laisser la porte entrouverte. Dans cet article, je rassemble les étapes que j’applique sur mes propres serveurs pour réduire la surface d’attaque sans compliquer la gestion du quotidien.

SSH : la première ligne de défense

#

Le service SSH est le point d’entrée le plus attaqué sur tout serveur Linux. Voici les réglages les plus importants dans /etc/ssh/sshd_config :

# Deshabilitar acceso root
PermitRootLogin no

# Solo autenticación por clave pública
PasswordAuthentication no
ChallengeResponseAuthentication no

# Limitar intentos de autenticación
MaxAuthTries 3

# Desactivar forwarding innecesario
X11Forwarding no
AllowTcpForwarding no

Après chaque modification :

sudo systemctl reload ssh   # Ubuntu/Debian
sudo systemctl reload sshd  # CentOS/RHEL

Pourquoi PermitRootLogin no et non prohibit-password ? Bien que prohibit-password bloque déjà l’accès root par mot de passe, laisser actif le login root par clé reste un risque : si cette clé est compromise, l’attaquant a accès total au système sans avoir besoin d’escalader les privilèges.

Changer le port SSH (sécurité par l’obscurité)

#

Changer le port par défaut (22) n’est pas une véritable sécurité, mais cela élimine le bruit des bots Internet qui scannent continuellement ce port :

Port 2222   # cualquier número entre 1024 y 65535

Sur le routeur ou le pare-feu, créez la règle de NAT pour rediriger le port externe vers le 22 interne, ou configurez UFW pour accepter le nouveau port.

Pare-feu avec UFW

#

UFW (Uncomplicated Firewall) simplifie la gestion d’iptables :

# Política por defecto: denegar todo
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Permitir solo lo necesario
sudo ufw allow 2222/tcp    # SSH en puerto personalizado
sudo ufw allow 80/tcp      # HTTP
sudo ufw allow 443/tcp     # HTTPS

# Activar
sudo ufw enable
sudo ufw status verbose

Mises à jour de sécurité automatiques

#

Les serveurs qui ne sont pas mis à jour finissent par être vulnérables. unattended-upgrades applique les correctifs de sécurité sans intervention manuelle :

sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades

Pour vérifier que c’est actif :

systemctl is-active unattended-upgrades

Le fichier de configuration se trouve dans /etc/apt/apt.conf.d/50unattended-upgrades. Par défaut, il n’applique que les mises à jour de sécurité, ce qui est le comportement correct pour la production.

Gestion des utilisateurs

#

Principe du moindre privilège

#

Chaque utilisateur ne doit avoir que les permissions dont il a besoin. Examinez régulièrement quels utilisateurs ont un shell actif :

grep -v nologin /etc/passwd | grep -v false

Pour désactiver un utilisateur sans le supprimer :

sudo usermod -s /usr/sbin/nologin usuario
sudo passwd -l usuario   # Bloquear contraseña

sudo sans mot de passe — avec discernement

#

Il est tentant de mettre NOPASSWD dans sudoers pour éviter de taper le mot de passe, mais limitez-le aux commandes spécifiques qui en ont besoin :

# Bien: solo para comandos concretos
usuario ALL=(ALL) NOPASSWD: /usr/bin/docker, /usr/bin/systemctl restart nginx

# Mal: acceso total sin contraseña
usuario ALL=(ALL) NOPASSWD: ALL

Protection contre les attaques par force brute avec fail2ban

#

fail2ban surveille les logs du système et bloque automatiquement les adresses IP qui effectuent trop de tentatives infructueuses :

sudo apt install fail2ban

Configuration basique dans /etc/fail2ban/jail.local :

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true
port    = 2222
logpath = %(sshd_log)s
backend = %(sshd_backend)s

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

# Ver IPs baneadas
sudo fail2ban-client status sshd

Audit : ce qu’il faut examiner régulièrement

#

Une fois le serveur configuré, il est conseillé d’examiner ces points avec une certaine fréquence :

# Intentos de acceso fallidos
sudo lastb | head -20

# Puertos escuchando (detectar servicios inesperados)
ss -tlnp

# Binarios con SUID (posibles vectores de escalada de privilegios)
find / -perm -4000 -type f 2>/dev/null

# Actualizaciones pendientes
apt list --upgradable 2>/dev/null | grep -i security

Chiffrement entre serveurs avec WireGuard

#

Si vous avez plusieurs serveurs qui doivent communiquer (rsync, bases de données, APIs internes), évitez d’exposer ces services à Internet. WireGuard offre un tunnel VPN rapide et simple avec chiffrement ChaCha20-Poly1305 :

sudo apt install wireguard
wg genkey | tee privatekey | wg pubkey > publickey

Le trafic entre serveurs voyage chiffré à travers le tunnel (10.10.0.x) au lieu d’utiliser les adresses IP publiques. Ainsi, des services comme rsync ou PostgreSQL ne sont jamais exposés même si quelqu’un intercepte le trafic réseau.

J’ai un article spécifique sur la réplication d’urgence avec rsync et WireGuard avec la configuration complète.

Résumé : checklist de durcissement

#

La sécurité parfaite n’existe pas, mais appliquer ces étapes réduit drastiquement la probabilité d’être la cible facile que les bots automatisés recherchent.

Équipement recommandé

#

• Mini PC Intel N100 — Mini PC silencieux et efficace pour serveur domestique 24/7
• YubiKey 5 NFC — Clé de sécurité physique pour 2FA et accès SSH sécurisé

Liens d’affiliation. Aucun coût supplémentaire pour toi.