Recentemente, atualizei as configurações em uma instância NGINX voltada para o público para adicionar suporte para http2. Ao olhar para os logs depois para sentir com que frequência ele estava sendo usado, vi um rápido aumento em novas entradas de log não relacionadas ao site hospedado.
Primeiro, havia várias entradas fazendo CONNECTsolicitações, todas falhando com 400 erros porque a instância NGINX não está configurada como um proxy de encaminhamento. Configurei regras fail2ban para descartar o tráfego de muitos endereços IP de origem. Eu não estou particularmente preocupado com isso (por favor, adicione um comentário se eu deveria estar).
O próximo conjunto de entradas são GETsolicitações, mas em vez de ter caminhos, eles têm URLs completos como destino, por exemplo
222.223.121.231 - - [16/Jul/2020:12:57:37 +0100] "GET http://api.gxout.com/proxy/check.aspx HTTP/1.1" 404 199 "http://api.gxout.com/proxy/check.aspx" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
A maioria deles está recebendo 404 respostas novamente como esperado e eu adicionei outra regra fail2ban para descartar pacotes dos endereços IP de origem (novamente não me preocupei muito com isso).
Existem alguns mais semelhantes que estão recebendo 200 respostas e são essas que me preocupam, por exemplo
35.236.60.202 - - [16/Jul/2020:11:52:28 +0100] "GET http://www.nike.com/ HTTP/1.1" 200 396 "-" "python-requests/2.20.0"
Tenho as seguintes perguntas:
- Por que o NGINX retornaria um 200 para essa solicitação?
- Sugestões de como depurar isso?
Todo o tráfego de entrada deve ser https (obrigatório ou http2) e estou fixado em TLS 1.2 ou 1.3, então não acho que capturar o tráfego com tcpdump vá ajudar (suponho que não posso alimentar a chave privada em wireshark e decodificar os pacotes?).
A única outra opção em que posso pensar é adicionar algum log personalizado ( é possível registrar os dados de resposta no log de acesso do nginx? ) ao NGINX para registrar toda a solicitação/resposta. Eu fiz isso no passado para depurar problemas de troca de token oAuth2.0, mas apenas em um sistema em que eu tinha controle total sobre todo o tráfego de entrada.
Acho que não há necessidade de depurar ainda mais isso, pois algumas coisas são óbvias:
O
python-requests/2.20.0as User-Agent indica algum script Python. A popularrequestsbiblioteca Python torna muito fácil escrever bots simples, sejam bons ou ruins.Retornar 200 para um nome de host desconhecido pode ser bastante comum se você tiver um servidor padrão no NGINX que permita a resposta a qualquer
Host:cabeçalho.Perdoe meu texto, mas por padrão , o servidor padrão no NGINX responderá a qualquer arquivo
Host:. Então, o que é necessário para que um200seja retornado é que seu aplicativo não verifique o nome de domínio e não emita um redirecionamento para o nome de domínio canônico do seu site.Como em uma situação típica "você sabe quais domínios você hospeda", qualquer solicitação com um nome de domínio estrangeiro (ou nenhum) pode ser considerada maliciosa/indesejada.
Você pode querer olhar para a abordagem de bloqueio de honeypot para tais solicitações em que "o domínio não é seu" - a maioria dos bots maliciosos/ruins na verdade apresentarão nada além de IP nu como o valor do
Host:cabeçalho, simplesmente porque eles são preguiçosos para verificar quais domínios estão localizados em um determinado IP (lembre-se de que eles encontram suas vítimas simplesmente enumerando redes/endereços IP).Quanto às solicitações com um URL completo em vez de URI, isso pode ser qualquer coisa, incluindo bots mal escritos, verificadores de proxy etc.
Se você tiver muitas dessas solicitações e gerar um 404 atinge seu back-end, eu recomendaria negar isso na configuração diretamente com uma regra simples e possivelmente adicionar um bloco instantâneo em vez de usar Fail2ban.