Sécuriser la couche TCP/IP d’un serveur Linux avec sysctl

WPEngine: Premium Managed WooCommerce hosting

Durcir la couche TCP/IP d’un serveur Linux avec sysctl

Un serveur dédié n’a pas besoin de se comporter comme un routeur de bordure. Dans la majorité des cas, il héberge des services, répond à des connexions entrantes, puis renvoie ses réponses proprement. C’est tout. Pas besoin d’accepter des redirections ICMP douteuses, du source routing exotique ou des paquets qui sentent le spoofing à trois baies de distance.

On peut donc durcir une partie de la pile TCP/IP directement au niveau du noyau Linux avec sysctl. Ce n’est pas un pare-feu. Ce n’est pas une baguette magique. Toutefois, c’est une couche de défense saine, rapide à appliquer, et complémentaire à iptables, nftables, UFW et fail2ban.

Ce que l’on va sécuriser

L’objectif est de réduire la surface d’attaque réseau côté noyau. Nous allons notamment :

limiter le spoofing IP avec le reverse path filtering ;
activer une protection de base contre les attaques SYN flood ;
refuser les redirections ICMP ;
désactiver le source routing IPv4 et IPv6 ;
ignorer les réponses ICMP manifestement invalides ;
éviter les vieux scénarios de smurfing ;
désactiver le forwarding si le serveur ne fait pas routeur ;
garder IPv6 proprement configuré, sans casser la connectivité.

Sur un serveur web classique, ces réglages conviennent très bien. En revanche, adaptez-les si votre machine fait du routage, du VPN, du VRRP, du conteneur réseau avancé, du BGP, du Anycast, du multi-WAN ou du load-balancing bas niveau. Là, sysctl devient vite un sport de combat.

Kinsta: Premium Managed WordPress hosting

Créer un fichier sysctl dédié

Évitez de modifier directement /etc/sysctl.conf. Aujourd’hui, la méthode la plus propre consiste à créer un fichier dédié dans /etc/sysctl.d/. C’est plus lisible, plus facile à versionner, et surtout plus simple à désactiver si un réglage pose problème.

sudoedit /etc/sysctl.d/99-network-hardening.conf

Ajoutez ensuite cette configuration :

# SkyMinds - TCP/IP hardening for a standard Linux server.
# Adapt before using on routers, VPN gateways, Kubernetes nodes,
# complex multi-homed hosts, or servers using advanced network namespaces.

#
# IPv4 forwarding: keep disabled unless the server is a router.
#
net.ipv4.ip_forward = 0

#
# Reverse path filtering.
# 1 = strict filtering.
# Use 2 instead on multi-homed servers where asymmetric routing is expected.
#
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

#
# Log packets with impossible source addresses.
# Useful for diagnostics, but reduce noise if logs become too chatty.
#
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1

#
# SYN flood mitigation.
#
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096

#
# Do not accept ICMP redirects.
#
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

#
# Do not send ICMP redirects.
#
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

#
# Disable source-routed packets.
#
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0

#
# Ignore bogus ICMP errors and broadcast pings.
#
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1

#
# IPv6 router advertisements.
# Keep this disabled on a server with static IPv6 configuration.
# Do not use blindly if your provider uses SLAAC or router advertisements.
#
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0Langage du code : PHP (php)

Appliquer la configuration

Chargez les réglages sans redémarrer :

sudo sysctl --system

Cette commande relit les fichiers sysctl gérés par le système, dont ceux présents dans /etc/sysctl.d/. Elle vous évite aussi d’oublier un fichier chargé ailleurs. Petit confort, gros gain de lisibilité.

Le plus lu : L'ordre des adjectifs en anglais

Pour vérifier une valeur précise :

sysctl net.ipv4.tcp_syncookies
sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.all.accept_redirects
sysctl net.ipv6.conf.all.accept_redirectsLangage du code : CSS (css)

Vous pouvez aussi lire directement les valeurs exposées par le noyau :

cat /proc/sys/net/ipv4/tcp_syncookies
cat /proc/sys/net/ipv4/conf/all/rp_filter
cat /proc/sys/net/ipv4/conf/all/accept_redirects

Attention au reverse path filtering

Le réglage rp_filter aide à bloquer certains paquets dont l’adresse source ne colle pas au chemin de retour attendu. Sur un serveur simple, c’est souhaitable. Sur une machine avec plusieurs interfaces, plusieurs routes par défaut, du routage asymétrique ou des tunnels VPN, le mode strict peut casser du trafic légitime.

Dans ce cas, utilisez le mode lâche :

net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 2Langage du code : PHP (php)

