Un problème assez fréquent lors de petit DDOS, ou de monté en charge de serveur.
Le module ip_conntrack ou nf_conntrack permet le suivi de connections lorsque l’on utilise netfilter. Dans cette table est écrit toutes les connections ouvertes ces 5 derniers jours. Cela peut poser un problème lorsque cette table est pleine. Aucune connections 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 par regarder les valeurs par default :
#/sbin/sysctl -a | grep conntrack
Ce qui devrait donner quelques 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 = 65536
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 = 65536
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 jours (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 à 64536 mais cela peut être beaucoup plus, tout dépend de la quantité de RAM que vous avez. Plus cette valeur sera élevé plus cela consommera de RAM.
Pour nf_conntrack :
# /sbin/sysctl -w net.netfilter.nf_conntrack_max=65536
Pour ip_conntrack :
# /sbin/sysctl -w net.ipv4.netfilter.ip_conntrack_max =65536
A présent il faut que vos configuration 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=65536.
net.netfilter.nf_conntrack_tcp_timeout_established=60
net.ipv4.netfilter.ip_conntrack_max =65536
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established =60
Enfin redémarrer votre interface réseau.
# /etc/init.d/network restart

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.