Infecção por vírus DDoS (como um serviço unix) em um servidor Web Debian 8 VM

14

Eu mantenho um Wordpress (totalmente atualizado) para uma equipe de estudantes em um serviço de Máquina Virtual no ~ okeanos por alguns anos. Hoje, o suporte técnico me informou que estou realizando ataques DDoS, o que, é claro, não estou (este serviço tem minhas credenciais acadêmicas conectadas ..). Depois de suspenderem a máquina e eu inflamar o sistema de correspondência, tentei descobrir o que aconteceu.

Primeiro de tudo, eu executo um ps -ejpara verificar o que está sendo executado:

root@snf-25181:~# ps -ej
1545 1545 1545 ? 00:00:00 console-kit-dae
1618 1057 1057 ? 00:00:00 gdm-session-wor
1632 1632 1632 ? 00:01:40 rghuoywvrf
1767 1767 1767 ? 00:00:00 sshd
1769 1769 1769 ? 00:00:00 systemd
1770 1769 1769 ? 00:00:00 (sd-pam)
1775 1767 1767 ? 00:00:00 sshd
1776 1776 1776 pts/0 00:00:00 bash
1849 1849 1776 pts/0 00:00:00 su
1870 1870 1776 pts/0 00:00:00 bash
2246 0 0 ? 00:00:00 kworker/0:0
2797 839 839 ? 00:00:00 apache2
3158 3158 3158 ? 00:00:00 bvxktwwnsb
3162 3162 3162 ? 00:00:00 bvxktwwnsb
3163 3163 3163 ? 00:00:00 bvxktwwnsb
3164 3164 3164 ? 00:00:00 bvxktwwnsb
3165 3165 1776 pts/0 00:00:00 ps

Observe o bvxktwwnsb e o rguoywvrf

Então eu fiz um ps auxpara obter os serviços (novamente, uma cauda):

Debian-+  1629  0.0  0.0 178300  4444 ?        Sl   16:53   0:00 /usr/lib/dconf/dconf-service
root      1667  0.0  0.0  30744  4436 ?        Ss   16:53   0:00 /sbin/wpa_supplicant -u -s -O /run/wpa_supplicant
root      1670  0.0  0.1 299588  9884 ?        Ssl  16:53   0:00 /usr/lib/packagekit/packagekitd
root      1674  0.0  0.1 1055004 6168 ?        Ssl  16:53   0:00 /usr/sbin/console-kit-daemon --no-daemon
www-data  1923  0.0  0.1 240964  8112 ?        S    16:53   0:00 /usr/sbin/apache2 -k start
pankgeo+  5656  0.0  0.0  27416  3424 ?        Ss   17:03   0:00 /lib/systemd/systemd --user
pankgeo+  5657  0.0  0.0 143108  2408 ?        S    17:03   0:00 (sd-pam)   
root      5893  0.0  0.1 102420  6428 ?        Ss   17:04   0:00 sshd: pankgeorg [priv]
pankgeo+  5904  0.1  0.0 102560  4128 ?        S    17:04   0:02 sshd: pankgeorg@pts/0
pankgeo+  5905  0.2  0.1  16816  6388 pts/0    Ss+  17:04   0:04 -bash      
root      7443  0.0  0.1 102420  6496 ?        Ss   17:07   0:00 sshd: pankgeorg [priv]
pankgeo+  7448  0.0  0.0 102552  4160 ?        S    17:07   0:00 sshd: pankgeorg@pts/1
pankgeo+  7449  0.0  0.1  16468  6228 pts/1    Ss+  17:07   0:01 -bash      
root     17351  0.0  0.0      0     0 ?        S    17:15   0:00 [kworker/0:0]
root     18446  0.0  0.0      0     0 ?        S    17:18   0:00 [kworker/0:2]
root     18488  0.1  0.0      0     0 ?        S    17:18   0:01 [kworker/1:1]
root     22680  1.5  0.0      0     0 ?        S    17:28   0:08 [kworker/1:0]
root     24173  0.0  0.1 102420  6416 ?        Ss   17:31   0:00 sshd: pankgeorg [priv]
pankgeo+ 24181  0.3  0.0 102420  3360 ?        S    17:31   0:01 sshd: pankgeorg@pts/2
pankgeo+ 24182  0.0  0.0  16480  6112 pts/2    Ss   17:31   0:00 -bash      
root     25316  2.3  0.0      0     0 ?        S    17:33   0:06 [kworker/1:2]
root     26777  0.0  0.0      0     0 ?        S    17:35   0:00 [kworker/0:1]
root     26778  0.0  0.0      0     0 ?        S    17:35   0:00 [kworker/0:3]
root     27300  0.0  0.0   1424  1040 ?        Ss   17:38   0:00 cat resolv.conf  #note                        
root     27306  0.0  0.0   1424  1036 ?        Ss   17:38   0:00 gnome-terminal   #from                     
root     27307  0.0  0.0   1424  1036 ?        Ss   17:38   0:00 ifconfig eth0    #here                    
root     27308  0.0  0.0   1424  1040 ?        Ss   17:38   0:00 id               #(DDOS?)         
root     27309  0.0  0.0   1424  1040 ?        Ss   17:38   0:00 ifconfig                        
pankgeo+ 27315  0.0  0.0  11136  2044 pts/2    R+   17:38   0:00 ps aux     

