1. Introducción
A continuación se explica con detalle la capacidad que tiene FirewallManager de Core-Admin para aplicar bloqueo prioritario de tráfico de manera que, para firewalls complejos y con muchas reglas, es posible descartar tráfico rápidamente a la entrada del sistema iptables (en la tabla raw), de cara a poder bloquear tráfico en condiciones de alta carga o ataques
.
2. Funcionamiento por defecto
Por defecto, #FirewallManager funciona del siguiente modo:
-
Todo el tráfico por defecto, está bloqueado
-
Para el resto de tráfico que se quiera autorizar, el administrador tiene que añadir una regla.
Este modo de funcionar es el habitual en firewalls. Nada más arrancar se bloquea todo y queda autorizado sólo lo que se haya configurado explícitamente.
En este esquema, el tráfico que se autoriza sigue la siguiente ruta de funcionamiento:
Como se puede observar en este esquema simplificado, el tráfico autorizado tiene que llegar hasta la tabla filter donde se instalan todas las reglas de autorización. En cuanto el tráfico llega a una regla de autorización que encaja (), entonces el tráfico se acepta.
Para el caso de tráfico denegado (), el esquema de funcionamiento por defecto es el siguiente:
3. Comparativa de rendimiento de tráfico autorizado vs. tráfico denegado
Como se puede ver para el tráfico autorizado (), la ruta de gestión es más corta en términos generales (por tanto es más eficiente).
Sin embargo, para el tráfico denegado (), la ruta de gestión siempre es más larga y más costosa.
Efectivamente, el tráfico denegado tiene que:
-
Recorrer todas las reglas de autorización de principio a fin, hasta llegar a la política de rechazo por defecto al final de toda la cadena (DROP).
-
Al mismo tiempo, a pesar de que es tráfico que será denegado, se activan todas las opciones de connection tracking
que tiene iptables/netfilter para la gestión de sesión (lo cual usa aún más recursos si cabe).
4. Por qué es importante entender cómo funciona el tráfico bloqueado en un firewall con estado en Linux
Como se puede observar, la ruta de gestión de tráfico bloqueado es más costosa tanto en tiempo como en consumo de memoria y cpu. Si se producen algunas o varias de las siguientes condiciones, el firewall puede tener problemas para gestionar el tráfico, llegando a comenzar a descartar tráfico, degradando el servicio o incluso, llegar a tumbarlo:
-
Alta carga
(gran número de sesiones sobre todo para tráfico TCP/UDP) -
Gran número de reglas de autorización iptables
de manera que de produce un efecto multiplicador 
por cada paquete a gestionar: simplificando, 15.000 reglas de firewall implica revisar 15.000 reglas por cada paquete a bloquear. -
Dado que el tráfico se deniega al final de la tabla filter, esto implica activar las opciones de connection tracking
(una de las grandes características del la maquinaria NetFilter para crear firewalls con estado).Debido a que es un firewall con estado, el connection tracking se activa, reserva recursos, contabiliza e inspecciona, resultado: más coste de cpu y de entrada/salida para gestionar interrupciones (ksoftirqd high cpu utilization).
5. Reglas prioritarias para descartar tráfico de manera efectiva
De manera general, no es necesario prestar atención al tráfico denegado.
Sin embargo, ahora ya sabe que en ciertas condiciones, mencionadas en el punto anterior, necesitará una opción que le permita descartar tráfico de manera temprana y prioritaria. Cuanto antes sea descartado, menor coste de gestión tendrá para su firewall Linux.
-
Para configurar una regla de descarte prioritario, cambie la opción por defecto en la acción para la regla a “descartar”
: -
Al configurar una regla con la opción “descartar”, creará una regla de bloqueo/descarte de tráfico prioritario. Esto es debido a que la regla será instalada en la tabla raw. Esto implica que será evaluada en fase de pre-rutado, mucho antes de entrar en la gestión de la tabla filter, evitando el procesamiento de dicha tabla, y de las tablas nat y mangle, así evita activar el connection tracking para dicho tráfico:
-
Efectivamente, este mecanismo le permite separar las reglas de bloqueo (activas y evaluadas antes) de las reglas de autorización (que habitualmente son mucho más numerosas).
-
RECUERDE: Mientras el tráfico denegado no le cause problemas, no pierda el tiempo describiendo reglas de descarte. No lo necesita ya que FirewallManager descartará todo lo que no esté autorizado.
Instale reglas de descarte sólo cuando necesite rechazar tráfico que le esté causando problemas de rendimiento.
6. ¿Cómo saber si cierto tráfico está causando problemas?
Todo tráfico que le cause problemas de procesamiento para su firewall seguirá los siguientes patrones:
-
Es tráfico que no ha autorizado y por tanto está siendo denegado por su firewall.
-
Es tráfico abundante, no habitual, muchas sesiones, muchas ips, no limitado pero habitualmente de tipo UDP o TCP (use tcpdump).
-
Es tráfico que está causando gran uso de recursos en el connection tracking. Use los siguientes comandos para inspeccionar las tablas de connection tracking para detectar grupos anómalos o que no encajen con su escenario:
>> conntrack -L >> crad-conntrack.pyc -
Otro indicio de problemas de gestión es que los procesos ksoftirqd de su kernel Linux comienzan a usar mucha CPU. Además, si analiza el contenido del /proc/interrupts puede comprobar fácilmente que tiene un elevado conteo en las interrupciones asociadas a sus tarjetas de red:
>> cat /proc/interrupts -
Normalmente estos problemas aparecen con firewalls que tienen muchas reglas (por encima de las 5000 reglas iptables). Compruebe y contabilice con:
>> iptables -S | wc -l >> iptables -S -t raw | wc -lUse también los indicadores del comprobador syn_flood_checker:
Pinche en mostrar comprobadores:
A continuación consulte el estado de su comprobador:
7. Qué no funciona
A continuación algunas notas sobre lo que no funcionará a la hora de gestionar alta carga de tráfico denegado:
-
No funcionará rebalancear las interrupciones que ya le está gestionando el servicio irqbalance. No toque su configuración: ya incluye una sabiduría que dificilmente superará cambiando las máscaras, añadiendo o quitando cpus asociadas a las tarjetas de red.
Es más, si no tiene instalado irqbalance, instalelo lo antes posible.
El problema no es irqbalance o el número de interrupciones. El problema es que se están generando demasiadas interrupciones, además de un alto consumo de cpu/por-paquete debido a que hay que procesar un altísimo conjunto de reglas.
8. Detalle de cómo se relacionan las tablas raw y filter (fases de activación)
Referencia: