Neste post de apoio ao vídeo, vamos proteger uma aplicação web com o AWS WAF. Vamos criar uma Web ACL associada a um Application Load Balancer, configurar regras próprias e regras gerenciadas da AWS, e depois ver os bloqueios acontecendo.
Para o laboratório usei o OWASP Juice Shop, uma aplicação propositalmente vulnerável que é ótima para testar WAF. Mostro como subir o seu neste post: Estudando Application Security com o OWASP Juice Shop na AWS.
O que é um WAF
Um WAF (Web Application Firewall) inspeciona o tráfego da camada 7, ou seja, HTTP e HTTPS, e decide se cada requisição pode ou não chegar à aplicação. Ele detecta e bloqueia ataques como SQL injection e XSS (Cross-Site Scripting), os mesmos que aparecem no OWASP Top 10.
No mercado existem várias opções, como Cloudflare, Akamai e soluções nacionais. O AWS WAF tem a vantagem de se integrar nativamente com os serviços da AWS.
Onde o AWS WAF pode ser usado
O AWS WAF se associa a recursos que recebem tráfego HTTP:
- Amazon CloudFront, na borda. Nesse caso a Web ACL é global e criada na região us-east-1.
- Application Load Balancer, que é o caso do vídeo.
- Amazon API Gateway (APIs REST). É assim que o WAF protege o projeto Score Trust: Score Trust: arquitetura serverless na AWS.
- AWS AppSync, Amazon Cognito, App Runner e Verified Access.
Um detalhe que confunde muita gente: para recursos regionais, como o ALB, a Web ACL precisa ser criada na mesma região do recurso. Selecione a região certa no console antes de começar.
Recursos AWS utilizados
| Recurso | Papel no laboratório |
|---|---|
| AWS WAF (Web ACL) | Conjunto de regras avaliadas em cada requisição |
| Application Load Balancer | Recurso protegido, na frente da aplicação. Veja como configurar: Como configurar o AWS Application Load Balancer com 2 target groups |
| Amazon EC2 | Instância rodando o OWASP Juice Shop |
| Regras gerenciadas da AWS | Grupos de regras prontos, mantidos pela AWS |
| Sampled requests e CloudWatch | Visualização das requisições permitidas e bloqueadas |
Passo a passo resumido
1. Criar a Web ACL
- Tipo de recurso: regional, na região do seu ALB.
- Associe o Application Load Balancer.
- Ação padrão: Allow. Tudo o que nenhuma regra bloquear passa. É o modelo mais comum: você libera por padrão e bloqueia o que é malicioso.
2. Regra de CAPTCHA em um path
A primeira regra customizada aplica um CAPTCHA no path /ftp do Juice Shop. Ao acessar esse caminho, o usuário precisa resolver o desafio antes de seguir.
O CAPTCHA serve bem para proteger formulários de login e de cadastro contra bots. Para um diretório que não deveria estar exposto, porém, não é a melhor solução. Por isso, no vídeo, troco essa regra por um bloqueio.
3. Bloquear um path sensível
Mesma condição (o URI path começa com /ftp), mas com ação Block. A requisição recebe 403 Forbidden e nem chega à aplicação. Esse tipo de regra serve para fechar rapidamente caminhos que ficaram expostos por engano, como painéis administrativos e backups, enquanto a correção definitiva não sai.
4. Bloquear o tráfego de fora do Brasil
Uma regra de geo match com a condição não originado do Brasil e ação Block. Se a sua aplicação atende só o público brasileiro, essa regra corta uma parte grande do tráfego automatizado e dos ataques oportunistas.
Cuidado com quem viaja ou usa VPN fora do país. Se isso for comum entre os seus usuários, considere usar a ação Count antes de bloquear.
5. Regras gerenciadas da AWS
A AWS mantém grupos de regras prontos, e vários deles são gratuitos (sem custo adicional por grupo). No vídeo adicionei proteção contra SQL injection com o grupo de banco de dados SQL. Outros que valem avaliar:
- Core rule set: cobre boa parte do OWASP Top 10.
- Known bad inputs: padrões de exploração conhecidos.
- Grupos por plataforma: Linux, Windows, PHP, WordPress. Use só os que fazem sentido para a sua stack.
- Amazon IP reputation list: IPs com histórico de atividade maliciosa.
Também existem regras pagas no AWS Marketplace, de fornecedores especializados.
6. Testar e observar
Com as regras ativas, simulei ataques de SQL injection e XSS no Juice Shop. Na aba Sampled requests da Web ACL dá para ver cada requisição: IP de origem, país, URI e qual regra bloqueou. É o que você usa para ajustar regras e investigar falsos positivos.
Boas práticas
- Comece em modo Count nas regras gerenciadas e acompanhe por alguns dias antes de bloquear. Assim você evita derrubar funcionalidades legítimas.
- Ordem das regras importa: as de Allow explícito (IPs internos, por exemplo) vêm antes; as mais baratas e mais restritivas, como as de geo e path, vêm em seguida.
- Rate-based rules limitam requisições por IP e são uma defesa simples contra força bruta.
- Habilite logs completos do WAF (CloudWatch Logs, S3 ou Firehose) para retenção e análise.
- Custo: o AWS WAF cobra por Web ACL, por regra e por milhão de requisições. CAPTCHA e alguns grupos gerenciados têm cobrança própria. Revise antes de deixar ligado.
- WAF não substitui código seguro. Ele é uma camada de defesa em profundidade, não a correção da vulnerabilidade.
Material de apoio
- Vídeo completo no canal: Como configurar o AWS WAF – Web Application Firewall
- Documentação oficial: Guia do desenvolvedor do AWS WAF
- OWASP Juice Shop, a aplicação usada nos testes
Ficou alguma dúvida sobre as regras? Deixe nos comentários.
Atualmente atua como Architecture Manager pela Atos Brasil, entusiasta Microsoft, FreeBSD e Debian, com mais de 20 anos de experiência em infraestrutura de T.I com ambientes heterogêneos, possuí o título de Microsoft Certified Trainer, AWS Community Builder, FinOps Member Foundation, Membro do comitê público do IDCIBER e especialista em segurança de perímetro, tendo atuado com soluções como Isa Server, iptables, IPFW, Cisco ASA, SonicWall, Fortigate, pfSense e soluções de Web Application Firewall.
Deixe um comentário