Observe os itens [-4: -1]. Então eu encontrei on-line, chkconfig --listentão eu corro isso e isso apareceu:

root@snf-25181:/home/pankgeorg# chkconfig --list
acdnfhruvx 0:off 1:off 2:off 3:off 4:off 5:off 6:off
flyymwddwn 0:off 1:off 2:off 3:off 4:off 5:off 6:off

1 a 5 onde, onmas eu os virei off. Então eu reiniciei e ele mudou de nome. Então eu located acdnfhruvxe isso apareceu:

root@snf-25181:~# locate acdnfhruvx
/etc/init.d/acdnfhruvx
/etc/rc1.d/S01acdnfhruvx
/etc/rc2.d/S01acdnfhruvx
/etc/rc3.d/S01acdnfhruvx
/etc/rc4.d/S01acdnfhruvx
/etc/rc5.d/S01acdnfhruvx

O conteúdo de um deles (são todos iguais): root @ snf-25181: ~ # cat /etc/init.d/acdnfhruvx #! / Bin / sh

chkconfig: 12345 90 90
description: acdnfhruvx
BEGIN INIT INFO
Provides: acdnfhruvx
Required-Start:
Required-Stop:
Default-Start: 1 2 3 4 5
Default-Stop:
Short-Description: acdnfhruvx
END INIT INFO
case $1 in
start)
/bin/acdnfhruvx
;;
stop)
;;
*)
/bin/acdnfhruvx   
;;
esac    

Isso foi encontrado após uma reinicialização, então /bin/acdnfhruvxnão estava em lugar nenhum. Mais tarde, encontrei exes (ELF formatado) em /usr/bin(acho que posso compartilhá-lo se houver um homem corajoso entre vocês)

