Equilíbrio entre gravação e bloqueio no WAF

Informatec Digital » Recursos » Equilibrando registro e bloqueio em WAF

Encontrar o equilíbrio certo entre registro e bloqueio em um WAF tornou-se um dos maiores desafios para as equipes de segurança e operações. Um firewall de aplicações web pode impedir ataques muito sérios, mas, se configurado de forma muito agressiva, pode bloquear compras legítimas, acessos ou chamadas de API. Se configurado de forma muito permissiva, acaba sendo quase puramente decorativo. A chave é ajustar cuidadosamente quando registrar, quando contabilizar, quando permitir e quando bloquear.

Neste artigo, vamos explorar como alcançar esse equilíbrio usando recursos modernos de WAF (listas de permissão, regras baseadas em frequência, modos de aprendizado, integração com SIEM, aprendizado de máquina etc.), com exemplos concretos do AWS WAF, ModSecurity, WAFs em nuvem e soluções locais . Você verá como limitar falsos positivos sem diminuir o nível de proteção, como organizar políticas por aplicação e como usar o registro de logs como um aliado, e não como uma fonte constante e incontrolável de ruído.

O que é um WAF e por que o registro é tão importante?

Um firewall de aplicações web atua como uma camada inteligente entre o usuário e o servidor , analisando o tráfego HTTP/HTTPS em tempo real. Ao contrário de um firewall de rede tradicional, que monitora portas e IPs, um WAF investiga mais a fundo: URLs, parâmetros, corpos de requisição, cabeçalhos, cookies, métodos HTTP e muito mais.

Sua missão é detectar e impedir ataques típicos da Camada 7 : injeção de SQL, XSS, LFI/RFI, ataques contra controle de acesso, abuso de API, raspagem agressiva, força bruta e até mesmo certos padrões de DDoS em nível de aplicação. Para isso, utiliza conjuntos de regras, assinaturas e políticas de segurança que são constantemente atualizadas.

O registro de logs é o outro lado da moeda. Cada decisão do WAF — permitir, bloquear ou apenas contabilizar — pode ser acompanhada por um evento detalhado nos logs . Esses logs permitem:

• Investigar incidentesReconstruir o que aconteceu e como foi feita uma tentativa de explorar uma vulnerabilidade.
• Ajustar regrasDetectar falsos positivos verificando quais solicitações legítimas o WAF está bloqueando.
• Cumprir as normasDemonstrar que existem controles ativos (PCI DSS, GDPR, auditorias internas, etc.).
• Alimentando um SIEMCorrelacionar ataques a aplicativos com eventos de rede, sistema, identidade, etc.

O problema é que um WAF mal configurado pode encher os logs com milhares de eventos irrelevantes , tornando impossível encontrar o que é importante e, além disso, causando rejeições injustificadas de tráfego legítimo. É aí que entra a arte de manipular os modos de registro, contagem e bloqueio.

Modelos de segurança em WAF: listas de bloqueio, listas de permissão e uma abordagem híbrida.

A maioria dos WAFs modernos combina diversas abordagens de filtragem, o que impacta diretamente a forma como as requisições são registradas e bloqueadas . De maneira geral, podemos identificar duas filosofias clássicas, além de um modelo híbrido bastante comum.

Um WAF baseado em listas de bloqueio segue um modelo de segurança negativa. Seu princípio fundamental é: "Permito tudo, exceto o que sei ser malicioso". Ele funciona usando assinaturas de ataques conhecidos (injeção de SQL, XSS, padrões de bots, etc.) e regras que definem o que é considerado suspeito. É mais fácil de implementar inicialmente, mas depender exclusivamente desse modelo acarreta o risco de permitir que novos vetores ou variantes de ataque passem despercebidos.

Um WAF com lista de permissões funciona de maneira oposta: "bloqueia tudo, exceto o que é explicitamente permitido". Ele se baseia em um modelo de segurança positivo. Somente o tráfego que se encaixa no comportamento legítimo definido — rotas, métodos, parâmetros, formatos, tamanhos etc. — é aceito. É muito mais seguro, mas requer ajustes significativos e pode gerar falsos positivos inicialmente se não for configurado corretamente.

