nf_conntrack: table pleine, suppression de paquet
Je vois beaucoup de ces messages dans/var/log/messages de mon serveur Linux
kernel: nf_conntrack: table full, dropping packet.
kernel: __ratelimit: 15812 callbacks suppresse
alors que mon serveur est sous attaque DoS mais la mémoire n'est pas encore saturée. Je me demande quelle est la signification du message et comment contrer les éventuelles implications pour la sécurité.
Le message signifie que votre table de suivi des connexions est pleine. Il n'y a aucune implication de sécurité autre que DoS. Vous pouvez atténuer partiellement cela en augmentant le nombre maximal de connexions suivies, en réduisant les délais de suivi ou en désactivant complètement le suivi des connexions, ce qui est faisable sur le serveur, mais pas sur un NAT routeur, car le ce dernier cessera de fonctionner.
sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=54000
sysctl -w net.netfilter.nf_conntrack_generic_timeout=120
sysctl -w net.ipv4.netfilter.ip_conntrack_max=<more than currently set>
Voici un excellent article traitant du sujet. Essentiellement, cela signifie simplement que la table que les tables IP (via APF ou toute autre solution) utilise pour stocker les connexions persistantes est pleine. Au détriment de la mémoire, vous pouvez l'augmenter.
Je suggère également de définir vos règles de pare-feu pour rejeter plutôt que pour supprimer
Un correctif temporaire, si vous devez conserver vos iptables NAT sont:
linux:~# sysctl -w net.netfilter.nf_conntrack_max=131072
Je dis temporaire, car élever le nf_conntrack_max ne garantit pas, tout ira bien désormais. Cependant, sur de nombreux serveurs peu chargés de trafic, il suffit d'augmenter le net.netfilter.nf_conntrack_max=131072 à une valeur suffisamment élevée sera suffisant pour résoudre le problème.
- Augmenter la taille de la table de hachage nf_conntrack
La valeur de hachage de la table de hachage, qui stocke les listes d'entrées conntrack, doit être augmentée de manière proportionnelle, chaque fois que net.netfilter.nf_conntrack_max est augmenté.
linux:~# echo 32768 > /sys/module/nf_conntrack/parameters/hashsize
La règle pour calculer la bonne valeur à définir est:
hashsize = nf_conntrack_max / 4
- Pour stocker en permanence les modifications apportées; a) mettez dans /etc/sysctl.conf:
linux:~# echo 'net.netfilter.nf_conntrack_count = 131072' >> /etc/sysctl.conf
linux:~# /sbin/sysct -p
b) mettre /etc/rc.local (avant la ligne de sortie 0):
echo 32768 > /sys/module/nf_conntrack/parameters/hashsize
Remarque: Soyez prudent avec cette variable, selon mon expérience, la porter à une valeur trop élevée (en particulier sur les noyaux patchés XEN) pourrait geler le système. Élever également la valeur à un nombre trop élevé peut geler un serveur Linux standard fonctionnant sur un ancien matériel.
- Pour le diagnostic de nf_conntrack il y a des trucs;
/proc/sys/net/netfilter répertoire stocké dans la mémoire du noyau. Vous y trouverez des valeurs stockées dynamiquement qui donnent des informations sur nf_conntrack opérations en "temps réel":
linux:~# cd /proc/sys/net/netfilter linux:/proc/sys/net/netfilter# ls
-al nf_log/ total 0 dr-xr-xr-x 0 root root 0 Mar 23 23:02 ./ dr-xr-xr-x 0 root root 0 Mar 23 23:02 ../
-rw-r--r-- 1 root root 0 Mar 23 23:02 0
-rw-r--r-- 1 root root 0 Mar 23 23:02 1
-rw-r--r-- 1 root root 0 Mar 23 23:02 10
-rw-r--r-- 1 root root 0 Mar 23 23:02 11
-rw-r--r-- 1 root root 0 Mar 23 23:02 12
-rw-r--r-- 1 root root 0 Mar 23 23:02 2
-rw-r--r-- 1 root root 0 Mar 23 23:02 3
-rw-r--r-- 1 root root 0 Mar 23 23:02 4
-rw-r--r-- 1 root root 0 Mar 23 23:02 5
-rw-r--r-- 1 root root 0 Mar 23 23:02 6
-rw-r--r-- 1 root root 0 Mar 23 23:02 7
-rw-r--r-- 1 root root 0 Mar 23 23:02 8
-rw-r--r-- 1 root root 0 Mar 23 23:02 9
IV. Diminution des autres valeurs de délai d'attente nf_conntrack NAT pour empêcher le serveur contre les attaques DoS
Généralement, la valeur par défaut de nf_conntrack_* les délais d'attente sont (inutilement) importants.
Par conséquent, pour des flux de trafic importants, même si vous augmentez nf_conntrack_max, encore petit, vous pouvez obtenir un nf_conntrack table de débordement entraînant la suppression des connexions au serveur. Pour que cela ne se produise pas, vérifiez et diminuez les autres nf_conntrack valeurs de suivi des connexions d'expiration:
linux:~# sysctl -a | grep conntrack | grep timeout
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_events_retry_timeout = 15
net.ipv4.netfilter.ip_conntrack_generic_timeout = 600
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent2 = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 432000
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 30
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 10
net.ipv4.netfilter.ip_conntrack_tcp_timeout_max_retrans = 300
net.ipv4.netfilter.ip_conntrack_udp_timeout = 30
net.ipv4.netfilter.ip_conntrack_udp_timeout_stream = 180
net.ipv4.netfilter.ip_conntrack_icmp_timeout = 30
Tous les délais d'attente sont en secondes. net.netfilter.nf_conntrack_generic_timeout comme vous le voyez est assez élevé - 600 secondes = (10 minutes). Ce type de valeur signifie que toute connexion NAT ne répondant pas peut rester bloquée pendant 10 minutes!
La valeur net.netfilter.nf_conntrack_tcp_timeout_established = 432000 est également assez élevé (5 jours!) Si ces valeurs ne sont pas abaissées, le serveur sera une cible facile pour quiconque souhaite l'inonder de connexions excessives, une fois que cela se produit, le serveur atteindra rapidement même la valeur élevée. pour net.nf_conntrack_max et la coupure de connexion initiale se reproduira à nouveau…
Cela dit, pour empêcher le serveur des utilisateurs malveillants, situé derrière le NAT vous tourmentant avec des attaques par déni de service:
Inférieur net.ipv4.netfilter.ip_conntrack_generic_timeout à 60 - 120 secondes et net.ipv4.netfilter.ip_conntrack_tcp_timeout_established à quelque chose comme 54000
linux:~# sysctl -w net.ipv4.netfilter.ip_conntrack_generic_timeout = 120
linux:~# sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 54000
Ce délai devrait fonctionner correctement sur le routeur sans créer d'interruptions pour les utilisateurs réguliers NAT. Après avoir modifié les valeurs et surveillé pendant au moins quelques jours, rendez les modifications permanentes en les ajoutant à /etc/sysctl.conf
linux:~# echo 'net.ipv4.netfilter.ip_conntrack_generic_timeout = 120' >> /etc/sysctl.conf
linux:~# echo 'net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 54000' >> /etc/sysctl.conf
selon l'article génial à http://pc-freak.net/blog/resolving-nf_conntrack-table-full-dropping-packet-flood-message-in-dmesg-linux-kernel-log/ =