Sécurité de votre serveur linux : Comment durcir un serveur sous linux ?

Dans ce guide pratique, on va renforcer ensemble la sécurité de votre serveur Linux. De la configuration SSH au pare-feu en passant par les paramètres sysctl, on couvre toutes les mesures essentielles pour rendre ton serveur aussi résistant que possible.

Cette optimisation s’inscrit dans une démarche plus globale de gestion des ressources système — au même titre que la configuration du swap Linux qui permet d’éviter les dysfonctionnements en cas de saturation mémoire.

Table des matières

Sécurisation de la mémoire partagée

/dev/shm peut être utilisé dans une attaque contre un service en cours d’exécution, comme Apache ou Nginx. On va le monter avec des options restrictives.

Ouvre /etc/fstab :

sudo nano /etc/fstab

Ajoute ou modifie la ligne suivante :

tmpfs     /dev/shm     tmpfs     defaults,noexec,nosuid,nodev     0     0

Recharge sans redémarrer :

sudo mount -o remount /dev/shm

Durcissement de SSH – désactivation de la connexion en tant que root et changement de port

Le moyen le plus efficace de sécuriser SSH : désactiver la connexion root, désactiver l’authentification par mot de passe (clés uniquement — ou mieux encore, des passkeys SSH biométriques), et changer le port par défaut.

Avant tout : crée un utilisateur non-root avec accès sudo et configure ta clé SSH. Si tu perds l’accès SSH après modification, tu te retrouves bloqué.

Édite la configuration SSH :

sudo nano /etc/ssh/sshd_config

Modifie ou ajoute ces lignes :

Port <TON_PORT>
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
X11Forwarding no
AllowUsers <TON_UTILISATEUR>

Protocol 2 est désormais le seul protocole supporté depuis OpenSSH 7.0 (2015) — inutile de le spécifier.

Applique les changements :

sudo systemctl restart ssh

Protéger su en limitant l’accès uniquement au groupe admin

sudo groupadd admin
sudo usermod -a -G admin <TON_UTILISATEUR>
sudo dpkg-statoverride --update --add root admin 4750 /bin/su

Renforcer le réseau avec les paramètres sysctl

/etc/sysctl.conf contrôle les paramètres noyau. Ces réglages protègent contre l’usurpation d’IP, les attaques SYN flood et les redirections malveillantes.

Ouvre le fichier :

sudo nano /etc/sysctl.conf

Ajoute les lignes suivantes :

# Protection contre l'usurpation d'IP
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Ignorer les demandes de diffusion ICMP
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Désactiver le routage des paquets source
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0

# Ignorer les redirections envoyées
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

# Bloquer les attaques SYN
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 5

# Enregistrer les paquets « martiens »
net.ipv4.conf.all.log_martians = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Ignorer les redirections ICMP
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

Applique sans redémarrer :

sudo sysctl -p

net.ipv4.icmp_echo_ignore_all = 1 (bloquer tous les pings) est intentionnellement omis : ça casse les diagnostics réseau sans apporter de sécurité réelle sur un serveur bien configuré avec un pare-feu.

Désactivez la récursion DNS ouverte et supprimez les informations de version – Serveur DNS BIND

Si tu fais tourner BIND9, désactive la récursion ouverte pour éviter d’être utilisé dans une attaque par amplification DNS.

sudo nano /etc/bind/named.conf.options

Dans la section options { ... } :

recursion no;
version "Not Disclosed";

Redémarre BIND :

sudo systemctl restart bind9

Prévenir l’usurpation d’IP

sudo nano /etc/host.conf

Ajoute :

order bind,hosts
nospoof on

Renforcez PHP pour la sécurité

Note : le chemin varie selon la version PHP installée. Remplace 8.x par ta version (php -v).

sudo nano /etc/php/8.x/apache2/php.ini

Modifie ou ajoute :

disable_functions = exec,system,shell_exec,passthru
expose_php = Off
display_errors = Off
html_errors = Off

register_globals, magic_quotes_gpc et track_errors ont été supprimés respectivement en PHP 5.4, 5.4 et 8.0 — inutile de les définir sur une installation moderne.

Redémarre Apache :

sudo systemctl restart apache2

Limitez la fuite d’informations Apache

sudo nano /etc/apache2/conf-available/security.conf

Modifie ou ajoute :

ServerTokens Prod
ServerSignature Off
TraceEnable Off
Header unset ETag
FileETag None

Active la configuration si besoin et redémarre :

sudo a2enconf security
sudo systemctl restart apache2

Analysez les journaux et bannissez les hôtes suspects – Fail2Ban

DenyHosts est obsolète : plus maintenu depuis 2014 et incompatible avec systemd. Utilise uniquement Fail2Ban, qui remplit le même rôle avec une bien meilleure intégration système.

Si tu préfères isoler Fail2Ban dans un container plutôt que l’installer sur l’hôte, j’ai publié un guide complet pour déployer Fail2Ban avec Docker et configurer les filtres personnalisés en quelques minutes.

Installation :

sudo apt install fail2ban

Crée une configuration locale — ne jamais modifier jail.conf directement, il est écrasé lors des mises à jour :

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

Configure la jail SSH (adapte le port si tu l’as changé) :

[sshd]
enabled  = true
port     = <TON_PORT_SSH>
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 3
bantime  = 3600
findtime = 600

Pour recevoir des alertes email en cas de bannissement :

[DEFAULT]
destemail = ton@email.com
action = %(action_mwl)s

Démarre et active au démarrage :

sudo systemctl enable --now fail2ban

Vérifie l’état :

sudo fail2ban-client status
sudo fail2ban-client status sshd

Conclusion — sécurité de votre serveur Linux en pratique

Ces mesures constituent une base solide pour tout serveur Linux exposé sur internet. L’ordre d’application compte : commence par SSH (tu ne veux pas te bloquer toi-même), puis sysctl, puis fail2ban.

Quelques rappels essentiels :

• Teste chaque changement SSH dans une seconde session avant de fermer la première
• Configure un pare-feu en complément — mon guide UFW avec Docker explique comment faire sans que Docker contourne tes règles
• Mets à jour régulièrement : sudo apt update && sudo apt upgrade
• Surveille les logs : journalctl -u ssh, sudo fail2ban-client status sshd

Articles connexes

• Dépannage des problèmes de montage de matrices RAID (mdadm)
• Content-Security-Policy : Protéger votre site sans bloquer vos scripts