Devido às vantagens e desvantagens de cada abordagem, um modelo híbrido que combina listas de permissão e listas de bloqueio está se tornando cada vez mais comum . Nesse cenário, perfis de tráfego esperados são definidos (por exemplo, o que constitui um login ou uma solicitação de pagamento normal), e assinaturas e heurísticas são aplicadas simultaneamente para detectar padrões maliciosos típicos. Para fins de registro, essa abordagem híbrida permite:

• Marcar como evento de alto risco aquilo que viola a lista de itens permitidos.
• Tratar como alertas de prioridade média/baixa Padrões gerais de listas de bloqueio.
• Use o modo "contagem" para ver o que violaria uma regra antes de ativar o bloqueio.

WAF na rede, no host e na nuvem: impacto no registro e bloqueio de logs

O modelo de implantação do WAF influencia significativamente a forma como o registro e o bloqueio de tráfego são gerenciados. Registrar solicitações em um dispositivo de rede não é o mesmo que registrá-las em um agente dentro do servidor ou em um serviço de nuvem gerenciado.

Um WAF baseado em rede é normalmente implementado como um dispositivo físico ou virtual dentro da infraestrutura, entre a internet e os aplicativos. Essa é a abordagem clássica usada por fabricantes como a F5. Ela oferece a vantagem de alto desempenho e controle granular , mas a configuração e o gerenciamento podem ser complexos. Os registros geralmente são enviados para o syslog ou para um SIEM central, e é importante filtrar cuidadosamente o que é salvo para evitar sobrecarregar o armazenamento e as ferramentas de análise, além de diagnosticar problemas em redes IP e DNS.

Os WAFs baseados em host são executados nos mesmos servidores (ou contêineres) onde reside a aplicação, normalmente como um módulo ou agente (por exemplo, ModSecurity integrado ao Nginx ou Apache; a combinação com o reforço de segurança do Linux usando SELinux melhora a postura de segurança). Esse modelo permite maior contexto da aplicação e regras altamente específicas por serviço, ao custo de consumir recursos locais e exigir um gerenciamento de logs mais distribuído. Os logs podem ser armazenados em arquivos locais e encaminhados posteriormente, ou integrados a serviços de registro centralizados.

Os WAFs baseados em nuvem (Cloudflare, Akamai, Imperva Cloud, AWS WAF, etc.) integram-se com balanceadores de carga, CDNs ou redes virtuais. Os provedores geralmente oferecem painéis de controle e exportação de logs para S3, BigQuery, syslogs remotos ou SIEMs. Em geral, são mais fáceis de configurar, mas você precisa adaptar suas políticas de registro ao modelo do provedor: tipos de eventos, períodos de retenção, filtros de severidade, etc.

A escolha entre um modelo e outro não é apenas uma decisão técnica, mas também uma questão de como você deseja equilibrar o registro e o bloqueio de dados: um serviço gerenciado na nuvem simplifica muitos aspectos, mas você pode querer controle absoluto sobre onde os registros são armazenados devido a políticas de conformidade ou confidencialidade, o que o leva a optar por modelos locais ou híbridos.

Termos, regras e ACLs da web: como o WAF decide se deve bloquear, permitir ou apenas registrar

Independentemente do fabricante, todos os WAFs modernos são baseados no conceito de condições de acesso, regras e políticas . Compreender isso é fundamental para usar com sucesso os modos de contagem, registro e bloqueio em produção.

As condições descrevem qual parte da solicitação é inspecionada: endereço IP de origem, cabeçalhos HTTP específicos (Host, User-Agent, Accept, Content-Type…), parâmetros de consulta, corpo da solicitação, cookies, método HTTP, país de origem, etc. Por exemplo, no AWS WAF Classic, você pode definir uma condição de IP com até 10.000 endereços ou intervalos, ou uma condição de correspondência de string em uma parte da URL.

As regras combinam uma ou mais condições e atribuem uma intenção: permitir, bloquear ou contar. Quando uma regra tem múltiplas condições, elas são normalmente avaliadas com um operador lógico AND : todas as condições devem ser atendidas para que a regra seja acionada. Uma regra normal, sem condições, na prática, não corresponde a nada e sua ação nunca é acionada.

Muitos WAFs, incluindo o AWS WAF, também possuem regras baseadas em taxa . Essas regras contabilizam as solicitações recebidas de um endereço IP (ou conjunto de endereços IP que atendam a determinadas condições) durante um período de tempo, por exemplo, cinco minutos. Se um limite for excedido — digamos, 1.000 solicitações em cinco minutos — a regra entra em vigor: bloqueando ou simplesmente contabilizando. Isso é muito útil para:

• controle ataque de força bruta em formulários de login.
• Limitar a coleta agressiva de dados ou o uso de bots grosseiros.
• Mitigar certos tipos de ataques DDoS no nível da aplicação.

O próximo nível é a ACL (Lista de Controle de Acesso) da Web . Nela, as regras são agrupadas e uma ordem de avaliação e uma ação padrão (PERMITIR ou BLOQUEAR) são definidas. Uma requisição passa pelas regras em ordem; se corresponder a alguma, a ação correspondente é aplicada e a avaliação das demais é interrompida. Se não corresponder a nenhuma regra, a ação padrão definida na ACL é aplicada.

Em termos de equilíbrio entre registro e bloqueio, a ACL é onde você decide se deseja que o sistema seja permissivo por padrão (PERMITINDO e bloqueando apenas por regras específicas) ou altamente restritivo (BLOQUEANDO, exceto em casos excepcionais). Além disso, muitas soluções permitem que você defina regras no modo "contagem" dentro da ACL, para que registrem as correspondências, mas não bloqueiem o tráfego — ideal para a fase de ajuste.

Listas brancas e redução de ruído em logs

As listas de permissão são uma ferramenta fundamental para reduzir falsos positivos e ruídos nos logs . A ideia é simples: em determinados contextos, você instrui o WAF a não aplicar uma diretiva ou conjunto de regras a um tráfego específico que você já categorizou como confiável ou que você sabe que está fora do padrão, mas é legítimo.

Por exemplo, no AWS WAF, você pode criar regras de lista de permissões para que, se uma solicitação vier de um endereço IP ou intervalo específico , ou se corresponder a um padrão de URL e método HTTP conhecidos, determinadas inspeções de assinatura não sejam aplicadas. Isso ajuda a:

• Impeça APIs internas que usem padrões "estranhos". gerar falsos positivos constantes.
• Reduza a latência introduzida pela inspeção profunda no tráfego que você já considera confiável.
• Reduza o volume de registros desnecessários nos logs do WAF.

Em plataformas como o ModSecurity, a abordagem recomendada não é modificar as regras padrão (por exemplo, o conjunto de regras principais da OWASP), mas sim criar exclusões específicas por ID de regra para determinados parâmetros, caminhos ou usuários. Isso permite manter a proteção geral sem criar grandes vulnerabilidades desativando regras inteiras em todo o site.

A chave é criar listas de permissões precisas , e não adotar uma abordagem genérica. É muito melhor excluir uma combinação específica (regra X + parâmetro Y na URL Z) do que desativar a regra X globalmente. Dessa forma, o registro de logs continua útil e você não cria pontos cegos desnecessários.

Regras e limites do protocolo: quando bloquear, quando advertir

Muitos WAFs incorporam um conjunto de regras de sanitização do protocolo HTTP que atuam como um primeiro filtro para tráfego malformado ou suspeito . Essas regras verificam cabeçalhos, métodos, tamanhos de argumentos obrigatórios, etc., e são uma fonte frequente tanto de boa proteção quanto de falsos positivos se não forem compreendidas corretamente.

