TL; DR O invasor substitui o IP de origem pelo endereço do seu servidor e aciona abusos automáticos. Como resultado, o cliente é banido da hospedagem por atividades maliciosas que não estavam lá.Comentado por vdsina.ru :
Este artigo foi escrito por nosso cliente, que nos passou de um grande hoster após um ataque de DDoS e concordou em compartilhar essa história.
Vou falar sobre uma maneira surpreendentemente insidiosa de ataques DDoS, que eu nunca encontrei antes. O insidioso é que nenhum ataque é realizado no próprio servidor da vítima. Em vez disso, o invasor provoca a operação de sistemas de detecção de ataques de terceiros, forçando a gerar reclamações completamente reais (nas pessoas comuns "abusos") ao seu servidor.
Do lado do hoster, parece que você está envolvido em atividades maliciosas, embora na verdade isso não seja verdade. Acontece que muitos grandes provedores de hospedagem não estão prontos para entender profundamente as causas do problema e preferem simplesmente bani-lo por violar as regras.
Este artigo detalha esse tipo de ataque em um caso real.
Linha do tempo
Eu mantive vários projetos pessoais em servidores VPS em um host conhecido. Uma vez recebi uma carta dele:
# 9042382: Violação de ToS - atividade maliciosa
Olá
Recebemos um relatório de atividade maliciosa originária do seu servidor XXXX. Pedimos que você investigue esse assunto assim que puder. Depois de concluir sua investigação, responda a este ticket com as respostas para as seguintes perguntas:
...
Reported-From: abuse-out@checkdomain.de Category: info Report-Type: info Service: different services Version: 0.1 User-Agent: Checkdomain Express 0.19 Date: Fri, 26 May 2018 19:25:19 +0200 Source-Type: ipv4 Source: my-server-ip-xx-xxx Port: dif. Report-ID: dih3cefnp@checkdomain.de Schema-URL: http://www.blocklist.de/downloads/schema/info_0.1.1.json Attachment: text/plain DETAILS ZU DEN ATTACKEN/STÖRUNGEN | DETAILS OF THE ATTACKS (letzten 60 Tage / max. 100 St.) | (last 60 days / max. 100 hits) portflood: syn | | standby.checkdomain.de | VORHERIGE SPERREN DER IP-NUMMER | BANNED HISTORY OF THIS IP-NUMBER my-server-ip-xxx-xxx-xxx: this ip-number was never banned before AUZUG AUS SERVERLOGDATEI | EXCERPT FROM SERVER LOGFILE tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:41667 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:46208 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:13000 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:39104 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:55348 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:37266 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:60684 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:63878 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:50445 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:56215 SYNRECV -
Onde
my-server-ip-xx-xxx é o endereço IP do servidor.
Nele, o hoster me envia uma reclamação recebida em sua caixa de abuso @ e pede urgentemente para interromper a atividade maliciosa, caso contrário, eu serei bloqueado. O log anexado mostra uma lista de conexões TCP com a porta 80 (HTTP) no estado SYN RECEIVED. Ou seja, do meu servidor há uma inundação SYN no servidor da web de alguém.
Meu primeiro pensamento é que eles me invadiram e o SYN flood vem do meu servidor. No Linux, há restrições no gerenciamento de soquetes com direitos normais de usuário e você pode enviar apenas pacotes SYN (sem estabelecer uma conexão TCP completa) apenas com privilégios de root. E isso significa que eles racharam completamente.
Em pânico, corro para o servidor para procurar um processo malicioso. Verifico top, ss, lsof e não vejo nada suspeito. A principal conclusão: "
horror, eles provavelmente inundaram um rootkit tão legal que esconde o vírus no nível do kernel de todos os utilitários do sistema! ". No processo de pesquisa, verifica-se que a carga no servidor não mudou, de acordo com os gráficos no painel do host, o tráfego na interface permanece o mesmo.
Antes disso, iniciei o
tcpdump com filtros que mostravam tráfego de saída e não via nada suspeito. Desesperado, decido ver todo o tráfego para o servidor. Encontro pacotes raros de RST de servidores estranhos no fluxo de tráfego legítimo.
Parece algo assim, onde
my-server-ip-xx-xxx é o endereço do meu servidor:
IP 85.10.207.190.http > my-server-ip-xx-xxx.8389: Flags [R] IP 85.10.207.190.http > my-server-ip-xx-xxx.8389: Flags [R] IP 85.10.207.190.http > my-server-ip-xx-xxx.8389: Flags [R] IP adsl-070-154.sip.pns.bellsouth.net.http > my-server-ip-xx-xxx.8389: Flags [R] IP adsl-070-154.sip.pns.bellsouth.net.http > my-server-ip-xx-xxx.8389: Flags [R] IP adsl-070-154.sip.pns.bellsouth.net.http > my-server-ip-xx-xxx.8389: Flags [R]
Era óbvio que isso era uma anomalia, já que não havia mais troca com esses servidores e por que eles enviaram um pacote para fechar a conexão, não estava claro para mim.
Nesse ponto, administradores experientes entenderiam tudo imediatamente, mas resolveremos tudo isso por nossos dedos
Como isso funciona
Pacotes RST recebidos são respostas a tentativas de estabelecer uma conexão TCP com uma porta privada. Ao mesmo tempo, não há tráfego de saída do meu servidor para os servidores que enviam RST. Isso significa que o invasor substitui o endereço de saída pelo meu e gera tráfego semelhante a um ataque DDoS. Mas como a única coisa que um invasor pode fazer é enviar um pacote de saída, todas as respostas dos servidores chegam ao meu servidor.
Somente respostas a solicitações falsas chegam ao servidor da vítimaNormalmente, esses ataques são usados para amplificação do DNS , quando o invasor envia uma pequena solicitação em nome da vítima e a vítima recebe uma grande resposta que não solicitou. Este é um mecanismo clássico de ataque por exaustão de canal.
No meu caso, o invasor não pretendeu esgotar o canal do servidor vítima. Sua atividade era completamente invisível nos gráficos de consumo do canal. Seu principal objetivo era provocar sistemas de notificação automática de ataques à rede que enviariam uma carta reclamando do endereço de abuso especificado na sub-rede whois do meu provedor.
Sistemas intrusivos de prevenção / detecção , como
Snort e
Suricata, podem fazer isso .
Como resultado, o hoster recebe uma carta absolutamente real de empresas legítimas, que contém uma reclamação sobre minha atividade maliciosa e até mesmo os registros reais nelas. Ao mesmo tempo, o invasor não precisa de um canal grande, pois conhece com antecedência os endereços dos servidores nos quais os sistemas IDS / IPS estão instalados e o número mínimo necessário de pacotes para que a reclamação automática funcione.
A única dificuldade para um invasor é encontrar um servidor que permita a substituição de endereços IP de saída em pacotes. Todos os hosters normais bloqueiam esses pacotes. Existem apenas dois tipos de hospedagem, permitindo que os clientes substituam o IP de saída: muito analfabetos configurados ou especialmente criados para crimes cibernéticos.
Verificando a possibilidade de falsificação de endereço IP
Aconselho que você verifique seu host quanto à possibilidade de substituir o IP de saída. Isso exigirá dois servidores, um para receber tráfego e outro para enviar.
No lado do servidor receptor, começaremos a registrar o tráfego recebido. Vamos especificar uma porta rara como um filtro no qual não deve haver tráfego em horários normais:
tcpdump -i any port 9912
No servidor que estamos testando, geraremos um pacote com a substituição do endereço IP de saída para
1.1.1.1 , direcionado à porta 9912. Para isso, usamos o utilitário cool
nping dos desenvolvedores do nmap. Permite gerar pacotes não-padrão nos níveis L2 e L3.
nping --tcp -p 9912 -S 1.1.1.1 receiver-server.com
receiver-server.com - o endereço do servidor de escuta executando tcpdump
1.1.1.1 - endereço de saída substituto
9912 - Porta Remota
Se no lado de
receiver-server.com você vir um pacote fornecido em nome do 1.1.1.1, seu provedor permitirá que você substitua o endereço IP de saída. Esta é uma ocasião para informá-lo sobre problemas na instalação de equipamentos de rede. Geralmente, esse problema é afetado pelos provedores de serviços de Internet domésticos.
Suporte técnico estúpido
Tendo descoberto as razões das queixas, eu detalhei tudo ao hoster:
Olá
Finalmente entendo o que aconteceu.
Eles falsificam meu endereço IP e hosts aleatórios DDoS usando meu endereço como endereço de origem. Portanto, as vítimas geram relatórios automáticos de abuso aos meus provedores de hospedagem.
Você pode ver no log de abuso que as conexões estão apenas no estado SYN_RECV (nenhuma conexão TCP completa estabelecida) porque eles podem enviar apenas um pacote usando IP falsificado e não podem concluir o handshake TCP.
Eu posso provar isso. Há muitos pacotes de entrada TCP RST chegando agora ao meu servidor a partir de hosts para os quais nunca enviei nenhum pacote.
Você pode verificá-lo agora executando:
tcpdump -i eth0 "tcp [tcpflags] & (tcp-rst)! = 0"
Você verá que muitos pacotes RST vieram de hosts para os quais nunca enviei dados.
Isso prova que o invasor está falsificando meu endereço IP para me comprometer e gerar abusos.
Pareceu-me que qualquer engenheiro de suporte técnico qualificado entenderia a situação e a questão seria encerrada. Mas, em vez disso, exigiram que eu verifique o servidor com software antivírus ou reinstale completamente o sistema operacional. Enquanto nos correspondíamos com o suporte técnico, os abusos continuaram chegando e em um dia fui banido.
Foi um insulto desagradável o fato de eu ter sido enquadrada. Essa situação mostra como as pessoas são vulneráveis, que, em vez de entender, seguem impensadamente os scripts. Desde então, cito esse caso como um exemplo quando surge o debate sobre a escolha de uma hospedagem para projetos importantes. Infelizmente, muitas empresas de hospedagem simplesmente não podem se dar ao luxo de dedicar muito tempo a casos não-padrão de pequenos clientes e é mais fácil bani-lo do que resolver seus problemas.
Inscreva-se no nosso desenvolvedor do Instagram
