La aritmética de la tabla de estados: dimensionar un firewall para floods, no para medias

Pregunte a la mayoría de la gente cómo de grande tiene que ser un firewall y le responderán en ancho de banda. Bajo ataque, el ancho de banda rara vez es lo primero que se agota. Lo es la tabla de estados: la lista de conexiones que el firewall está siguiendo, que tiene un tamaño fijo, se llena al ritmo al que llegan conexiones nuevas y se vacía solo tan rápido como lo permiten los timeouts. Entienda esa aritmética y podrá dimensionar un firewall para el día en que importa en lugar de para el día medio.

Por qué el estado se agota antes que el ancho de banda

Cuando la tabla está llena, las conexiones nuevas se descartan, legítimas o no, aunque los enlaces estén casi ociosos.

Dos tipos de tráfico llenan una tabla deprisa:

• SYN floods. Cada SYN falsificado crea una entrada half-open que nunca se completará.
• UDP hacia servicios públicos. DNS, NTP, servidores de juegos, VoIP y servicios parecidos ven enormes cantidades de intercambios cortos desde muchos orígenes, y cada uno puede crear su propia entrada.

La aritmética

El número de entradas en régimen estacionario de una tabla es, con buena aproximación:

entries  =  new flows per second  x  seconds each entry lives

Esa es la ley de Little, y es todo el juego. Suponga que llega un flood de 50.000 SYN nuevos por segundo, y que las entradas TCP half-open viven 30 segundos. La tabla necesita 1.500.000 entradas solo para el ataque, antes de que llegue ningún usuario real. Recorte ese timeout a 5 segundos durante el flood y el mismo ataque necesita 250.000. El mismo firewall, la misma memoria, una diferencia de seis veces conseguida con un solo temporizador.

Así que solo hay tres palancas: una tabla mayor (memoria), vidas más cortas (timeouts) y menos entradas por flujo (no seguir el estado en absoluto donde no hace falta). Use las tres.

Palanca uno: dimensione la tabla a propósito

Calcule qué memoria asigna la plataforma por entrada de estado, decida cuánta de la RAM del firewall está dispuesto a dedicar al estado y fije el máximo a partir de ahí, en lugar de vivir con un valor por defecto elegido para una oficina pequeña. Después ponga una alarma mucho antes de que la tabla se llene.

En OPNsense y en firewalls basados en pf los números en vivo están a un comando de distancia:

pfctl -si | grep -A4 "State Table"
pfctl -sm | grep states

Palanca dos: timeouts adaptativos y SYN cookies

Los timeouts estáticos son un compromiso entre ser amable con los clientes lentos y sobrevivir a un flood. Los timeouts adaptativos eliminan el compromiso: a medida que la tabla se llena por encima de un umbral inicial, todos los timeouts se reducen linealmente, hasta llegar a cero en un umbral final. Los días normales conservan temporizadores generosos; bajo presión las entradas caducan rápido. En términos de pf:

set limit states 2000000
set timeout { adaptive.start 1200000, adaptive.end 2200000 }

Añada SYN cookies, idealmente en un modo adaptativo que se active solo cuando la tabla cruce un umbral. Con cookies, el firewall responde a un SYN sin crear estado y solo construye una entrada cuando el cliente completa el handshake, cosa que un origen falsificado nunca hace. Eso convierte el ataque más eficiente contra un firewall stateful en tráfico que el firewall apenas nota.

Palanca tres: no siga lo que no necesita seguimiento

Para servicios UDP de alto volumen, seguir cada intercambio no compra casi nada: el servicio responde desde un puerto conocido, y las reglas son simples. Una pareja de reglas sin estado (permitir entrada hacia el puerto del servicio, permitir salida desde él) no crea ninguna entrada, así que un flood UDP no puede agotar la tabla en nombre de un servidor DNS o NTP. Mantenga el tratamiento stateful para TCP y para todo aquello en lo que el tráfico de vuelta deba estar estrictamente ligado a una petición saliente.

Conserve el estado a través de un fallo

Dimensionar es la mitad del trabajo; la otra mitad es no perderlo todo cuando falla un nodo. En un par activo y standby, CARP mueve las direcciones virtuales al standby, y pfsync replica la tabla de estados entre los nodos de forma continua, por un enlace dedicado siempre que sea posible. Cuando el nodo activo muere, el standby ya conoce cada conexión establecida, así que las sesiones continúan en lugar de que todos los usuarios tengan que reconectar. Pruébelo: inicie una descarga larga o una sesión SSH a través del par, apague el nodo activo y vea cómo sigue.

Dos hábitos prácticos ayudan. Aplique los cambios de ajuste primero al standby, verifique, después haga el failover y cambie el otro nodo; y reparta el procesamiento de paquetes entre los núcleos de CPU con recuentos de hilos ajustados a cada appliance, para que un núcleo ocupado no se convierta en el límite real.

Ordene el conjunto de reglas para decisiones baratas

Un flood es más barato de descartar pronto. Ponga primero las decisiones gruesas y baratas: una lista de bloqueo combinada de inteligencia de amenazas, después bloqueos por país, después rangos de hosting abusivos conocidos, y solo entonces las reglas de permiso por host. Nombre cada alias y cada regla por el host que protege, para que el conjunto de reglas se documente solo y las reglas antiguas puedan retirarse con confianza.

Compruebe su propio firewall

• ¿Cuál es el límite de la tabla de estados, y cuál es el pico de hoy como porcentaje de ese límite?
• ¿Hay una alarma muy por debajo del límite?
• ¿Están configurados los timeouts adaptativos, y hay SYN cookies disponibles bajo carga?
• ¿Se tratan sin estado los servicios UDP de alto volumen?
• En un par HA, ¿se sincroniza el estado, y ha probado un failover con sesiones en vivo?
• ¿Sabe qué le haría a la tabla un ataque a diez veces su tasa normal de conexiones? Haga la multiplicación.

Nuestros firewalls perimetrales de Atenas funcionan como pares stateful construidos y ajustados de esta manera, y se cambian solo a través de su API. Si quiere ayuda para hacer la aritmética de los suyos, con gusto nos sentamos con usted.

Hable con un ingeniero

Related (rows[1])

Relacionado: Firewalls perimetrales gestionados · Cómo cambiamos las cosas: disciplina de cambios en la red · Monitorización de red y evidencias