Alguns exemplos muito comuns:

• Cabeçalho Accept ausente (Cabeçalho Accept ausente): Isso não é estritamente uma violação da RFC, mas muitas requisições sem esse cabeçalho vêm de ferramentas automatizadas ou scripts mal escritos. Isso pode afetar APIs personalizadas ou clientes que não o enviam. Em muitos ambientes, o registro e a contagem de requisições são preferíveis ao bloqueio direto.
• Cabeçalho do host ausenteDe acordo com os padrões HTTP/1.1, o cabeçalho Host é obrigatório. Os WAFs também precisam dele para determinar qual política aplicar. O bloqueio nesse cabeçalho geralmente é razoável, mas pode gerar falsos positivos durante testes ou devido a tráfego interno mal configurado; é recomendável monitorar os logs antes de habilitar o bloqueio estrito.
• Cabeçalho User-Agent ausenteEsta regra tenta conter bots rudimentares e tráfego não identificado. O problema é que muitas APIs legítimas podem não enviar um User-Agent. A abordagem mais sensata geralmente é registrar as atividades e, se uma API legítima e consistente for detectada, Adicione o endereço IP ou o padrão deles a uma lista de permissões..
• Validação GET/HEAD com corpoEmbora a RFC não proíba estritamente o envio do corpo da requisição com os métodos GET ou HEAD, essa não é uma prática comum e pode indicar tentativas de evasão. Em muitos casos, o primeiro passo é registrar todas essas requisições e, se forem consideradas anomalias suspeitas, bloqueá-las.
• Tipo de conteúdo ausente com corpoSe houver um corpo de requisição, mas nenhum Content-Type, isso indica claramente o uso inadequado do protocolo ou uma tentativa de burlar a análise. Nesses casos, uma abordagem de bloqueio mais agressiva geralmente faz sentido, especialmente em ambientes voltados para a internet.

Além dessas regras de protocolo, os limites de argumentos são frequentemente utilizados para proteger contra ataques de inundação e negação de serviço (DoS) em nível de aplicação. Por exemplo:

• Número máximo de argumentos por solicitação (por padrão, 255 em alguns WAFs).
• Comprimento máximo de um argumento individual (por exemplo, 400 caracteres).
• Tamanho total combinado de todos os argumentos (por exemplo, 64.000 bytes).

Esses valores são razoáveis ​​para muitas aplicações, mas existem casos — como o envio de formulários complexos, filtros avançados e grandes volumes de dados JSON — em que ocorrem falsos positivos. Nesses cenários, a abordagem mais prudente é começar registrando e contabilizando as requisições , analisar quais endpoints estão ultrapassando os limites e ajustar apenas as rotas correspondentes, em vez de remover todos os limites do site inteiro.

Falsos positivos: como detectá-los e não morrer tentando

Um falso positivo é uma solicitação legítima que o WAF identifica como maliciosa e bloqueia ou sinaliza como um ataque. Eles são inevitáveis, especialmente quando você tem conjuntos de regras abrangentes como o OWASP CRS ativados, mas podem ser gerenciados profissionalmente para que não se tornem uma dor de cabeça diária.

A detecção de falsos positivos começa com uma análise cuidadosa dos registros . Isso envolve examinar quais solicitações estão sendo bloqueadas, qual regra as aciona e o contexto em que ocorrem (URL, parâmetros, usuário, origem etc.). Ferramentas visuais e painéis podem ajudar a identificar picos de erros 403 ou padrões incomuns.

Uma abordagem altamente recomendada, tanto por provedores de nuvem quanto pela comunidade ModSecurity, é usar um modo de simulação ou contagem . Nesse modo, as regras que você deseja testar registram cada correspondência, mas não bloqueiam. Isso permite que você veja, por exemplo, quantas solicitações legítimas uma nova regra de SQLi teria bloqueado antes que você ousasse ativá-la em produção.

