O F5 AWAF - Advanced (antigo BIG-IP ASM - Application Security Manager) pode definir uma política de segurança de forma declarativa, como um arquivo JSON que você mantém em controle de versão e importa no BIG-IP. Como a política é apenas um arquivo, ela se encaixa naturalmente em um pipeline de CI/CD (integração e entrega contínuas): puxe do Git, ajuste e envie de volta para o dispositivo.
O envelope
Toda a política vive sob um único objeto policy:
{ "policy": { "name": "my-app-policy", "template": { "name": "POLICY_TEMPLATE_FUNDAMENTAL" } } }
Dois campos são obrigatórios: name e template. Todo o resto é opcional.
Primeiro o template, depois os ajustes
O template é o ponto de partida. A F5 fornece vários, incluindo POLICY_TEMPLATE_RAPID_DEPLOYMENT, POLICY_TEMPLATE_FUNDAMENTAL, POLICY_TEMPLATE_COMPREHENSIVE e POLICY_TEMPLATE_API_SECURITY, cada um oferecendo um nível diferente de proteção padrão. O template faz o trabalho pesado; o resto da política apenas descreve o que deve diferir dele.
Sobre o template, a F5 distingue duas camadas de ajuste fino. A seção de ajustes (adjustments) contém atributos que sobrescrevem ou adicionam ao template, como tecnologias de servidor, URLs e parâmetros. As modificações (modifications) são o ajuste granular e frequente, como reduzir falsos positivos ou corrigir uma vulnerabilidade específica.
A regra que mais importa: ausente significa padrão
Todo ajuste é opcional, e esta é a coisa mais importante a entender ao ler uma política declarativa: se a política não inclui uma seção, os valores dessa seção vêm do template. Uma seção ausente não significa que uma proteção está desligada. Você não pode concluir que o Data Guard está desativado só porque data-guard está ausente; você só pode concluir isso se a política o desativar explicitamente. Leia uma política declarativa como um delta sobre o seu template, nunca como o quadro completo por si só.
As seções lógicas
A política é organizada em seções lógicas, cada uma com um propósito definido: enforcement (enforcementMode, signature-settings, policy-builder), contexto da aplicação (applicationLanguage, caseInsensitive, server-technologies), a superfície de tráfego (urls, parameters, filetypes, methods, headers, cookies) e proteções (blocking-settings, data-guard, brute-force-attack-preventions, csrf-protection e outras).
A F5 publica o schema completo, versionado da v16.0 à v17.5, no clouddocs. Ler uma política bem significa percorrer essas seções uma a uma, sempre lembrando que o que não está escrito é herdado.
Esta série, em ordem
Este artigo abre a série BIG-IP Advanced WAF. Seu modelo de template e ajustes é como toda política é lida; as partes constroem a política na ordem em que suas decisões entram em vigor (modo de enforcement, staging de assinaturas, análise de conteúdo, camadas), acrescentam as proteções que olham além de uma requisição (sessões, respostas, evasão, bots, inundações) e então tratam da operação: falsos positivos, a triagem de um bloqueio e o modo de aprendizado que um atacante consegue conduzir. Terminam com as duas perguntas de protocolo mais novas: o e o método QUERY.
- Blocking vs Transparent: o que o modo de enforcement do Advanced WAF realmente faz. Se a política protege ou apenas observa: o que os modos blocking e transparent realmente fazem com uma violação.
- Staging de assinaturas e o período de prontidão para enforcement. Uma assinatura nova casa e registra sem bloquear até ser revisada e o período de prontidão ter passado.
- Content profiles do Advanced WAF: como analisar JSON, XML, GraphQL e GWT com segurança. Como payloads JSON, XML, e GWT são analisados, para que as assinaturas se apliquem a campos e a estrutura seja imposta.
- Políticas aninhadas no Advanced WAF: herança pai/filho e microsserviços de política. Políticas pai e filho com herança obrigatória, e microsserviços de política: duas maneiras de empilhar em vez de uma política plana.
- Session Tracking do Advanced WAF: como encontrar e deter o cliente por trás das requisições. Identificar o usuário, a sessão, o dispositivo ou o endereço por trás de um fluxo de requisições, e agir sobre essa identidade.
- Data Guard: como mascarar dados sensíveis nas respostas. A proteção do lado da resposta que mascara números de cartão e outros padrões sensíveis antes que saiam.
- Técnicas de evasão: como o Advanced WAF normaliza a codificação do atacante. Codificações incomuns que escondem um payload de uma assinatura, e as subviolações de evasão que normalizam em volta delas.
- Sinais e desafios no lado do cliente: como o Advanced WAF distingue um navegador de um bot. O JavaScript injetado, a checagem de integridade e as sondagens de capacidade que distinguem um navegador real de automação.
- L7 Behavioral DoS (BaDoS): como o Advanced WAF aprende o normal e mitiga o resto. A defesa por aprendizado de máquina contra inundações na camada de aplicação: uma linha de base aprendida, o estresse do servidor e assinaturas geradas na hora.
- Como lidar com falsos positivos no Advanced WAF: triagem por rating, depois ajuste com escopo. Tráfego legítimo que dispara a política: triagem pelo rating da violação primeiro, depois o ajuste com o menor escopo possível.
- Por que o AWAF bloqueou, na ordem que responde mais rápido. Quatro perguntas na ordem que responde mais rápido: o que foi bloqueado, se estava errado, quanto confiar na assinatura, o que mudou.
- Aprendizado automático em produção: como um atacante envenena uma política de WAF. O aprendizado automático diante de tráfego não confiável, e como um atacante faz uma sugestão ser aceita na política.
- WAF sobre QUIC: proteção web HTTP/3 no BIG-IP 21.1. A mesma proteção web, defesa contra bots e proteção contra inundações estendidas a virtual servers HTTP/3, e os limites que restam.
- QUERY encontra o BIG-IP: LTM, iRules e o veredito do Advanced WAF. O novo método QUERY encontra o BIG-IP: deixado passar pelo profile HTTP, bloqueado pelo WAF como ilegal até ser permitido.
Fontes
O schema é publicado por versão do BIG-IP, portanto a faixa citada acima está visível no sumário, não é uma afirmação sobre ele.