Firewall Manager -- Alta latencia de ping -- ksoftirqd consumiendo mucha cpu 100% -- paquetes perdidos -- Alto número de reglas iptables

#1

1. Introducción

Este artículo describe cómo resolver un escenario donde un firewall basado en iptables, corriendo con #coreadmin-es dmin-es y usando Core-Admin FirewallManager y la herramienta IPBlocker, donde el firewall muestra un bajo rendimiento.

2. Síntomas

  1. Servidor linux ejecutando FirewallManager y la herramienta IpBlocker, basada en iptables que muestra procesos ksoftirqd consumiendo mucha cpu o el 100%.

  2. No paran de crecer los indicadores indicadores “dropped” en la tarjeta red al comprobarlos:

    >> ifconfig -a | grep dropped
    RX packets:55169628049 errors:0 dropped:30255399 overruns:0 frame:0
    TX packets:43640984422 errors:0 dropped:0 overruns:0 carrier:0
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    RX packets:43184969750 errors:0 dropped:121487666 overruns:0 frame:0
    TX packets:51691961677 errors:0 dropped:0 overruns:0 carrier:0
    RX packets:2126364061 errors:0 dropped:4388060 overruns:0 frame:0
    TX packets:3374447258 errors:0 dropped:0 overruns:0 carrier:0
    RX packets:62047417 errors:0 dropped:0 overruns:0 frame:0
    TX packets:62047417 errors:0 dropped:0 overruns:0 carrier:0

  1. La herramienta EthTool muestra que el contador de “no buffer rx available” está creciendo cada vez que se consulta:

    >> ethtool -S eth0 | grep buffer
    rx_no_buffer_count: 144683278
    >> ethtool -S eth0 | grep buffer
    rx_no_buffer_count: 144683377

  2. Tienes un gran número de reglas iptables, por encima de las 20.000:

    >> iptables -S | wc -l
    49560

  3. Tienes un gran número de reglas crad-ip-blocker.pyc que están causando un gran número de reglas iptables:

    >> crad-ip-blocker.pyc -l | grep 15612

  4. Estás viendo muchas interrupciones en /proc/interrupts, especialmente las asociadas a la tarjeta de red (IR-PCI-MSI-edge ethX) y al Local timer interrupts:

>> cat /proc/interrupts

  1. En tu log iptables, tienes mucho tráfico reportado como denegado:

    >> tail -f /var/log/kern.log

3. Análisis inicial

En este caso, si la mayoría de estos indicadores se cumplen, entonces es posible que su sistema esté bajo presión de alto número de conexiones denegadas de manera que la cadena iptables está tomándose demasiado tiempo para gestionar cada paquete de entrada, de manera que no es capaz de gestionar el tráfico.

4. Sobre el indicador dropped a nivel de tarjeta de red (ethtool o ifconfig)

De manera general, tu firewall no debería tener indicadores dropped o en todo caso, muy poco frecuentes en ninguna de sus tarjetas de red:

>> ifconfig -a | grep dropped

Incluso en el caso de que tenga un firewall iptables y/o un servicio QoS (basado en tc).

Tener indicadores dropped en su tarjeta de red indica que el driver/kernel/tarjeta no está siendo capaz de gestionar el tráfico porque está malformado, no hay suficiente espacio (buffer) para gestionarlo o algún procesado interno se está retrasando haciendo que el tráfico se encole, y finalmente se descarte (dropped).

Es importante entender que esta indicación dropped no tiene nada que ver con el descarte de iptables y/o tc (iptables DROP or tc drop).

La primera (indicación dropped de tarjeta de red) ocurre muy temprano antes de entrar dentro de iptables/tc. La segunda (descarte iptables) ocurre después y, en todo caso, si iptables descarta (dropped) algún tráfico, este no es contabilizado a nivel de tarjeta de red usando el indicador dropped que hemos viso (recuerda: ifconfig -a | grep dropped).

5. Un sistema sano no debe tener indicaciones dropped a nivel de tarjeta de red

Un sistema Linux, incluso bajo alta carga de tráfico denegado no debe tener indicadores dropped a nivel de tarjeta de red/driver/kernel (ifconfig -a | dropped).

Incluso en el caso de que tenga iptables y/o QoS (tc) descartando (dropping) paquetes debido a que su poĺítica no se cumple.

6. Cómo resolver esta incidencia

  1. Lo primero, reduzca el número de reglas de bloqueo que tiene instaladas con IPBlocker.
    Seleccione el listado de reglas que quiere que sean instaladas por unos pocos días y luego borradas:

    Posiblemente las instaló con la indicación permanente. En general, no se recomienda hacer bloqueo permanente: es mejor bloquear por algunos días para evitar tener el firewall cargando con un montón de reglas que realmente no son usadas.

    Para borrar reglas ip bloquer desde línea de comando, ejecute:

    # take a backup
    >> crad-ip-blocker.pyc -l > list-of-blocking-rules.txt

    # now remove rules
    >> for I in crad-ip-blocker.pyc -l | cut -f1 -d:
    do
    crad-ip-blocker.pyc -r $I
    done

  2. Después de eso, compruebe cuantas reglas tiene para determinar si ha reducido:

    >> iptables -S | wc -l

  3. En este punto, si todo fue correcto, debería haber recuperado el procesado normal del firewall:

    Si no, compruebe las reglas iptables -S para ver si son causadas por reglas de Firewall Manager u otro sistema/scripting que esté instalando reglas de bloqueo. Tiene que reducir el número de reglas de iptables.

  4. Si ha resuelto el problema, actualice el syn_floood_detect_checker para que le avise cuando el número de reglas iptables supere las 10.000 de manera que pueda hacer algo de limpieza antes de tener problemas:

    4.a) Pulse sobre acciones:

    image

    4.b) Ahora configurar comprobadores del agente:

    image

    4.c) Ahora pulse a configurar:

    image

    4.d) Introduzca el nuevo límite reducido:

    image

7. Qué cosas no funcionan en estos casos

a) Incrementar el tamaño del buffer RX de la tarjeta de red no resolverá el problema. En efecto, esto solucionará no perder paquetes pero incrementará la latencia debido a que el problema está localizado en el procesado y descartado de paquetes.

>> ethtool -G eth0 rx 4096

b) Instalar or reiniciar irqbalance.