Détails des durcissements des sysctl sous Linux : sysctl réseau

I. Présentation

Faisant suite à mon autre article "Détails des durcissements des sysctl sous Linux : sysctl système".

Nous allons dans cet article nous intéresser aux durcissements recommandés par l'ANSSI sur les sysctl réseau dans son guide Recommandation de configuration d'un système GNU/Linux. Je vais dans cet article suivre la même approche que dans l'article précédent, dans lequel vous trouverez également quelques exemples d'utilisation de la commande sysctl pour lire et écrire des paramètres.

Pour les paramètres sysctl au niveau réseau, celles-ci peuvent être appliquées à plusieurs niveaux, ce qui détermine le nom précis du paramètre à modifier. On peut par exemple différencier les paramètres s'appliquant sur les interfaces IPv4 (net.ipv4.X.X) ou IPv6 (net.ipv6.X.X), mais également spécifier une interface précise (net.ipv4.eth0), les mots-clés all et default sont utilisés respectivement pour appliquer un paramètre sur toutes les interfaces ou pour les interfaces nouvellement créées (configuration par défaut si rien n'est spécifié).

Ça, c'était la théorie, la réalité est un chouilla plus obscure (voir ce mail https://marc.info/?l=linux-kernel&m=123606366021995&w=2) et je vous déconseille, pour résumer, de paramétrer des valeurs différentes pour le all et le default d'une même sysctl sous peine de vous retrouver avec des comportements difficiles à déboguer ou à comprendre.

II. Durcissement des sysctl réseau Linux

A. IP Forwarding

Le premier durcissement généralement recommandé en ce qui concerne les sysctl réseau est la désactivation de l'IP forwarding. Ce sysctl, lorsqu'il est à 1, permet au serveur de faire transiter des paquets d'une interface vers une autre, à l'image d'un routeur. Lorsque cette fonctionnalité n'est pas utile au fonctionnement du serveur, il est recommandé de désactiver l'IP forwarding :

net.ipv4.ip_forward = 0

Ainsi, le serveur ne sera pas autorisé à faire du routing, c'est-à-dire faire suivre des paquets d'une interface vers une autre, et ne pourra être utilisé comme un routeur entre deux réseaux. Dans le cas où votre serveur dispose de deux interfaces, dont une vers un réseau non maitrisé (Internet par exemple), les paquets provenant d'internet ne pourront atteindre directement les autres serveurs du réseau non exposé (deuxième interface de votre serveur), car le serveur ne fera pas suivre ces paquets, même s'il connait la route par lesquels ils sont censés passer.

Dans le cas où ce sysctl est à 1 (IP forwarding activé), alors les paquets reçus par le serveur sans lui être destinés, mais pour lesquels il connait une route seront automatiquement envoyés sur cette route, le serveur pourrait alors servir de pont entre deux réseaux sans que cela ne soit voulu.

À noter que ce paramétrage ne protège pas de tout, si votre serveur est compromis ou si l'application web qu'il héberge est ciblée par une attaque SSRF (Server Side Request Forgery), alors les IP du réseau "interne" pourront tout de même être atteintes.

B. Filtrage par chemin inverse

Le filtrage par chemin inverse ou Reverse Path Filtering est un mécanisme du noyau Linux consistant à vérifier si l'adresse source indiquée dans les paquets reçus par une interface est routable par cette interface. En d'autres termes, lorsque notre serveur va recevoir un paquet sur une interface, il va l'ouvrir, regarder quelle est son adresse IP source, puis utiliser sa table de routage pour voir s’il contient une route capable de joindre cette IP source pour l'interface par laquelle il a reçu ce paquet (qui deviendra une IP destination en cas de réponse :)). On pourrait décrire ce mécanisme comme un contrôle de cohérence du serveur qui reçoit un paquet, le serveur cherche à vérifier s'il est normal ou cohérent de recevoir un paquet avec telle IP source sur cette interface.

