Linux est reconnu pour avoir l'une des
implémentation TCP/IP les plus aboutie et des plus
véloce.
Alors qu'elle possède, via Netfilter, un mécanisme bien
défini de filtrage et d'altération des paquets qui la
traverse, elle jouit également d'un nombre de
fonctionnalités
personnalisables très important, qui la rende très
modulaire. Du comportement du protocole TCP à la protection de
certaines attaques connues, le noyau Linux laisse à
l'administrateur système le soin de modeler comme il le
souhaite la couche TCP/IP de sa machine.
Dans cette partie, nous ne parlerons
pas de mécanismes tels que le QOS ou de routage avancé
via l'interface iproute2. Nous évoquerons essentiellement les
possibilités de configuration des paramêtres
réseaux
du noyau et donnerons des exemples pouvant servir pour améliorer
la réactivité du serveur en cas de surcharge ou
d'attaque.
Lorsque le noyau a été
compilé pour inclure cette fonctionnalité (c'est à
dire dans 99% des cas), l'administrateur et les utilisateurs ont
accès depuis la racine à un répertoire
particulier nommé procfs. Ce répertoire est un
« pseudo système de fichier » car il n'a
pas de lien physique avec une mémoire de masse mais se trouve
n'être qu'en mémoire. Il contient beaucoup
d'informations sur les processus en cours d'exécution, la
charge de la machine, l'utilisation de la mémoire ou encore
certains paramêtres du noyau.
[root@localhost proc]# ls /proc
1 1555 1639 1829 1887 73 fb ksyms pci
10 1564 1748 1831 1888 8 filesystems
loadavg
11 1573 1755 1833 1914 9 fs locks
...
1482 1592 1820 1849 5 dma isapnp mtrr
tty
1493 1593 1823 1863 6 driver kcore
net
15 1594 1825 1884 7 execdomains kmsg
partitions sys
Dans le répertoire /proc se trouve un sous répertoire sys, à l'intérieur duquel l'administrateur peut lire ou inscrire des valeurs qui modifierons le comportement du noyau à la volée :
[root@localhost proc]# ls /proc/sys/*
sys/dev:
cdrom parport raid rtc
sys/fs:
binfmt_misc file-max inode-state
overflowgid
dentry-state file-nr lease-break-time
overflowuid
dir-notify-enable inode-nr
leases-enable quota
sys/kernel:
acct hostname ostype random shmmni
cad_pid hotplug overflowgid
real-root-dev sysrq
cap-bound modprobe overflowuid
rtsig-max tainted
core_pattern msgmax panic rtsig-nr
threads-max
ctrl-alt-del msgmni
print_fatal_signals
shmall
domainname osrelease printk shmmax
sys/net:
802 core ethernet ipv4 token-ring unix
sys/vm:
bdflush max_map_count min-readahead
page-cluster
kswapd max-readahead
overcommit_memory
pagetable_cache
L'extrait du contenu du répertoire /proc/sys ci-dessus montre la hierarchisation des paramêtres que l'on peut modifier. Dans notre cas, nous allons nous occuper du répertoire /proc/sys/net/ipv4 (ou ipv6 selon la version d'ip utilisée).
Lorsque l'on modifie un
paramêtre
du noyau dans /proc, sachant que celui-ci n'est qu'une
représentation
particulière d'une partie de l'espace noyau en mémoire,
un redémarrage de la machine annulera tous les changements
opérés.
Un moyen simple de changer les
paramêtres et d'être certain que les changements seront
repris en compte au prochain redémarrage, il existe la
commande sysctl.
Entre autres choses, sysct permet de
lire ou d'écrire la valeur correspondante à la clé
passée en paramêtre, celle ci étant lue depuis le
répertoire /proc/sys. Appelée sans arguments, on lit la
valeur :
[root@localhost kernel]# sysctl
vm.pagetable_cache
vm.pagetable_cache = 25 50
[root@localhost kernel]# sysctl
kernel.pid_max
kernel.pid_max = 32768
Pour écrire un valeur dans une clé, on utilise l'argument -w :
[root@localhost kernel]# sysctl -w
kernel.pid_max=35000
kernel.pid_max = 35000
Dans le cadre de ce document, je ne m'attacherais qu'à décrire les paramêtres qui me sont apparus pertinents pour notre étude[LIEN]. Par ailleurs, certaines options sont disponibles directement depuis le répertoire ipv4 tandis que d'autre le sont depuis les sous-répertoire de conf. Alors que pour les premières, nous modifions le comportement global du noyau, pour les secondes, nous modifions le comportement associé à chaque interface réseau de notre machine.
Cet paramêtre permet d'activer (1) ou de désactiver (0) le routage IP entre les différentes interfaces réseaux de la machine. Doit être désactivé si la machine ne fait pas office de passerelle. Par défaut, cette option est désactivée.
Développé par un certain D.J. Berstein(...), les syncookies représentent un moyen efficace de contrer les attaques de type TCP SYN Flooding. En temps normal, lorsqu'un client fait une demande de connexion, le serveur met sa demande dans une file d'attente FIFO (limitée) en attendant le ACK du client qu'il ne devrait en fait jamais recevoir (3 way Handshake biaisé par l'utilisation d'une adresse IP spoofée). Lorsque le serveur est victime de SYN Flooding, la file d'attente des demandes de connexions se rempli jusqu'à ne plus pouvoir recevoir de connexions légitimes. Avec l'activation des SYN Cookies, le serveur envoi au client un numéro de séquence particulier (fonction du temps, d'un encodage du MSS du serveur en réponse à celui du client et d'une clé secrete basée sur l'ip source et destination ainsi que le port source et destination). La demande est traitée de suite et n'est pas mise dans la file d'attente des connexions en cours d'ouverture. Le serveur peut donc encore répondre aux demandes légitimes. NB: Cette fonctionnalité n'existe que sous Linux et Solaris...
Configuration de l'explicit notification congestion. Cette option permet à notre machine d'informer le client que la route qui suit vers sa destination est congestionnée et qu'il devrait ralentir la cadence d'emission des paquets. Elle est utile dans le cas d'utilisation de Linux comme routeur ou firewall. Par défaut, cette fonctionnalité est désactivée.
Cette option permet de définir le timeout que l'on alloue à une socket en état FIN-WAIT2 avant de la fermer. Cet état arrive lorsqu'un client ne valide pas la fin de la connexion de son coté. Par défaut, à 180 dans les noyau 2.2, puis 60 dans les noyau 2.4. Peut encore être baissée si votre serveur possède des ressources mémoires limitées (pour info, une socket dans cet état occupe 1,5Ko. Quelques milliers et cette occupation se chiffre en dizaines de méga...)
Taille de la file d'attente des connexions en cours d'établissement. Par défaut à 1024. Peut être agrandie afin de rendre les SYN Flood plus difficiles a réaliser.
Défini le nombre maximal de fois que le noyau tente d'envoyer un SYNACK sans recevoir de réponse de la part du client. Par défaut, cette variable est à 5. Peut être baissée (conséquences???)
Si cette option est activée (1), le noyau ne répondra jamais au paquets IP de type icmp echo, c'est à dire ping. Cette option, desactivée par défaut, peut empecher certaines applications réseaux de fonctionner normalement.
Si cette option est activée (1), le noyau ne répondra jamais aux paquets IP de type icmp_echo en brodcast ou multicast (ex: ping -b). Permet d'empecher les attaques de type smurf ou de DDOS sur un réseau local. Par défaut désactivée (0), cette fonctionnalité devrait toujours être utilisée.
ICMP est un protocole de la couche IP qui donne des informations sur cette même couche. Entre autres choses, elle permet d'informer un hôte ou un routeur qu'il existe une meilleure route pour accéder à un point du réseau (notamment lorsqu'il y a congestion du réseau). Par défaut, cette option est activée (1) et devrait être raisonablement désactivée (0), sachant qu'elle peut représenter un risque de sécurité.
Cette option, désactivée par défaut (0), permet si elle est activée (1) d'empecher la redirection ICMP des paquets si la source n'est pas comprise dans la liste des passerelles par défaut.
Cette option,
désactivée par défaut (0), permet si elle est
activée (1) d'envoyer des redirection ICMP à d'autres
hôtes lorsque notre machine officie en tant que routeur.
Les options que nous venons de citer
ne
représentent qu'un panel très restreint de ce qu'il est
possible de faire avec le noyau linux. Néanmoins, gardez
à
l'esprit que beaucoup options méritent d'être
testée
avant d'être utilisée en production.
En jouant sur les paramêtres du noyau, qu'ils soient appliqués sur la pile TCP/IP ou sur une interface particulière, on a la possibilité d'augmenter la montée en charge et la resistance du serveur face à certaines attaques de type déni de services ou simplement de surcharge. Le choix par défaut des paramêtres défini est généralement pertinent mais quelques modifications permettent d'augmenter significativement la sécurité de votre machine. Pour information, un SYN Flood lancé avec un débit de 56Kbit/s sur un serveur Linux sans activation des SYN Cookies peut compromettre sans problèmes le serveur en question. Idem pour TOUTE la famille des Windows Servers...
![]() |
![]() |
![]() |
![]() |
![]() |
First | Previous | Post comment | Next | Last |