Firewall ou WAF: o que cada um vê e o que cada um trava

O que decide uma firewall stateful

Uma firewall de Layer 3/4 acompanha ligações e julga cada ligação nova pelos seus endereços, pela sua porta e pelo estado do fluxo a que pertence. O Cisco Firepower, o OPNsense e o netfilter fazem-no todos bem: uma porta que nenhuma regra abre está fechada, uma resposta só é permitida para uma ligação iniciada de dentro, e as portas de gestão só respondem às gamas que estão na allow-list. A sua visão termina na camada de transporte. Com TLS no caminho não consegue ver nada dentro do payload, a menos que termine a sessão, e mesmo em tráfego em claro não tem qualquer noção de URL, cabeçalho, código de resposta ou login.

O que um WAF acrescenta

Uma web application firewall lê a transação HTTP depois da terminação do TLS, o que na prática significa que vive dentro ou ao lado do reverse proxy. Acrescenta três tipos de controlo que a firewall não consegue exprimir. As regras de assinaturas, como o ModSecurity com o OWASP Core Rule Set, detetam injection, traversal e payloads de exploits conhecidos dentro do pedido. As regras de comportamento contam por cliente e por caminho: pedidos por minuto na rota de login, respostas de login falhado por endereço, sinais de bot nos cabeçalhos e nos tempos. As regras positivas declaram o que um caminho aceita, como que métodos, que tipos de conteúdo e que tamanho de corpo, e recusam o resto.

Um WAF não substitui a firewall. Só vê o tráfego que chega até ele, e não sabe nada sobre SSH, portas de bases de dados ou o plano de gestão.

Onde o abuso do login se torna visível

Um login falhado é um facto na resposta. A aplicação responde a um POST para o caminho de login com um código ou um redirecionamento que distingue a falha do sucesso, e o proxy escreve isso no seu access log em cada tentativa. Contar as falhas por cliente por minuto é uma linha de awk sobre esse log, e é o sinal que um packet filter não tem forma de ver.

O controlo tem de estar associado ao cliente, não à conta. O bloqueio de conta, por si só, trava as tentativas contra um username e tranca o seu dono do lado de fora, enquanto o bot passa ao nome seguinte da lista. Um rate limit por cliente na rota de login faz o que o bloqueio não consegue:

# nginx: at most 5 login attempts a minute per client, small burst allowed
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location = /login {
    limit_req zone=login burst=5 nodelay;
    proxy_pass http://app;
}

O HAProxy exprime a mesma ideia com uma stick table associada ao endereço de origem, e um conjunto de regras de WAF pode contar diretamente o código de resposta do login falhado.

Como os dois encaixam

A ordem é firewall, depois terminação do TLS e o proxy com as suas regras de WAF, depois a aplicação. A deteção pertence ao Layer 7, porque é aí que está a evidência. A imposição pode ficar em qualquer uma das camadas. O proxy pode responder ao cliente infrator com um 429 ou um 403 no pedido seguinte, o que chega para a maioria dos abusos. Para um cliente que insiste, o proxy pode empurrar o endereço para a tabela dinâmica do packet filter por um período definido, o que também descarta as outras ligações desse cliente e não custa nada à firewall por pacote.

Dois pontos de desenho vêm antes de armar esse ciclo de retorno. As gamas de gestão e de monitorização do operador entram primeiro na allow-list, para que um teste ou uma gralha não possam trancar do lado de fora as pessoas que operam a plataforma. E os endereços partilhados existem: um NAT de escritório ou um carrier-grade NAT põe muita gente atrás de um único endereço, por isso os bloqueios têm validade curta e uma forma documentada de os levantar. Toda a cadeia é depois testada a partir de um host fora da rede, tal como um atacante a encontraria, antes de alguém confiar nela.

O que nenhum dos dois vê

Uma palavra-passe correta. O credential stuffing com uma palavra-passe válida que vazou parece um login bem-sucedido a todas as camadas. Essa lacuna fecha-se com autenticação multifator na conta e com a allow-list dos caminhos administrativos na firewall, para que uma credencial válida seja inútil a partir de um endereço que não é seu.