Dans le cas où ce "contrôle de cohérence" échoue, le paquet est supprimé ("droppé" pourrait-on dire en bon français). L'ANSSI recommande d'activer cette fonctionnalité en mettant une valeur 1 aux sysctl suivants :

 net.ipv4.conf.all.rp_filter = 1
 net.ipv4.conf.default.rp_filter = 1

À noter que les systèmes Red Hat possèdent une option supplémentaire (2) permettant d'accepter un paquet si son IP source est routable par n'importe quelle interface du serveur, et non pas uniquement par l'interface ayant réceptionné le paquet analysé.

Le reverse path filtering est en réalité un mécanisme créé pour limiter les attaques par Déni de Service (Denial of Service ou DoS). L'une des techniques de déni de service profite du Three way Handshake TCP combiné à de l'IP spoofing. Plus clairement, l'attaquant va envoyer des milliers de paquets TCP SYN au serveur avec des adresses IP usurpées ou n'existant pas. Le serveur va alors renvoyer à ces adresses IP un paquet SYN/ACK et n'obtiendra jamais de réponse. Ainsi, les connexions resteront ouvertes pendant un long moment, ce qui les rendra indisponibles pour de nouvelles connexions légitimes. Un peu comme si l'on réservait toutes les tables d'un restaurant sur une semaine sans venir y manger :).

Ce mécanisme est décrit précisément dans la RFC3704 : https://tools.ietf.org/html/rfc3704

Lorsqu'une telle attaque intervient avec un rp_filter activé, la plupart des paquets seront droppés dès leur réception, car le système remarquera qu'ils ne sont pas légitimes pour arriver sur une interface réseau donnée.

C. Redirections ICMP

L'ICMP (Internet Control Message Protocol) est un protocole qui ne se réduit pas au ping, les paquets echo request (paquet ICMP de type 8) et echo reply (paquet ICMP de type 0) observés lorsqu'on fait un ping ne sont qu'une petite partie des capacités de ce protocole. Parmi les fonctions méconnues de ce dernier, les paquets ICMP de type 5, nommés Redirect Messages sont utilisés afin d'avertir un hôte nous ayant envoyé un message qu'une autre route est possible (et plus rapide) pour joindre l'hôte qu'il cherche à contacter.

Ce mécanisme se nomme l'ICMP redirect est n'est utilisé qu'à de rares occasions (voire jamais) sur un système d'information moderne correctement configuré, et comme tout en sécurité, si c'est inutile, c'est à désactiver.

net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

En soit, ce mécanisme de l'ICMP redirect permet donc à un hôte recevant un paquet de faire passer son correspondant par un autre chemin réseau, en lui indiquant une nouvelle route qu'il intégrera durablement dans sa table de routage, un attaquant utilisant ce mécanisme envers un système peut donc modifier le chemin qu'emprunterons les futurs paquets, et pourquoi pas provoquer une attaque de type Man in the Middle ou une simple interruption de service. C'est pourquoi l'ANSSI recommande de désactiver l'acceptation et l'envoi de paquets ICMP redirect.

Le sysctl secure_redirects correspond à une option permettant à l'hôte d'accepter un paquet ICMP redirect uniquement si celui provient de l'adresse IP d'une des passerelles enregistrées au niveau de la configuration réseau. On cherche ici a maintenir l'utilisation de l'ICMP redirect, mais à réduire les hôtes pouvant nous envoyés de tels paquets à une liste de confiance.

D. Source routing

Pour l'expéditeur d'un paquet IP, le mécanisme du source routing consiste en la possibilité de définir la route prise par ce paquet sur le réseau. Alors que dans la plupart des cas, un paquet IP est envoyé par son expéditeur sur la passerelle réseau, qui définit ensuite en fonction de sa table de routage quel sera le prochain saut ou la prochaine passerelle à atteindre. Dans le cas d'un source routing, l'expéditeur peut inclure dans le paquet IP une liste d'adresses IP par lequel le paquet devra passer et ainsi modifier la décision nominale des différentes passerelles du réseau qui seront traversées. En d'autres termes, l'expéditeur peut manipuler une partie de la décision des passerelles concernant le routage des paquets. Également, le chemin par lequel le paquet est passé peut être transmis à son destinataire, qui prendra potentiellement ce chemin pour ses réponses. Les guides de bonnes pratiques recommandent de désactiver cette fonctionnalité :

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