Et si vous administrez un serveur hébergé chez OVH, Hetzner, Online/Scaleway, Infomaniak ou tout autre fournisseur avec configuration réseau spécifique, vérifiez toujours la route avant d’appliquer bêtement une recette. Les recettes aveugles finissent souvent en ticket support. Et personne ne veut passer son vendredi soir à réparer une route de retour.

IPv6 : ne désactivez pas tout par réflexe

L’ancien réflexe consistait souvent à désactiver l’autoconfiguration IPv6 sur toutes les interfaces, par exemple avec net.ipv6.conf.eth0.autoconf = 0. Cette approche vieillit mal. D’abord, l’interface ne s’appelle plus forcément eth0. Ensuite, certains hébergeurs utilisent IPv6 avec SLAAC, router advertisements ou une configuration hybride.

Si votre serveur possède une IPv6 statique configurée proprement, vous pouvez refuser les router advertisements avec :

net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0Langage du code : PHP (php)

En revanche, ne désactivez pas IPv6 “pour sécuriser”. C’est rarement une bonne stratégie. Sécurisez plutôt IPv6 avec les mêmes exigences qu’IPv4 : pare-feu, services minimaux, écoute contrôlée, logs et supervision.

Tester après application

Après un durcissement réseau, on vérifie deux choses : les paramètres noyau et la connectivité réelle. Commencez par confirmer les valeurs importantes :

sysctl -a 2>/dev/null | grep -E 'rp_filter|accept_redirects|send_redirects|accept_source_route|tcp_syncookies|log_martians|accept_ra'Langage du code : JavaScript (javascript)

Puis testez le réseau depuis et vers le serveur :

ip route
ip -6 route
ping -c 3 1.1.1.1
ping -c 3 skyminds.net
curl -I https://www.skyminds.net/Langage du code : JavaScript (javascript)

Si le serveur héberge un site WordPress, vérifiez aussi les services exposés :

ss -tulpn

Cette commande liste les ports TCP/UDP en écoute. Elle vous dira rapidement si un service bavard écoute sur toutes les interfaces alors qu’il devrait rester local. C’est souvent là que les vrais problèmes commencent.

Le plus lu : Serveur dédié : création d'un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d'utilisateurs/domaines virtuels

Revenir en arrière proprement

Si un réglage casse votre connectivité, ne paniquez pas. Renommez le fichier, rechargez sysctl, puis analysez calmement :

sudo mv /etc/sysctl.d/99-network-hardening.conf /etc/sysctl.d/99-network-hardening.conf.disabled
sudo sysctl --system

Ensuite, remettez les réglages un par un. Dans la pratique, les coupables habituels sont rp_filter sur les serveurs multi-homés et les réglages IPv6 quand l’hébergeur s’appuie sur router advertisements.

Ce que sysctl ne remplace pas

Ce durcissement améliore le comportement réseau du noyau, mais il ne remplace pas une vraie politique de sécurité. Vous avez encore besoin :

d’un pare-feu propre avec nftables, iptables ou UFW ;
d’un filtrage applicatif si vous exposez Apache ou Nginx, avec éventuellement ModSecurity selon le contexte ;
d’une protection SSH sérieuse : clés, désactivation du login root, fail2ban ou équivalent ;
d’une surveillance des logs système ;
de mises à jour régulières du noyau et des paquets ;
d’une configuration cohérente pour les services sensibles comme Postfix, IMAP et SMTP.

La bonne approche reste cumulative. On durcit le noyau, puis on filtre les ports, puis on verrouille les services, puis on surveille. La sécurité serveur, ce n’est pas un cadenas. C’est une série de portes bien fermées.

Résumé de la configuration recommandée

Pour un serveur Linux standard, hébergeant des sites web, des services PHP, une base de données locale ou un serveur mail classique, cette base est saine :

tcp_syncookies = 1 pour limiter l’impact des SYN flood ;
accept_redirects = 0 pour refuser les redirections ICMP ;
send_redirects = 0 puisque le serveur n’est pas un routeur ;
accept_source_route = 0 pour refuser le source routing ;
rp_filter = 1 sur serveur simple, ou 2 sur serveur multi-homé ;
log_martians = 1 pour mieux repérer les paquets suspects ;
icmp_echo_ignore_broadcasts = 1 pour éviter les vieux scénarios de smurfing ;
accept_ra = 0 uniquement si votre IPv6 ne dépend pas des router advertisements.

Appliqué proprement, ce durcissement prend moins de dix minutes. Et contrairement à beaucoup de “tweaks” pseudo-magiques, celui-ci améliore réellement l’hygiène réseau du serveur.

Sources et documentation

Report a typo

Shares3Facebook Tweet Pin LinkedIn