Também é uma boa ideia testar as regras em um ambiente de teste ou pré-produção que receba tráfego real ou simulado. Ferramentas como o OWASP ZAP ou scripts de reprodução de tráfego podem ajudar a simular padrões legítimos e ataques conhecidos para testar o comportamento do WAF.

Além disso, é crucial considerar o impacto operacional e reputacional dos falsos positivos: interrupções de pagamento, falhas no cadastro de usuários, chamadas críticas de API que falham sem explicação — tudo isso pode ter um custo direto em receita e imagem da marca. Um excesso de falsos positivos também sobrecarrega a equipe de segurança com alertas que não agregam valor, dificultando a identificação de incidentes genuínos.

Estratégias para ajustar regras e uso inteligente do registro

Gerenciar falsos positivos não se resume a desativar regras até que "tudo funcione", mas sim a ajustar o WAF com precisão cirúrgica . É aqui que boas práticas como as seguintes entram em jogo:

Primeiramente, evite desativar regras globalmente. É preferível criar exceções bem específicas : exclua o ID da regra apenas para uma rota específica, para determinados parâmetros ou para tráfego interno. Dessa forma, você mantém a proteção no restante da aplicação e preserva registros úteis.

Em segundo lugar, aproveite o modo de contagem antes de bloquear. Ativar novas regras inicialmente apenas no modo de registro permite medir quantas solicitações legítimas seriam afetadas. Você pode complementar isso com alertas no SIEM para detectar rapidamente se uma regra está gerando um volume anormal de correspondências.

Em terceiro lugar, integre o WAF com um SIEM ou plataforma de registro centralizada . Isso facilita a correlação de eventos do WAF com outros indicadores: atividade incomum do sistema, falhas de autenticação em massa, alterações de configuração suspeitas, etc. Também ajuda a priorizar quais regras ajustar primeiro com base na gravidade e frequência dos eventos.

Em quarto lugar, documente cada alteração: qual regra foi ajustada, para qual endpoint, com qual justificativa e com quais evidências. Consultar os manuais do servidor pode ser útil para isso. Essa documentação não só ajuda a manter o controle interno, como também é inestimável em auditorias e revisões de segurança, onde você precisa demonstrar que os controles não são desativados levianamente.

Automação, aprendizado de máquina e regras adaptativas no WAF

À medida que as aplicações crescem e o tráfego se torna mais complexo, gerenciar o WAF manualmente torna-se inviável. É aí que entram em cena a automação, a análise avançada de logs e, em alguns casos, o aprendizado de máquina.

Em primeiro lugar, a integração com o SIEM permite criar regras de correlação e respostas automatizadas : por exemplo, se um conjunto de IPs acionar repetidamente regras de injeção ou XSS, você pode gerar uma ação automática para adicionar esses IPs a uma lista de bloqueio temporária ou reforçar o nível de inspeção.

Em segundo lugar, alguns WAFs incorporam modos de aprendizado de máquina que observam o tráfego legítimo durante um período definido. Com base nesses dados, eles propõem ou ajustam limites, padrões e perfis de comportamento normal. Isso ajuda a reduzir falsos positivos quando as regras são ativadas no modo de bloqueio e a detectar desvios de tráfego subsequentes.

Em ambientes de pesquisa e laboratório, técnicas de aprendizado supervisionado têm sido usadas para treinar modelos que distinguem entre tráfego legítimo e malicioso, refinando políticas que são então utilizadas em produção. Embora não seja uma solução mágica, essa abordagem pode ajudar a descobrir padrões sutis que as regras clássicas baseadas em assinaturas não detectam facilmente.

Por fim, os testes automatizados contínuos (usando ferramentas como OWASP ZAP, scripts personalizados ou pipelines de CI/CD) permitem validar se as alterações no WAF não comprometem funcionalidades críticas nem deixam vulnerabilidades óbvias. Integrar esses testes ao ciclo de implantação torna a segurança uma parte natural do fluxo de desenvolvimento, em vez de uma correção de última hora.

Políticas definidas por aplicação e listas negras por serviço