Dans les faits, le source routing au niveau d'un paquet IP n'est presque jamais utilisé, il peut être utile pour du débogage (notamment pour du traceroute). En plus d'aider à dresser une cartographie du réseau, le source routing reste intéressant pour un attaquant, car il peut permettre de joindre une machine sur un réseau qui n'est, selon les tables de routages habituelles, pas accessibles au travers un serveur ayant deux interfaces réseau par exemple. 

E. Journalisation des martians packet

L'IANA définit un paquet "martien" comme un paquet qui arrive sur une interface n'utilisant pas le réseau source ou destination du paquet reçu. Pour Linux, il s’agit de tout paquet qui arrive sur une interface qui n’est en aucun cas configurée pour ce sous-réseau.

net.ipv4.conf.all.log_martians = 1

L'objectif de la journalisation des IP "anormales" est justement de pouvoir investiguer, voire alerter et réagir sur un comportement réseau qui n'est pas usuel. Il est en effet courant qu'un attaquant produise ce genre de comportements anormaux lors d'une phase de cartographie, d'une analyse comportementale d'un hôte ou d'un service pour en déterminer la nature (version, technologie précise), voir de causer un bug ou d'exploiter une vulnérabilité.

Dans les faits, la journalisation d'un tel paquet aura aussi de grandes chances de provenir d'une erreur de configuration au niveau des routes et des routeurs du réseau, le but pourrait donc également être d'avertir les administrateurs d'un potentiel problème de routage.

F. RFC 1337

