A aritmética da state table: dimensionar uma firewall para floods, não para médias

Pergunte à maioria das pessoas de que tamanho precisa de ser uma firewall e respondem em largura de banda. Sob ataque, a largura de banda raramente é o que se esgota primeiro. A state table é: a lista de ligações que a firewall está a seguir, que tem um tamanho fixo, enche ao ritmo a que chegam novas ligações, e só esvazia tão depressa quanto os timeouts permitem. Perceba essa aritmética e consegue dimensionar uma firewall para o dia que conta em vez do dia médio.

Porque é que o state se esgota antes da largura de banda

Quando a tabela está cheia, as novas ligações são descartadas, legítimas ou não, mesmo que as ligações físicas estejam quase paradas.

Dois tipos de tráfego enchem uma tabela depressa:

• SYN floods. Cada SYN forjado cria uma entrada meio aberta que nunca se vai completar.
• UDP para serviços públicos. DNS, NTP, servidores de jogos, VoIP e serviços semelhantes veem números enormes de trocas curtas de muitas origens, e cada uma pode criar a sua própria entrada.

A aritmética

O número de entradas numa tabela em regime estacionário é, com boa aproximação:

entries  =  new flows per second  x  seconds each entry lives

É a lei de Little, e é todo o jogo. Suponha que um flood chega a 50.000 SYN novos por segundo, e que as entradas TCP meio abertas vivem 30 segundos. A tabela precisa de 1.500.000 entradas só para o ataque, antes de chegar qualquer utilizador real. Corte esse timeout para 5 segundos durante o flood e o mesmo ataque precisa de 250.000. A mesma firewall, a mesma memória, uma diferença de seis vezes feita por um único temporizador.

Há, portanto, apenas três alavancas: uma tabela maior (memória), tempos de vida mais curtos (timeouts), e menos entradas por fluxo (não seguir state onde não é preciso). Use as três.

Alavanca um: dimensione a tabela de propósito

Apure quanta memória a plataforma aloca por entrada de state, decida quanta da RAM da firewall está disposto a dar ao state, e defina o máximo a partir daí, em vez de viver com uma predefinição escolhida para um pequeno escritório. Depois crie um alarme muito antes de a tabela estar cheia.

Em OPNsense e firewalls baseadas em pf, os números em tempo real estão a um comando de distância:

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

Alavanca dois: adaptive timeouts e SYN cookies

Os timeouts estáticos são um compromisso entre ser simpático com clientes lentos e sobreviver a um flood. Os adaptive timeouts eliminam o compromisso: à medida que a tabela enche para lá de um limiar inicial, todos os timeouts encolhem linearmente, chegando a zero num limiar final. Nos dias normais mantêm-se temporizadores generosos; sob pressão as entradas expiram depressa. Em termos de pf:

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

Acrescente SYN cookies, idealmente num modo adaptativo que só liga quando a tabela ultrapassa um limiar. Com cookies, a firewall responde a um SYN sem criar state e só constrói uma entrada quando o cliente completa o handshake, coisa que uma origem forjada nunca faz. Isso transforma o ataque mais eficiente contra uma firewall stateful em tráfego de que a firewall mal dá conta.

Alavanca três: não siga o que não precisa de ser seguido

Para serviços UDP de grande volume, seguir cada troca compra quase nada: o serviço responde a partir de uma porta conhecida, e as regras são simples. Um par de regras stateless (permitir entrada para a porta do serviço, permitir saída a partir dela) não cria entrada nenhuma, pelo que um flood UDP não consegue esgotar a tabela por conta de um servidor DNS ou NTP. Reserve o tratamento stateful para TCP e para tudo em que o tráfego de retorno tenha de estar estritamente ligado a um pedido de saída.

Mantenha o state através de uma falha

Dimensionar é metade do trabalho; a outra metade é não o perder todo quando um nó falha. Num par ativo e standby, o CARP move os endereços virtuais para o standby, e o pfsync replica a state table entre os nós continuamente, sobre uma ligação dedicada sempre que possível. Quando o nó ativo morre, o standby já conhece todas as ligações estabelecidas, pelo que as sessões continuam em vez de cada utilizador voltar a ligar-se. Teste-o: inicie um download longo ou uma sessão SSH através do par, desligue o nó ativo, e veja-a continuar.

Dois hábitos práticos ajudam. Aplique as alterações de afinação primeiro no standby, verifique, depois faça failover e altere o outro nó; e distribua o processamento de pacotes pelos núcleos de CPU com contagens de threads adequadas a cada appliance, para que um núcleo ocupado não se torne o verdadeiro limite.

Ordene o ruleset para decisões baratas

Um flood é mais barato de descartar cedo. Ponha primeiro as decisões grosseiras e baratas: uma lista de bloqueio combinada de threat intelligence, depois bloqueios por país, depois gamas de hosting conhecidas por abusos, e só então as regras de permissão por host. Dê a cada alias e regra o nome do host que protege, para que o ruleset se documente a si próprio e as regras antigas possam ser removidas com confiança.

Verifique a sua própria firewall

• Qual é o limite da state table, e qual é o pico de hoje em percentagem dele?
• Há um alarme bem abaixo do limite?
• Estão configurados adaptive timeouts, e há SYN cookies disponíveis sob carga?
• Os serviços UDP de grande volume são tratados de forma stateless?
• Num par HA, o state está sincronizado, e já testou um failover com sessões ativas?
• Sabe o que um ataque a dez vezes o seu ritmo normal de ligações faria à tabela? Faça a multiplicação.

As nossas firewalls de perímetro em Atenas correm como pares stateful construídos e afinados desta forma, alterados apenas através da sua API. Se quer ajuda para fazer a aritmética para as suas, teremos todo o gosto em sentar-nos consigo.

Fale com um engenheiro

Relacionados: Managed firewalls de perímetro · Como alteramos as coisas: disciplina de alterações de rede · Monitorização de rede e evidências