Alerta de segurança NGINX sob ataque por manipulação de proxy_pass para desviar tráfego

Se você usa o NGINX para servir sites, fazer balanço de carga ou como proxy inverso, preste atenção: recentemente foi detectada uma campanha em que um ator malicioso compromete servidores com o NGINX e ferramentas de gestão de hospedagem para redireccionar o tráfego dos usuários para sua própria infraestrutura, mantendo a aparência de normalidade.

NGINX é, por design, um intermediário entre o visitante e o servidor final: recebe pedidos, aplica regras, pode cachear e reenviar-as para outros backends. Essa flexibilidade é precisamente o que esses atacantes exploram. Pesquisadores da Datadog Security Labs documentaram como os atacantes introduzem blocos de configuração maliciosos dentro de arquivos da NGINX, especialmente em instalações gerenciadas com o painel Baota, para capturar rotas determinadas e reenviar-las através da directiva 'proxy_ 'pass' para servidores controlados por eles. Você pode ler mais sobre o trabalho do Datadog na seção de segurança do seu blog ( Datadog Security Labs).

O que faz a campanha é injetar blocos location que correspondem a rotas escolhidas pelo atacante e reesscrevem o pedido para incluir o URL original antes de o encaminhar com 'proxy_ 'pass' a domínios externos. Para que a redirecção pareça legítima, conservam cabeçalhos como Host, X-Real-IP, User- Agent ou Referer. Dado que 'proxy_ 'pass' É uma característica legítima e muito usada para balanceamento e failover, seu abuso passa despercebido se não forem inspeccionadas as configurações.

O modus operandi descoberto inclui um conjunto de programas automatizados que atuam em etapas: um controlador inicial descarrega e executa os componentes restantes e pode até mesmo enviar pedidos de HTTP em bruto por TCP se não houver ferramentas como curl ou wget; outro componente é direcionado especificamente para arquivos geridos pelo painel Baota e selecciona modelos de injeção de acordo com o valor da injeção server_ name, descrevendo a configuração de forma que o serviço não deixe de prestar serviço; existem ferramentas que buscam e processam arquivos de configuração em locais típicos (sites-enabled, conf.d, sites-available), usam utilitários de texto para separar e editar fragmentos sem corromper, validam as mudanças com nginx - t Antes de carregar e marcar os ficheiros já infetados por somas para evitar duplicar a injeção; outra peça focaliza o ataque num subconjunto de domínios (segundo os pesquisadores, muitos com terminações regionais como .in e .id e também sites com sufixos .edu/.gov) e emprega reinícios forçados como último recurso; há finalmente um script que inventaria um mapa de domínios comprometidos e exfiltra essa informação a um servidor de comando e controle identificado pelos rastreadores.

Precisamente porque não se aproveita uma vulnerabilidade no motor da NGINX, mas a capacidade de modificar seus arquivos de configuração, esses ataques são complexos de detectar. Os administradores podem não notar nada estranho: os usuários ainda recebem o conteúdo esperado e o tráfego não apresenta falhas visíveis a olho nu. Além disso, ao manter os cabeçalhos e reenviar os pedidos, a interação parece legítima desde a perspectiva do cliente e muitos sistemas de monitoramento ignoram a diferença.

Se você quer verificar se seu ambiente está afetado, há várias linhas de defesa práticas. Verifique com atenção as configurações do NGINX procurando location e 'proxy_ 'pass' que apontem para domínios ou IPs externos à sua organização; um comando simples para começar é procurar ocorrências de proxy_pass nas rotas típicas de configuração, e sempre validar com nginx - t Antes de carregar. Limita quem pode escrever nos ficheiros de configuração e nas pastas do painel de hospedagem, vigia alterações inesperadas com sistemas de integridade de arquivos e registra e alerta sobre recargas ou reinícios de NGINX. Também é recomendável restringir o tráfego de saída não autorizado a partir de servidores web e proteger os painéis de controle como Baota com senhas fortes, autenticação multifator e acesso por IP quando possível. O painel Baota tem presença online em seu site oficial ( BaoTa) e convém assegurar instâncias expostas.

Para entender por que detectar estas manipulações não é trivial, lembra que 'proxy_ 'pass' É uma directiva documentada e comum na NGINX; a própria documentação técnica descreve o seu uso para reenviar pedidos a backends e é uma peça fundamental em arquiteturas modernas ( Documentação oficial do NGINX sobre o 'proxy_pass'). Isso significa que as mudanças maliciosos se camuflan como configurações válidas e funcionais.

Se você quiser seguir a pesquisa ou testar indicadores, as equipes de resposta geralmente publicam artefatos e endereços IP associados aos C2 para seu bloqueio em corta-fogos e listas de rejeição; por exemplo, um dos endereços associados pelos pesquisadores pode ser consultado em bases de reputação pública ( consulta em AbuseIPDB para 158.94.210.227), o que ajuda a tomar medidas de rede a nível defensivo.

Em suma, não é suficiente para proteger o software: é preciso proteger a configuração e o acesso à mesma. Rever regularmente os ficheiros de configuração, limitar as alterações a pessoal autorizado e monitorizar a telemetria de rede e as recarregações de NGINX São medidas essenciais para detectar e conter este tipo de campanhas. Se você administra servidores com painéis de hospedagem, certifique-se de que esses painéis estão atualizados e de que os acessos estão fortemente autenticados; a segurança da camada de gestão é geralmente o elo mais frágil nesses incidentes.

Se você quer aprofundar as recomendações técnicas e práticas específicas de mitigação, a comunidade e fornecedores como Datadog ou a própria NGINX publicam guias e entradas técnicas que convém seguir: além do artigo técnico de Datadog citado no início, NGINX mantém entradas sobre boas práticas de segurança em seu blog ( Segurança no NGINX — guia e recomendações). Combinar essas boas práticas com controles de integridade e de rede é a melhor receita para não levar surpresas.