Eu implantei meu aplicativo em contêiner usando o AWS ECS Fargate . Minha configuração consiste em:
- Um servidor web FastAPI em execução na porta 8000 .
- Um servidor NGINX em execução na porta 8080 .
Por motivos de segurança, bloqueei o acesso direto por meio de grupos de segurança , o que significa que ninguém pode acessar o IP público da minha instância nas portas 80, 443, 8080 ou 8000 .
Em vez disso, tornei meu aplicativo acessível somente por meio de um AWS Application Load Balancer (ALB) , que lida com tráfego baseado em domínio . Minha suposição era que, como o IP público não é acessível , os bots não seriam capazes de enviar solicitações automatizadas a menos que soubessem meu nome de domínio.
No entanto, ainda estou recebendo solicitações de bots.
Minha pergunta:
- Como os bots ainda estão enviando solicitações ao meu serviço se o acesso IP direto está bloqueado?
- Existe uma maneira de impedir completamente o tráfego de bots sem usar o AWS WAF ou outros serviços de segurança da AWS ?
- Bloquear o acesso direto ao IP público não significa que somente usuários que conhecem meu domínio podem acessar o serviço?
Agradeceria qualquer informação sobre o motivo disso estar acontecendo e possíveis soluções.
O ALB não filtra o tráfego de bots. Ele apenas o passa para seus contêineres. Se um bot souber seu nome de domínio, ele pode enviar solicitações diretamente para seu ALB. O domínio e o ALB não são imunes ao tráfego de bots só porque estão atrás de SGs.
É difícil entender pela pergunta o que são os "bots" e o que são as "solicitações", mas uma possível causa para os grupos de segurança "não terem efeito" pode ser o funcionamento da modificação de grupos de segurança.
Quando você modifica um grupo de segurança, as alterações só entram em vigor em novas conexões iniciadas, o que significa que se você tiver uma conexão TCP aberta de um cliente para seu destino, modificar uma regra para bloquear essa conexão não encerrará a conexão existente (no entanto, novas conexões TCP do mesmo cliente serão bloqueadas).
Aplicar ACLs de rede é uma opção "mais forte" para garantir que as conexões sejam bloqueadas (e também se aplicam imediatamente às conexões existentes).
Outro possível motivo: suas tabelas de rotas de VPC permitem caminhos de conexão inesperados para seu destino, ignorando suas regras.
Por fim, você pode verificar se alguma solicitação está chegando ao seu balanceador de carga habilitando as métricas do CloudWatch e os logs de acesso do balanceador de carga.
@Mark B encontrou a solução. Obrigado a @Mark B do Stackoverflow.
Há duas soluções.
1) (Melhor se você usar Cloudflare): Altere o grupo de segurança do balanceador de carga para aceitar apenas solicitações de endereços IP do Cloudflare. Então você pode ter certeza de que todas as solicitações estão passando pelo Cloudflare e seu WAF. Intervalos de IP do Cloudflare para permitir que endereços IPv4 adicionem o grupo de segurança.
2) As solicitações ainda chegam ao nosso balanceador de carga, mas se o nome do cabeçalho não corresponder, serão rejeitadas: O balanceador de carga retorna um erro 404 por padrão e, se o cabeçalho do host corresponder ao meu domínio, ele encaminha a solicitação ao grupo de destino.