Introdução
A segurança de aplicações web é uma prioridade crescente à medida que as ameaças cibernéticas evoluem. Neste contexto, o uso de um Web Application Firewall (WAF) em arquiteturas baseadas na AWS tornou-se uma prática recomendada. No entanto, mesmo com a implementação de um WAF, a configuração inadequada de componentes como o AWS CloudFront e o Application Load Balancer (ALB) pode deixar sua aplicação vulnerável a ataques, permitindo que hackers contornem essas proteções.
Este artigo explora em detalhes como uma aplicação pode ficar exposta a acessos diretos e potencialmente perigosos, mesmo em ambientes onde o WAF está presente. Vamos configurar e testar diferentes arquiteturas, analisando como cada uma delas responde a possíveis tentativas de bypass do WAF. Através de exemplos práticos, demonstraremos as consequências de configurações inadequadas e discutiremos estratégias para mitigar esses riscos.
Para facilitar o entendimento, a arquitetura básica que será utilizada ao longo deste artigo segue o seguinte fluxo: os usuários acessam um domínio gerenciado pelo Route 53, que redireciona as requisições para o CloudFront que têm um WAF associado. Em seguida, o CloudFront encaminha essas requisições para o Application Load Balancer (ALB), que por fim entrega o conteúdo hospedado no recurso final, como uma instância EC2. Visualmente, esse fluxo pode ser representado da seguinte forma: Usuários → http://www.exemplo.com → Route 53 → CloudFront → Application Load Balancer → Recurso
A proposta desse texto é fornecer um exemplo prático que não apenas ilustra o potencial risco, mas também oferece soluções para garantir que sua aplicação esteja protegida contra acessos não autorizados. Seja você um arquiteto de soluções ou um engenheiro de segurança, este artigo fornecerá insights valiosos sobre como fortalecer a segurança da sua infraestrutura na nuvem.
Pré Requisitos
Para acompanhar esta demonstração, é necessário que você tenha conhecimento sobre a criação e manipulação dos seguintes componentes: Application Load Balancer (ALB); Distribuições CloudFront
Web Application Firewall (WAF); Domínios no Route53
Configuração da Infraestrutura de Teste
Nesta seção, vamos configurar uma infraestrutura simplificada para simular o ambiente de produção, onde testamos o potencial bypass do WAF na arquitetura onde o WAF é implementado apenas no CloudFront. A seguir, detalhamos cada passo necessário para configurar esse ambiente.
Passo 1. Criação do Application Load Balancer (ALB)
Iniciaremos criando um Application Load Balancer (ALB) que usa uma configuração padrão, i.e. responde exclusivamente na porta 443, e toda requisição que chega na porta 80 é direcionada automaticamente para a porta 443. Para nosso teste, o ALB será configurado com regras simples que retornam mensagens de texto plano, eliminando a necessidade de servidores web em instâncias EC2. As regras e suas respostas serão configuradas da seguinte forma:
| Priority | Rule | Response |
|---|---|---|
| 10 | Has the tag: {X-CF-Verified: True} | Access authorized: The request contains the tag that validates the request passed through CloudFront. |
| 20 | Has hostheader www.example.com | Potential failure: It was validated that the request appears to come from access to the DNS www.example.com. |
| Default | If no other rule applied | Application Load Balancer was accessed, reaching the default rule. |
Passo 2. Configuração da Distribuição CloudFront
Em seguida, criaremos uma distribuição CloudFront que servirá o conteúdo do ALB configurado no passo anterior. Durante a configuração das Origens no CloudFront, adicione uma tag personalizada a todas as requisições que passarem pelo CloudFront. A tag a ser usada será: {X-CF-Verified: True}. Esta tag será essencial para identificar as requisições que passaram pelo CloudFront quando forem processadas pelo ALB.
Passo 3: Criar um Web ACL WAF
Para demonstrar o WAF em ação, configuramos um Web ACL com uma regra específica que exige que todos os usuários respondam a um CAPTCHA ao acessar os recursos protegidos. A regra verificará se o URI Path das requisições começa com “/”, e, em caso afirmativo, um CAPTCHA será apresentado. Abaixo, um exemplo da regra em formato JSON para ser utilizado no editor JSON do AWS WAF. Após configurar a regra, associe o Web ACL ao CloudFront criado no passo anterior.
{
"Name": "all-requests",
"Priority": 0,
"Action": {
"Captcha": {}
},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "all-requests"
},
"Statement": {
"ByteMatchStatement": {
"FieldToMatch": {
"UriPath": {}
},
"PositionalConstraint": "STARTS_WITH",
"SearchString": "/",
"TextTransformations": [
{
"Type": "NONE",
"Priority": 0
}
]
}
},
"CaptchaConfig": {
"ImmunityTimeProperty": {
"ImmunityTime": "3600"
}
}
}
Passo 4: Configuração do Route 53
Por fim, configure o Route 53 para gerenciar o domínio utilizado no teste. Certifique-se de que as requisições sejam direcionadas corretamente para a distribuição CloudFront configurada anteriormente, assegurando que o fluxo de tráfego siga o caminho pretendido: Usuários → http://www.exemplo.com → Route 53 → CloudFront → ALB → Recurso.
Teste de Vulnerabilidade: Acesso Direto ao Load Balancer
Nesta seção, vamos conduzir um teste prático para demonstrar uma potencial falha de segurança que ocorre quando o WAF não está devidamente vinculado ao Application Load Balancer (ALB). O objetivo é ilustrar como um atacante pode contornar o CloudFront e acessar diretamente o ALB, expondo sua aplicação a riscos significativos.
Passo 1: Acesso via CloudFront
Inicialmente, acessaremos o serviço da maneira correta, utilizando o CloudFront. Para isso, abra seu navegador e acesse o endereço que direciona a requisição para o CloudFront. Este é o caminho esperado para o tráfego de sua aplicação, onde o WAF, se configurado corretamente, inspecionará as requisições.
Passo 2: Descoberta do DNS e IP do Load Balancer
Para realizar o teste de vulnerabilidade, precisamos identificar o DNS e o endereço IP público do ALB. Utilize o comando host ou dig para obter essas informações:
host alb-id-123456789012.us-east-1.elb.amazonaws.com
Suponha que o comando retorne o IP 50.10.50.10. No próximo passo, substitua esse IP pelo correspondente ao seu ALB.
Nota:Nota: Além das técnicas tradicionais de descoberta de IPs, um atacante pode tentar descobrir o IP original ou histórico do seu servidor antes da implementação de proteções como WAF ou Cloudflare. Plataformas como Shodan, SecurityTrails, ZoomEye e Censys mantêm registros históricos de endereços IP associados a domínios e podem revelar apontamentos antigos que não estão mais publicamente visíveis. Portanto, se anteriormente ao uso de um Application Load Balancer (ALB) com WAF, as requisições eram direcionadas diretamente para sua instância EC2, é crucial garantir que o Security Group da instância esteja configurado para responder apenas ao ALB. Além disso, se possível, migre a instância para uma subnet privada e remova seu IP público. Como a instância estará respondendo apenas ao ALB, a segurança é significativamente aumentada se ela não for acessível diretamente pela internet. Caso você precise acessar o terminal da instância (por exemplo, via SSH), utilize uma VPN para se conectar à VPC e, assim, acessar a instância de forma segura.
Passo 3: Realizando Requisição Direta ao ALB
Com o IP do ALB em mãos, tentaremos acessar o serviço diretamente, ignorando o CloudFront. Isso pode ser feito usando um navegador web para acessar o DNS do ALB ou o endereço de IP identificado no passo anterior. Alternativamente, você pode executar o seguinte comando no terminal:
curl -k https://50.10.50.10
Este comando tenta estabelecer uma conexão diretamente com o ALB, sem passar pelo CloudFront. Se o ALB não estiver protegido por um WAF, a requisição será processada normalmente, demonstrando uma vulnerabilidade na arquitetura.
Passo 4: Simulando um Acesso Direto ao ALB com Headers Manipulados
Agora, vamos simular um ataque onde o invasor tenta enganar o ALB manipulando os headers da requisição para imitar uma requisição legítima que passou pelo CloudFront. Isso pode ser feito utilizando curl ou uma ferramenta de teste de API, como o Postman. Veja um exemplo de comando curl para executar no console:
curl -k -H "Host: www.example.com" https://50.10.50.10:443
Neste exemplo, o header Host é modificado para que o ALB acredite que a requisição veio do CloudFront. Se o WAF não estiver devidamente configurado no ALB, essa requisição pode ser aceita, expondo o serviço a potenciais ataques.
Conclusão do Teste
Este teste prático demonstra como a ausência de um WAF vinculado ao ALB pode deixar a aplicação vulnerável a ataques diretos, mesmo que um CloudFront esteja presente na arquitetura. É essencial garantir que a segurança seja implementada em todos os pontos críticos da infraestrutura, protegendo tanto o CloudFront quanto o ALB. Para tal, as recomendamos as seguintes soluções:
- Validação de Headers Personalizados: Configure um WAF a nível regional no ALB que valide a presença de um header personalizado, como {X-CF-Verified: True}. Este header deve ser adicionado pelo CloudFront, e o WAF bloqueará requisições onde o header estiver ausente.
- Rotação Automática de Tags de Validação: Implemente uma função Lambda, que pode ser acionada periodicamente com o serviço Amazon EventBridge Scheduler, que rotacione periodicamente o valor da tag de validação utilizada no header {X-CF-Verified: True}. Por exemplo, a tag pode ser rotacionada para um valor como {X-CF-Verified: abcd1234}. Essa abordagem dificulta que um atacante descubra e use a tag, aumentando a segurança da aplicação. A Lambda deve atualizar automaticamente tanto o WAF quanto o ALB com a nova tag, e sua execução pode ser agendada para intervalos regulares, como diariamente. Embora esta medida adicione uma camada adicional de segurança, vale considerar a implementação desta técnica de acordo com a criticidade do sistema e os recursos disponíveis. Em um futuro post no blog, podemos explorar um exemplo de código para essa Lambda.
- Restrições no Security Group do ALB: Restrinja o Security Group do ALB para que ele responda apenas aos IPs do CloudFront. Essa medida é direta e eficaz, bloqueando tentativas de acesso direto ao ALB. A lista de IPs do CloudFront está disponível em https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html
A figura abaixo ilustra a sugestão de arquitetura para proteger sua aplicação contra acessos diretos ao Application Load Balancer (ALB). Ela inclui a implementação de Web Application Firewalls (WAF) tanto no nível do CloudFront quanto diretamente no ALB, além da configuração de um EventBridge para rotação automática das tags de validação, conforme descrito nas recomendações anteriores.
Considerações Finais
Por mais robustas que as soluções técnicas sejam, a segurança nunca está completa sem o componente humano. A formação de uma cultura de segurança dentro da sua equipe é crucial para garantir uma defesa eficaz contra ameaças. Aqui estão algumas práticas recomendadas que podem fortalecer ainda mais sua postura de segurança:
- Treinamento Regular: Mantenha sua equipe atualizada e consciente das melhores práticas de segurança. Promova workshops e sessões de capacitação para que todos estejam preparados para lidar com ameaças emergentes.
- Monitoramento Contínuo: Implemente sistemas de monitoramento automatizado que possam detectar e responder a incidentes de segurança em tempo real. Ferramentas como AWS GuardDuty, AWS CloudTrail e AWS Config são essenciais para manter a visibilidade e o controle sobre o ambiente.
- Resposta a Incidentes: Tenha um plano de resposta a incidentes bem definido. Garanta que sua equipe saiba como agir rapidamente em caso de uma violação de segurança, minimizando o impacto potencial.
Conforme as ameaças cibernéticas continuam a evoluir, é fundamental que tanto as soluções técnicas quanto às práticas humanas sejam continuamente aprimoradas. Ao combinar uma arquitetura bem projetada com uma equipe bem treinada, sua organização estará melhor preparada para enfrentar os desafios de segurança na nuvem.
