Servidor Debian comprometido enviando ataque DDOS

Question

Eu tenho um servidor online que aparentemente foi comprometido e envia ataques DDOS para outro ip. O sistema é um servidor 7 debian, hospedando alguns sites wordpress, joomla e tempo de antena para hospedar um rádio. O Fail2ban está instalado e configurado.

Eu tenho acesso no modo de recuperação, mas não consegui encontrar nada de suspeito nos logs. Assim que inicializo o sistema no modo normal, ele começa a enviar pacotes e não consigo fazer login remoto (ssh).

A imagem a seguir reflete os pacotes enviados assim que eu tento inicializar o sistema.

Qualquer ajuda apreciada.

    

Answer 1

Eu finalmente resolvi isso, eu devo observar que a imagem anexada na pergunta estava mostrando pacotes de saída enviados, não devido a qualquer ataque de dodem mas por causa do tráfego gerado ao reinicializar em "modo de recuperação".

Estes são os passos que tomei para resolvê-lo:

1- Inicie o modo de recuperação no console do online.net.

2- ssh no "modo de recuperação" e monte o sistema de arquivos problemático, observe que seu dispositivo pode ser diferente do seguinte comando de amostra:

$ mount /dev/sda2 /mnt

3- Verifique os registros no servidor:

$ cat /var/log/syslog
$ cat /var/log/dmesg
$ cat /var/log/messages
$ cat /var/log/fail2ban.log
$ cat /var/log/auth.log

Além disso, seu apache2 access.log e / ou qualquer outro registro crítico em seu sistema.

4- Procure qualquer arquivo modificado um dia ou dois antes do ataque:

$ find /mnt -mtime -3 -ls

5- Verifique o sistema em busca de rootkits (rkhunter) ou vírus (clamav)

Como não encontrei nada suspeito, verifiquei se havia algum tipo de serviço de acesso remoto no console do online.net (gostaria de ter pensado nisso antes) e assim foi. Então eu reiniciei no modo normal e pude verificar que o sistema não estava inicializando devido a erros em / dev / sda2. Para resolvê-lo eu reiniciei no modo de recuperação e fiz um

$ fsck2 /dev/sda2

Houve alguns inodes corrompidos, respondi Sim para reparar todos eles.

6- Então eu reiniciei o sistema novamente, mas o processo de inicialização ficou em estoque em "limpeza de arquivos temporários". Para resolvê-lo, mudei o TMPTIME para 60 no seguinte arquivo:

/ etc / default / rcS

Nota: Lembre-se de resolver esse problema e retorne essa configuração para 0 no login bem-sucedido, deixando o TMPTIME para remover arquivos tmp com mais de 60 dias como um risco de segurança

7- Depois de alguns pequenos erros, eu poderia finalmente fazer o login, colocar as configurações necessárias de volta aos padrões, e re-pesquisar todo o sistema com rkhunter e clamav, apt-get update & & apt-get upgrade e uma última reinicialização.

O sistema agora está limpo e funcionando novamente.