Un problème assez fréquent lors de petit DDOS, ou de montée en charge de serveur.
Le module ip_conntrack ou nf_conntrack permet le suivi de connexions lorsque l’on utilise netfilter. Dans cette table sont écrites toutes les connexions ouvertes ces 5 derniers jours. Cela peut poser un problème lorsque cette table est pleine. Aucune connexion n’est alors possible et la console renvoie le message suivant :
nf_conntrack: table full, dropping packet.
Ou
ip_conntrack: table full, dropping packet.
Il faut commencer par regarder les valeurs par défaut :
#/sbin/sysctl -a | grep conntrack
Ce qui devrait donner quelque chose comme ça :
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_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_tcp_loose = 1
net.ipv4.netfilter.ip_conntrack_tcp_be_liberal = 0
net.ipv4.netfilter.ip_conntrack_tcp_max_retrans = 3
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
net.ipv4.netfilter.ip_conntrack_max = 131072
net.ipv4.netfilter.ip_conntrack_count = 4983
net.ipv4.netfilter.ip_conntrack_buckets = 16384
net.ipv4.netfilter.ip_conntrack_checksum = 1
net.ipv4.netfilter.ip_conntrack_log_invalid = 0
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_max = 131072
net.netfilter.nf_conntrack_count = 4983
net.netfilter.nf_conntrack_buckets = 16384
net.netfilter.nf_conntrack_checksum = 1
net.netfilter.nf_conntrack_log_invalid = 0
net.netfilter.nf_conntrack_expect_max = 256
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_loose = 1
net.netfilter.nf_conntrack_tcp_be_liberal = 0
net.netfilter.nf_conntrack_tcp_max_retrans = 3
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180
net.netfilter.nf_conntrack_icmp_timeout = 30
Bon la première chose à faire est de limiter le délai maximum d’une connexion de 432000 secondes (soit 120 heures ou 5 jours) à seulement 1 jour (ou moins).
Pour nf_conntrack :
# /sbin/sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=86400
Pour ip_conntrack :
# /sbin/sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established =86400
Ensuite si ce n’est pas déjà le cas augmenter le conntrack_max. Dans cet exemple je la passe à 131072 mais cela peut être beaucoup plus, tout dépend de la quantité de RAM que vous avez. Plus cette valeur sera élevée plus cela consommera de RAM.
Pour nf_conntrack :
# /sbin/sysctl -w net.netfilter.nf_conntrack_max=131072
Pour ip_conntrack :
# /sbin/sysctl -w net.ipv4.netfilter.ip_conntrack_max =131072
À présent il faut que vos configurations perdurent au prochain reboot. Pour cela rajouter les lignes précédentes dans le sysctl.conf.
# nano /etc/sysctl.conf
net.netfilter.nf_conntrack_max=131072.
net.netfilter.nf_conntrack_tcp_timeout_established=86400
net.ipv4.netfilter.ip_conntrack_max =131072
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established =86400
Enfin recharger la configuration sysctl.
# /sbin/sysctl -p
Bonjour
J’ai un probleme qui semble s’apparenter a ce que vous decrivez, mais j’aimerai savoir si vous pouvez confirmer mon analyse.
J’ai un serveur (ubuntu/apache2) sur lequel tournent des daemons backend codés en perl.
Ces daemons parsent des fichiers XML et produisent des fichiers en sortie vers /var/www/…
Quand la charge du serveur monte, j’ai une erreur d’acces fichier qui est la suivante : « Resource temporarily unavailable at /usr/lib/perl5/XML/LibXML.pm line 587. »
Et quand je regarde dans syslog je vois :
Jul 9 15:20:11 nsxxxxxxx kernel: __ratelimit: 933 callbacks suppressed
Jul 9 15:20:11 nsxxxxxxx kernel: nf_conntrack: table full, dropping packet.
N’étant pas expert en la matiere, pensez vous que la methode que vous decrivez pourrai être la solution à mon problème ?
Cordialement.
Pierre
Oui vous pouvez essayer. De toute manière cette méthode n’est pas dangereuse pour votre système. L’étape la plus critique étant le reboot de l’interface réseau.
Hello
Tu ne mets pas la même valeur à « net.ipv4.netfilter.ip_conntrack_tcp_timeout_established » selon que tu passes par la commande « /sbin/sysctl -w » ou l’édition de /etc/sysctl.conf , c’est normal ?
Sinon, lorsqu’on modifie justement ce fichier /etc/sysctl.conf : plutôt que de redémarrer l’interface réseau ( un peu violent pour les services web qui pourraient tourner sur la machine ) , il suffit de lancer la commande
sysctl -p
…pour que la configuration soit chargée.