Tráfego DNS de saída excessivo

Question

Eu tenho um sistema VPS que tive por 3 anos em um host sem problema. Recentemente, o host começou a enviar uma quantidade extrema de tráfego DNS de saída para 31.193.132.138. Devido ao modo como o Linode respondeu a isso, eu deixei o Linode recentemente e mudei para o 6sync. O servidor foi completamente reconstruído no 6sync, com exceção das configurações de correio postfix.

Atualmente, os daemons executados são os seguintes:

sshd nginx postfix dovecot

php5-fpm (somente host local) spampd (somente localhost) clamsmtpd (somente localhost)

Dado que o servidor foi 100% reconstruído, não consigo encontrar nenhum ataque sério contra os daemons acima, as senhas foram alteradas, as chaves ssh ainda não existem na reconstrução, etc ... parece extremamente improvável que este é um compromisso que está sendo usado para DoS o endereço.

O IP fornecido é anotado on-line como uma fonte conhecida de SPAM. Minha suposição inicial era que ele estava tentando usar meu servidor postfix como retransmissão, e os endereços falsos que ele fornecia eram domínios com esse IP registrado como seus servidores de nomes. Eu imagino que, dada a configuração do postfix, as consultas do DNS para coisas como informações do SPF chegariam com quantidade igual ou maior do que o número de tentativas de spam enviadas por e-mail.

Tanto o Linode quanto o 6Sync disseram que o tráfego de saída é extremamente desproporcional. A seguir, todas as informações que recebi da Linode em relação ao tráfego de saída:

21:28:28.647263 IP 97.107.134.33.32775 > 31.193.132.138.53: 28720 op8+% [b2&3=0x4134] [17267a] [30550q] [28773n] [14673au][|domain]
21:28:28.647264 IP 97.107.134.33 > 31.193.132.138: udp
21:28:28.647264 IP 97.107.134.33.32775 > 31.193.132.138.53: 28720 op8+% [b2&3=0x4134] [17267a] [30550q] [28773n] [14673au][|domain]
21:28:28.647265 IP 97.107.134.33 > 31.193.132.138: udp
21:28:28.647265 IP 97.107.134.33.32775 > 31.193.132.138.53: 28720 op8+% [b2&3=0x4134] [17267a] [30550q] [28773n] [14673au][|domain]
21:28:28.647266 IP 97.107.134.33 > 31.193.132.138: udp

O 6sync não pode confirmar se o aumento recente no tráfego de saída foi para o mesmo IP ou sobre o DNS, mas presume-se como tal. Por enquanto, o meu servidor está bloqueando toda a sub-rede 31.0.0.0/8 para ajudar a impedir isso enquanto eu descubro isso.

Alguém tem alguma ideia do que está acontecendo?

    

Answer 1

não é uma resposta, apenas alguns pensamentos aleatórios:

• você consegue ver esse tráfego quando apenas executa o tcpdump em sua interface de rede [virtual]? se assim for - você pode tentar descobrir se há algum padrão diário / horário? você pode criar a regra iptables para contar o tráfego e depois permitir que o plug-in munin coletar as estatísticas ..
• você pode tentar determinar qual aplicativo está gerando esse tráfego? Eu vejo dois métodos aqui:
  • método brutal é esperar até que o tráfego seja exibido e começar a matar os aplicativos um após o outro.
  • abordagem gentil - use iptables na cadeia OUTPUT e correspondência do proprietário para log pacotes de saída na porta 53 para o seu syslog. algo como: iptables -I OUTPUT -p udp -dport 53 - proprietário de correspondência - proprietário do proprietário 33 -j LOG --log-prefix "uid 33" aplicado a todos os seus uids usados. Verifique o syslog para ver qual processo gera o tráfego indesejado.
• você tem o servidor dns local [por exemplo, bind] em execução? se então:
  • fareje também no loopback para ver qual aplicativo pode estar enviando solicitações que causam tráfego indesejado.
  • servidores externos podem conversar com seu servidor dns? se assim for - talvez seja algum tipo de ataque de back-scatter onde o seu servidor recebe pacotes de endereços falsificados e responde bombardeando a vítima.
• você tem 110% de certeza de que seu código php não foi alterado? pode ser que alguns dos seus scripts contenham poucas linhas maliciosas?

Answer 2

Eu ainda não sei o que é o tráfego, mas posso confirmar que não está em conformidade com o tráfego de DNS.

O cabeçalho de 12 bytes tem:

• um campo de ID de 2 bytes (28720 - 0x7030)
• campos de sinalizadores de 2 bytes (0x4134)
• 4 * contagens de registros de 2 bytes [17267a] [30550q] [28773n] [14673au]

Os sinalizadores em uma consulta recursiva normal devem ser 0x0100. As 4 contagens devem ser (1, 0, 0, 0 +).

    

Answer 3

Tente executar o tcpdump com o modo detalhado (-v) para ver as solicitações DNS reais & respostas acontecendo. Pode ser algum tunelamento ip através do DNS. Como o pQd propôs, seria bom saber qual software está gerando o tráfego.