Em ambientes complexos — por exemplo, um provedor de hospedagem ou um provedor de serviços de internet (ISP) — uma única política de WAF não é suficiente, especialmente quando há TI paralela envolvida . É comum ter vários domínios ou aplicativos por trás do mesmo balanceador de carga, cada um com diferentes necessidades de segurança e perfis de tráfego . É aqui que o desenvolvimento de políticas e listas específicas para cada serviço se torna essencial.

Um exemplo ilustrativo é um balanceador de carga HTTP/S atuando como um proxy reverso para múltiplos sites (por exemplo, www.company1.com e www.company2.com) por trás de um único endereço IP virtual. Nesse cenário, o WAF pode ser configurado para avaliar o cabeçalho Host e o endereço IP de origem assim que a requisição chegar, mesmo antes de atingir o módulo de balanceamento de carga.

A lógica seria algo como isto: o WAF verifica se a combinação de SERVER_NAME (Host) e IP do cliente corresponde a uma lista negra específica do site. Se o IP estiver listado como bloqueado para www.company2.com, mas não para www.company1.com, uma resposta 403 Forbidden é enviada apenas no primeiro caso. O tráfego "limpo" é então passado para o módulo de balanceamento de carga, que decide qual servidor de backend atenderá a solicitação.

Isso permite manter, por exemplo, listas negras específicas de domínio , em vez de uma única lista global para todo o ponto de acesso. No nível de registro, cada rejeição é registrada no syslog com detalhes como o ID da regra, a condição correspondida, a URL, o host e o endereço IP do cliente, facilitando a análise subsequente e a expansão ou depuração dessas listas.

A moral da história é que quanto mais segmentadas forem suas políticas (por aplicativo, por ambiente, por tipo de usuário), mais preciso será o equilíbrio entre registro e bloqueio: você pode ser muito rigoroso em portais administrativos e um pouco mais flexível em sites informativos, por exemplo, sempre com evidências nos registros do motivo de cada decisão tomada.

Além do WAF clássico: WAAP e proteção de API

O cenário de ameaças não parou de evoluir. Hoje, muitas aplicações são nativas da nuvem, utilizam arquiteturas de microsserviços e expõem APIs públicas e privadas , tornando-as alvos principais para atacantes. Os WAFs tradicionais evoluíram para plataformas mais abrangentes conhecidas como WAAP (Web Application and API Protection) ou WAAS (Web Application & API Security).

Essas soluções não apenas descobrem automaticamente aplicativos da web, mas também identificam endpoints de API , aceitam especificações como OpenAPI ou Swagger e usam essa definição para verificar a conformidade da solicitação: tipos de dados esperados, parâmetros permitidos, limites de tamanho etc. Dependendo do endpoint (por exemplo, um que lida com dados altamente sensíveis), um nível muito maior de análise e bloqueio pode ser aplicado.

No nível de registro de logs, o WAAP tende a gerar eventos ricos em contexto : qual endpoint exato da API foi atacado, qual operação (GET, POST, PUT…), qual usuário ou token estava envolvido, qual parte da especificação foi violada, etc. Isso permite decisões de bloqueio mais precisas, em vez de depender apenas de padrões genéricos de payload.

Além disso, muitas ferramentas WAAP incluem proteção contra DoS específica para aplicativos e APIs, filtragem por geolocalização, gerenciamento de reputação de IP, detecção de bots e scraping, e opções para personalizar os níveis de alerta por serviço. Novamente, trata-se de ter a flexibilidade para decidir onde você deseja uma abordagem mais robusta e onde deseja priorizar a operação tranquila , sem sacrificar um banco de dados de logs sólido para investigar eventuais incidentes.

Em conjunto, um WAF bem configurado — seja ele clássico, baseado em WAAP ou integrado a um ecossistema de nuvem — torna-se um componente essencial da defesa moderna de aplicações e APIs, capaz de combinar registro detalhado, bloqueio inteligente e adaptação contínua ao cenário de ameaças em constante mudança.