Uma extensa lista de comandos que eu vi a máquina executando sem saber a origem (de sucessivos ps -ejs e ps auxes:

root     27755  0.0  0.0   1424  1036 ?        Ss   17:40   0:00 ifconfig                        
root     27759  0.0  0.0   1424  1036 ?        Ss   17:40   0:00 who                        
root     27760  0.0  0.0   1424  1040 ?        Ss   17:40   0:00 echo "find"                        
root     27761  0.0  0.0   1424  1036 ?        Ss   17:40   0:00 top                        
root     27762  0.0  0.0   1424  1036 ?        Ss   17:40   0:00 id                        
root     27805  0.0  0.0   1424  1036 ?        Ss   17:40   0:00 gnome-terminal                        
root     27809  0.0  0.0   1424  1040 ?        Ss   17:40   0:00 ifconfig                        
root     27810  0.0  0.0   1424  1044 ?        Ss   17:40   0:00 sh                        
root     27811  0.0  0.0   1424  1040 ?        Ss   17:40   0:00 sleep 1                        
root     27822  0.0  0.0   1424  1040 ?        Ss   17:40   0:00 netstat -an                        
root     27826  0.0  0.0   1424  1036 ?        Ss   17:40   0:00 top                        
root     27829  0.0  0.0   1424  1040 ?        Ss   17:40   0:00 bash                        
root     27833  0.0  0.0   1424  1040 ?        Ss   17:40   0:00 cd /etc                        
root     27834  0.0  0.0   1424  1040 ?        Ss   17:40   0:00 whoami                        
root     27822  0.0  0.0   1424  1040 ?        Ss   17:40   0:00 netstat -an                        
root     27826  0.0  0.0   1424  1036 ?        Ss   17:40   0:00 top                        
root     27829  0.0  0.0   1424  1040 ?        Ss   17:40   0:00 bash                        
root     27833  0.0  0.0   1424  1040 ?        Ss   17:40   0:00 cd /etc                        
root     27834  0.0  0.0   1424  1040 ?        Ss   17:40   0:00 whoami                        

pkillIsso é inútil, pois sempre bifurca, remove arquivos /etc/init.d/e /{usr/,}bintambém não faz sentido, pois após a reinicialização, há uma nova versão (idêntica) do executável. Depois de todas essas informações, tenho duas perguntas: Posso descobrir COMO Fui infectado? Posso me livrar disso? Agradeço antecipadamente!

pankgeorg
fonte
Se o seu servidor foi comprometido, será muito difícil dizer como foi infectado e o que foi feito, porque é trivial para o invasor medicar / remover os arquivos de log. A melhor prática é ter o armazenamento externo de arquivos de log em outro local; portanto, se sua máquina estiver comprometida, você terá pelo menos os logs que antecederam a invasão. Por fim, acho que você precisará reinstalar - a única maneira de garantir um sistema limpo e não infectado.

Respostas:

24

Sofremos uma infecção semelhante no Suse, provavelmente através do login de força bruta ssh .

As etapas para limpeza são:

  1. Verifique o arquivo /etc/crontab. Você provavelmente tem uma entrada para chamar o vírus a cada 3 minutos

    */3 * * * * root /etc/cron.hourly/cron.sh
    

    Exclua esta linha.

  2. Identifique o processo pai do vírus. O rguoywvrfno seu ps -ej. Os outros proceses são criados e mortos continuamente.
  3. Pare com isso, não mate, com kill -STOP 1632
  4. Verifique com o outro ps -ejque apenas o pai vive, os filhos devem morrer rapidamente
  5. Agora você pode excluir os arquivos em /usr/bine /etc/init.d. Existem variantes do vírus que também usa /bootou /bin. Use ls -lt | headpara procurar arquivos que foram modificados recentemente.
  6. Verifique o script /etc/cron.hourly/cron.sh. No nosso servidor, ele estava chamando outra cópia do vírus /lib/libgcc.so. Exclua os dois arquivos.
  7. Agora você pode matar definitivamente o rguoywvrfprocesso.
Serxipc
fonte
1
existem alguns maus scripts em /etc/rc6.d/, eles começam com K90
mazgalici
1
faça um find / -name "*rguoywvrf*"para encontrar os outros arquivos, substituindo rguoywvrfpor qualquer que seja o nome do arquivo
Mohamed Hafez
1
Verifique este link: garasiku.web.id/web/joomla/index.php/security/…
DarckBlezzer
3

Para responder suas perguntas:

  1. Sem as precauções necessárias (syslog externo, IDS, monitoramento de logs etc.), você provavelmente nunca descobrirá o que aconteceu.
  2. Eu teria que concordar com Matt. Você investirá tempo para colocar uma máquina em funcionamento na qual nunca confiará. Na minha opinião, a melhor solução é mover os dados para fora do local e refazer a máquina.

Claro, pelo que vale, essa é apenas a minha opinião. Porém, ao refazer a máquina, é claro que você pode tomar as precauções necessárias e se proteger melhor no futuro.

Eamonn Travers
fonte
1

isso é uma ameaça que gera muitos problemas porque inicia um ataque DDOS e gera milhares de conexões com servidores externos na porta 80, mas, se não for intencional ou não, tende a sobrecarregar sua conexão até que os roteadores / firewalls congelem, se não houver Regras de ataque do DDOS.

agora, como você pode remover essa ameaça?

  1. encontre sua ameaça, use

Centos / redhat

ps -ely 

Debian

ps -ej

você verá:

3158 3158 3158 ? 00:00:00 bvxktwwnsb
3162 3162 3162 ? 00:00:00 bvxktwwnsb
3163 3163 3163 ? 00:00:00 bvxktwwnsb
3164 3164 3164 ? 00:00:00 bvxktwwnsb

o " bvxktwwnsb" é seu alvo

  1. então você precisa inicializar o servidor linux no modo de usuário único, fazer qualquer alteração no modo multiusuário é inútil, geralmente você pode alternar com o seguinte comando:

    telinit S

  2. depois disso, você precisa excluir os arquivos executados na inicialização

em Centos / Redhat, o procedimento é

Etapa a)

