nf_conntrack: tabla llena, descargando paquete

15

Veo muchos de estos mensajes en / var / log / messages de mi servidor Linux

kernel: nf_conntrack: table full, dropping packet.
kernel: __ratelimit: 15812 callbacks suppresse

mientras mi servidor está bajo ataque DoS pero la memoria aún no está saturada. Me pregunto cuál es el significado del mensaje y cómo contrarrestar las posibles implicaciones de seguridad.

    
pregunta hnn 02.10.2013 - 07:44
fuente

3 respuestas

17

El mensaje significa que su tabla de seguimiento de conexiones está llena. No hay implicaciones de seguridad que no sean DoS. Puede mitigar parcialmente esto aumentando el número máximo de conexiones que se rastrean, reduciendo los tiempos de espera de seguimiento o desactivando el seguimiento de la conexión, lo que es factible en el servidor, pero no en un enrutador NAT, porque este último dejará de funcionar. >

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>
    
respondido por el Matrix 02.10.2013 - 10:13
fuente
5

Aquí hay un gran artículo que trata el tema. Básicamente, solo significa que la tabla que utilizan las tablas de IP (a través de APF o cualquier otra solución) para almacenar conexiones persistentes está llena. A expensas de la memoria puedes aumentarla.

enlace

    
respondido por el Matthew Salsamendi 03.10.2013 - 01:19
fuente
3

También sugeriría configurar las reglas del cortafuegos para que rechacen en lugar de eliminar

Una solución temporal, si necesita mantener las reglas de NAT de iptables es:

 linux:~# sysctl -w net.netfilter.nf_conntrack_max=131072

Digo temporal, porque el aumento de nf_conntrack_max no garantiza que las cosas salgan bien de ahora en adelante. Sin embargo, en muchos servidores que no tienen mucho tráfico, solo el aumento de net.netfilter.nf_conntrack_max=131072 a un valor suficientemente alto será suficiente para resolver el problema.

- Aumentar el tamaño de la tabla hash nf_conntrack

El valor de hashsize de la tabla Hash, que almacena las listas de entradas conntrack, debe incrementarse de manera apropiada, siempre que se genere net.netfilter.nf_conntrack_max.

linux:~# echo 32768 > /sys/module/nf_conntrack/parameters/hashsize

La regla para calcular el valor correcto para establecer es:

hashsize = nf_conntrack_max / 4

- Para almacenar permanentemente los cambios realizados; a) poner en /etc/sysctl.conf:

linux:~# echo 'net.netfilter.nf_conntrack_count = 131072' >> /etc/sysctl.conf
linux:~# /sbin/sysct -p

b) coloque /etc/rc.local (antes de la línea de salida 0):

echo 32768 > /sys/module/nf_conntrack/parameters/hashsize

Nota: Tenga cuidado con esta variable, ya que mi experiencia al aumentarla a un valor demasiado alto (especialmente en los núcleos parcheados XEN) podría congelar el sistema. También elevar el valor a un número demasiado alto puede congelar un servidor Linux normal que se ejecuta en hardware antiguo.

- Para el diagnóstico de nf_conntrack stuff existe;

/proc/sys/net/netfilter memoria almacenada en el kernel del directorio. Allí puede encontrar algunos valores almacenados dinámicamente que brindan información sobre las operaciones nf_conntrack en "tiempo real":

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. Disminución de otros valores de tiempo de espera de NAT nf_conntrack para evitar que el servidor contra ataques DoS

En general, el valor predeterminado para nf_conntrack_* de tiempo de espera es (innecesario) grande.

Por lo tanto, para grandes flujos de tráfico, incluso si aumenta nf_conntrack_max , aún en corto, puede obtener una tabla de desbordamiento de nf_conntrack que resulta en la caída de las conexiones del servidor. Para que esto no suceda, verifique y disminuya los otros valores de seguimiento de la conexión nf_conntrack timeout:

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

Todos los tiempos de espera son en segundos. net.netfilter.nf_conntrack_generic_timeout como ves es bastante alto - 600 segundos = (10 minutos). ¡Este tipo de valor significa que cualquier conexión NAT-ted que no responda puede permanecer pendiente durante 10 minutos!

El valor net.netfilter.nf_conntrack_tcp_timeout_established = 432000 también es bastante alto (¡5 días!) Si no se bajan estos valores, el servidor será un objetivo fácil para cualquier persona que quiera inundarlo con conexiones excesivas; una vez que esto ocurra, el servidor alcanzará rápidamente el valor elevado para net.nf_conntrack_max y la caída inicial de la conexión volverá a aparecer. -volver a repetir ...

Dicho todo esto, para evitar que el servidor tenga usuarios malintencionados, situados detrás del NAT que lo atormenta con ataques de Denegación de Servicio:

Bajar net.ipv4.netfilter.ip_conntrack_generic_timeout a 60 - 120 segundos y net.ipv4.netfilter.ip_conntrack_tcp_timeout_established a algo así como 54000

linux:~# sysctl -w net.ipv4.netfilter.ip_conntrack_generic_timeout = 120
linux:~# sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 54000

Este tiempo de espera debería funcionar bien en el enrutador sin crear interrupciones para los usuarios normales de NAT. Después de cambiar los valores y monitorear durante al menos unos días, haga los cambios permanentes agregándolos a /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

de acuerdo con el impresionante artículo en enlace

    
respondido por el Sandri_Nenes 04.04.2016 - 11:56
fuente

Lea otras preguntas en las etiquetas