La RFC 1337 est une RFC de type Informationnal (non obligatoire en somme) qui décrit un bug théoriquement possible sur des connexions TCP, ce bug est nommé "TIME-WAIT Assassination hazards". En somme, il s'agit d'une "lacune" dans la conception de TCP/IP qui rend possible la fermeture d'une connexion en TIME-WAIT par un paquet provenant d'une ancienne session TCP (arrivé en retard ou en dupliqué à cause d'une latence quelconque). Ce cas de figure théorique peut donc perturber des communications établies entre un client et un serveur :

net.ipv4.tcp_rfc1337 = 1

Cette protection vise donc à se protéger d'une anomalie potentielle dans les communications TCP, qui n'est pas le fruit d'une attaque ciblée visant à avoir un résultat précis.

G. Ignorer les réponses non conformes à la RFC 1122

Certains routeurs sur Internet ignorent les normes établies dans la RFC 1122 et envoient de fausses réponses aux trames de diffusion. Normalement, ces violations sont journalisées via les fonctions de journalisation du noyau, mais si vous ne voulez pas voir ces messages d'erreur dans vos journaux, vous pouvez activer cette variable, ce qui conduira à ignorer totalement tous ces messages d'erreur.

La RFC 1122  normalise ce que toute machine terminale (host, par opposition à routeur) connectée à l'Internet devrait savoir. Je vous invite à consulter la description de Stéphane Borztmeyer sur son blog pour plus de détails : RFC 1122: Requirements for Internet Hosts - Communication Layers

net.ipv4.icmp_ignore_bogus_error_responses = 1

L'objectif est donc simplement d'économiser un tout petit peu d'espace disque et d'éviter la présence de certains évènements inutiles dans les journaux. Peu d'impact en termes de sécurité donc.

H. Augmenter la plage pour les ports éphémères

Les ports éphémères sont les ports utilisés comme port source lorsqu'un système initie une connexion vers un serveur (alors nommés "port client"). Ces ports peuvent également être utilisés par certains protocoles dans une seconde phase d'échange avec le client après un premier échange sur un port "officiel". C'est notamment le cas pour les protocoles TFTP ou RPC. Sur les serveurs à haut trafic (reverse proxy ou load balancer), il est recommandé d'élargir la plage de port par rapport à celle par défaut :

net.ipv4.ip_local_port_range = 32768 65535

À noter que 65535 est la valeur la plus haute pouvant être acceptée. La valeur la plus basse (ici 32768) peut aller jusqu'à 0, gardez cependant à l'esprit que de nombreux ports sont réservés à des usages spécifiques (22 pour SSH, 80 pour HTTP, etc.). Il est donc plus sage de ne pas empiéter sur ces ports-là.

Le gain n'est pas très significatif, mais ce faisant, nous permettons au serveur d'établir plus de connexions et limitons ainsi les risques de saturation de ces ports pouvant être provoqués intentionnellement (attaque par déni de service) ou non (trafic réseau exceptionnellement élevé).

I. Utiliser les SYN cookies

Les SYN cookies sont des valeurs particulières des numéros de séquences initiales générés par un serveur (ISN: Initial Sequence Number) lors d'une demande de connexion TCP. Les bonnes pratiques de sécurité recommandent leur activation au niveau des échanges réseau :

 net.ipv4.tcp_syncookies = 1

L'activation des SYN cookies au niveau du système permet de se protéger des attaques par inondation de requêtes SYN (SYN flooding) qui consiste à ouvrir un très grand nombre de connexions sur un serveur à l'aide de requêtes SYN, sans jamais donner suite au Three Way Handshake TCP (SYN, SYN/ACK, ACK). Le serveur maintient donc un ensemble de connexions en attente (attente de réception d'un ACK après envoi d'un SYN/ACK), ce qui finit par saturer les connexions disponibles pour les clients légitimes.

Ce mécanisme permet au serveur de garder la "tête froide" lorsqu'il est ciblé par une telle attaque, mais il n'est pas conçu pour améliorer les capacités du serveur dans un contexte normal de fonctionnement (autre qu'une attaque par SYN flood).

Attention toutefois : les SYN cookies ne sont en théorie pas conforme au protocole TCP et empêchent l'utilisation d'extension TCP, ils peuvent entraîner une dégradation sérieuse de certains services (par exemple le relais SMTP). Si vous voulez tester les effets des SYN cookies sur vos connexions réseau, vous pouvez paramétrer ce sysctl sur 2 pour activer sans condition la génération de SYN cookies.

J. Gestion de l'IPv6

Dans le cas où l'IPv6 n'est pas activement utilisé au sein de vos réseaux locaux (c'est très très souvent le cas), il est tout simplement recommandé de désactiver la prise en compte de l'IPv6 au niveau du noyau Linux.

net.ipv6.conf.all.disable_ipv6 = 1 
net.ipv6.conf.default.disable_ipv6 = 1

La désactivation pure et simple de l'IPv6 permet de réduire la surface d'attaque du serveur, ce qui est l'un des principaux fondements de la sécurité. Dans bien des cas, l'IPv6 peut être utilisé pour détourner du trafic réseau, réaliser des attaques par déni de service ou contourner des politiques de filtrage lorsqu'il n'est pas activement utilisé et pris en compte dans la configuration et le durcissement global d'un système d'information.

K. Gestion de l'auto-configuration IPv6

Dans le cas, très rare selon moi, où vous utilisez de manière active l'IPv6 dans vos infrastructures internes, différents paramètres peuvent être utilisés afin de durcir la configuration de vos systèmes.

En IPv6, les router advertisements sont des paquets régulièrement envoyés par les routeurs d'un réseau pour s'annoncer aux éventuels nouveaux venus. Les informations contenues dans les router advertisements permettent à un nouvel hôte connecté de récupérer les caractéristiques essentielles du réseau, passerelles par défaut, routes et le préfixe servant à se forger une adresse IPv6 en auto configuration.

Dans le cas où les adresses IPv6 sont établies de manière statique sur vos réseaux, il est recommandé de désactiver la prise en charge des router advertisements afin de ne pas laisser la possibilité à un attaquant d'utiliser leur prise en charge sur les systèmes du réseau pour lui-même déterminer la configuration IPv6 de ces systèmes . En effet, quoi de plus simple que de se faire passer pour un routeur ou une passerelle pour réaliser une attaque par l'homme du milieu ?

# Ne pas accepter les router preferences par router advertisements
net.ipv6.conf.all.accept_ra_rtr_pref = 0
net.ipv6.conf.default.accept_ra_rtr_pref = 0

# Pas de configuration automatique des prefix par router advertisements
net.ipv6.conf.all.accept_ra_pinfo = 0
net.ipv6.conf.default.accept_ra_pinfo = 0

# Pas d’apprentissage de la passerelle par router advertisements
net.ipv6.conf.all.accept_ra_defrtr = 0
net.ipv6.conf.default.accept_ra_defrtr = 0

# Pas de configuration auto des adresses à partir des router advertisements
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.autoconf = 0

L. Désactiver le support des "router solicitations" IPv6

En IPv6, le router sollicitation est un type de message qui permet à un hôte de demander à tous les routeurs présents sur le réseau local de lui envoyer un Router Advertisement, afin qu'il l'enregistre dans sa liste de voisins et qu'il puisse récupérer les éléments essentiels du réseau IPv6. Dans le cas où les adresses IPv6 sont paramétrées en statique, il est recommandé de désactiver ce mécanisme :

 net.ipv6.conf.all.router_solicitations = 0
 net.ipv6.conf.default.router_solicitations = 0

Pour être plus précis, ce sysctl configure le nombre de router sollicitation à envoyer sur le réseau avant de considérer qu'il n'y a pas de routeur sur le réseau. Désactiver ce comportement lorsque les adresses IPv6 sont statiques permet donc d'éviter du trafic inutile, mais également qu'un attaquant puisse répondre à ces sollicitations en vue de se faire passer pour un routeur IPv6 auprès de votre serveur, lui facilitant ainsi le travail pour la réalisation d'une attaque de type man in the middle.

M. Nombre maximal d’adresses autoconfigurées par interface

L'adressage IPv6 permet d'utiliser plusieurs adresses par interface. À moins que vous n'ayez un besoin particulier nécessitant plusieurs adresses IPv6 unicast global par interface, il est recommandé de paramétrer ce sysctl à 1, ce qui limite à 1 le nombre d'adresses unicast global par interface (16 possibles dans la configuration par défaut).

 net.ipv6.conf.all.max_addresses = 1
 net.ipv6.conf.default.max_addresses = 1

Attention, positionner ces sysctl à 0 rend illimité le nombre d'adresses possibles, ce qui finira par avoir un impact sur les performances de votre serveur.

J'ai toutefois du mal à trouver des risques concrets relatifs à la non-application de ce paramètre. D'après ma compréhension du paramètre dans son état par défaut et du fonctionnement de l'IPv6, sa non-application entrainera la possibilité pour un attaquant de générer la création d'une adresse IPv6 sur sa cible puisque dans un environnement "normal", les 16 slots disponibles sur l'interface IPv6 ne seront pas toutes utilisées. En principe on laisse donc au travers la configuration par défaut, des paramètres non utilisés qui n'attendent qu'à recevoir les faux router avertissements d'un attaquant.  Alors que si le nombre d'adresses IPv6 est limité à 1 par interface est que celle-ci est déjà configurée lors de la venue de l'attaquant (en statique qui plus est), ce dernier n'aura pas de porte d'entrée possible.

N'hésitez pas à ajouter des informations de compréhension supplémentaires dans les commentaires si vous en avez à ce sujet :).

III. Conclusion

Voilà, nous avons fait le tour des durcissements sysctl recommandés par l'ANSSI dans son guide Recommandations de configuration d'un système GNU/Linux. Vous aurez compris que les raisons de certains durcissements sont faciles à appréhender alors que d'autres sont plus bien abstraits ou répondent à des cas très spécifiques. Quoi qu'il en soit j'espère vous avoir apporté une lumière supplémentaire sur ces éléments.

N'hésitez pas à signaler toute erreur ou précision technique dans les commentaires 🙂

Mickael Dorigny Co-founder

Co-fondateur d'IT-Connect.fr. Auditeur/Pentester chez Orange Cyberdéfense.

See Full Bio