cd /etc/init.d          
ll -tr 

Se o último comando ordenar seus arquivos na data inversa, você verá um último 1 ou 2 arquivos no final com o nome

acdnfhruvx
kmrkuwbrng
gqpjiestmf
bvxktwwnsb

você precisa ver o conteúdo

cat /etc/init.d/gqpjiestmf

normalmente você verá a execução de um arquivo localizado em / bin ou / usr / sbin com o mesmo nome

você precisa excluir os dois arquivos.

Etapa b)

cd /etc/
ll -tr 

verifique se o seu arquivo crontab foi alterado recentemente, verifique seu conteúdo, procure uma linha

*/3 * * * * root /etc/cron.hourly/udev.sh

ou

*/3 * * * * root /etc/cron.hourly/crontab.sh 

você precisa editar o arquivo e remover essa linha.

verifique o conteúdo de udev.shou crontab.she você verá algo parecido com isto

#!/bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin
cp /lib/libgcc4.so /lib/libgcc4.4.so
/lib/libgcc4.4.so

você precisa remover o arquivo "libgcc4.4.so" ou qualquer outro mencionado lá (alterar as permissões também funcionaria, por exemplo chmod a-x libgcc.so)

reinicie o servidor e tudo deve ficar bem.

Para debian / ubuntu e parentes, use:

locate bvxktwwnsb

e exclua os arquivos encontrados em / etc e / bin

Espero que isso ajude muitas pessoas.

Jorge Arenas
fonte
Sua resposta pode ser difícil de ler porque não parece estar formatada corretamente. Se precisar de ajuda, o centro de ajuda terá mais informações sobre como formatar corretamente as postagens.
precisa saber é o seguinte
0

Eu encontrei algo!!!

procure / etc / crontab

No meu servidor, há um cronjob a cada 3 minutos para executar algo:

*/3 * * * * root /etc/cron.hourly/cron.sh

cat cron.sh

#!/bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin
for i in `cat /proc/net/dev|grep :|awk -F: {'print $1'}`; do ifconfig $i up& done
cp /lib/libgcc.so /lib/libgcc.so.bak
/lib/libgcc.so.bak

Minha solução:

  1. desabilite a permissão (rwx 000) para: /etc/init.d/ {/ usr} / bin / /lib/libgcc.so
  2. remova a entrada do cronjob em / etc / crontab
  3. remova o script cron em /etc/cron.hourly/cron.sh
  4. reinicie o servidor

nota: os locais dos arquivos podem variar

Andi Bobinsky
fonte
0

Truque adicional complementar à solução Serhii. Parar todos os processos pode ser difícil, pois isso gera spam na rede e na CPU. Portanto, adicione esta linha ao seu /etc/crontabpara interromper automaticamente todos os processos desagradáveis ​​(interrompe todos os processos com 10 caracteres no nome a cada três minutos):

*/3 * * * * root pstree -ap | grep -E -- '-[a-z]{10},' | cut -d, -f2 | xargs kill -STOP 2>/dev/null

É uma boa coisa após a limpeza, para garantir que o processo não retorne. Execute-o por um tempo até ter certeza de que sua caixa está limpa.

lzap
fonte