Infección por el virus DDoS (como servicio unix) en un servidor web Debian 8 VM

Mantengo un Wordpress (totalmente actualizado) para un equipo de estudiantes en una máquina virtual en el servicio ~ okeanos durante un par de años. Hoy, el servicio de asistencia me informó que estoy llevando a cabo ataques DDoS, lo cual, por supuesto, no estoy (este servicio tiene mis credenciales académicas conectadas ...). Después de que suspendieron la máquina y encendí su sistema de correo, traté de averiguar qué sucedió.

En primer lugar, ejecuto un ps -ejpara verificar lo que se está ejecutando:

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 el bvxktwwnsb y el rguoywvrf

Luego hice una ps auxpara obtener los servicios (de nuevo, una cola):

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     

Tenga en cuenta los elementos [-4: -1]. Luego encontré en línea acerca de chkconfig --listlo que ejecuté y esto apareció:

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 donde onpero los convertí off. Luego reinicié y ha cambiado de nombre. Luego hice locateel acdnfhruvxy esto salió:

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

El contenido de uno de ellos (todos son iguales): 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    

Esto se encontró después de un reinicio, por /bin/acdnfhruvxlo que no estaba en ninguna parte. Más tarde encontré exes (con formato ELF) en /usr/bin(creo que puedo compartirlo si hay un hombre valiente entre ustedes)

Una extensa lista de los comandos vi la máquina ejecutar sin conocer el origen (de sucesivas ps -ejs y 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                        

pkilling no tiene sentido, ya que siempre se bifurca, elimina archivos /etc/init.d/y /{usr/,}bintampoco tiene sentido ya que después del reinicio hay una nueva versión (idéntica) del ejecutable. Después de toda esta información, tengo dos preguntas: ¿Puedo averiguar CÓMO fui infectado? ¿Puedo deshacerme de esto? ¡Gracias de antemano!

Sufrimos una infección similar en Suse, probablemente a través del inicio de sesión de fuerza bruta ssh .

Los pasos para limpiar son:

1. Revisa el archivo /etc/crontab. Probablemente tenga una entrada para llamar al virus cada 3 minutos.

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

   Eliminar esta línea

2. Identificar el proceso padre del virus. El rguoywvrfen tu ps -ej. Los otros procesos se crean y eliminan continuamente.
3. Para, no lo mates, con kill -STOP 1632
4. Consulte con otro ps -ejque solo vive el padre, los niños deben morir rápidamente
5. Ahora puede eliminar los archivos en /usr/biny /etc/init.d. Hay variantes del virus que también usa /booto /bin. Use ls -lt | headpara buscar archivos que se hayan modificado recientemente.
6. Revise el script en /etc/cron.hourly/cron.sh. En nuestro servidor estaba llamando a otra copia del virus /lib/libgcc.so. Eliminar ambos archivos.
7. Ahora puedes matar definitivamente el rguoywvrfproceso.

Para responder tu pregunta:

1. Sin las precauciones necesarias (syslog fuera del sitio, IDS, monitoreo de registros, etc.) probablemente nunca se enterará de lo que sucedió.
2. Tendría que estar de acuerdo con Matt. Invertirá tiempo para poner en funcionamiento una máquina en la que nunca confiará realmente. En mi opinión, la mejor solución es mover los datos fuera del sitio y rehacer la máquina.

Por supuesto, por lo que vale, esta es solo mi opinión. Sin embargo, al rehacer la máquina, por supuesto, puede tomar las precauciones necesarias y protegerse mejor en el futuro.

Esta es una amenaza que genera muchos problemas porque lanza un ataque DDOS y genera miles de conexiones a servidores externos en el puerto 80, pero no lo hago si intencionalmente o no, tiende a sobrecargar su conexión hasta que los enrutadores / firewalls se congelen si no hay Reglas de ataque DDOS.

ahora, ¿cómo puedes eliminar esta amenaza?

1. encuentra tu amenaza, usa

Centos / redhat

ps -ely 

Debian

ps -ej

ya verás:

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

el " bvxktwwnsb" es tu objetivo

2. entonces debe iniciar su servidor Linux en modo de usuario único, hacer cambios en el modo multiusuario no tiene sentido, por lo general, puede cambiar con el siguiente comando:

   telinit S

3. después de eso, debe eliminar los archivos que se ejecutan al inicio

en Centos / Redhat el procedimiento es

Paso a)

cd /etc/init.d          
ll -tr 

el último comando ordena tus archivos en fecha inversa, vas a ver uno o dos archivos al final con el nombre como

acdnfhruvx
kmrkuwbrng
gqpjiestmf
bvxktwwnsb

necesitas ver el contenido

cat /etc/init.d/gqpjiestmf

normalmente verá la ejecución de un archivo ubicado en / bin o / usr / sbin con el mismo nombre

necesitas eliminar ambos archivos.

Paso b)

cd /etc/
ll -tr 

compruebe si su archivo crontab ha cambiado recientemente, mire su contenido, busque una línea

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

o

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

necesita editar el archivo y eliminar esa línea.

verifique el contenido de udev.sho crontab.shy verá algo como esto

#!/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

debe eliminar el archivo "libgcc4.4.so" o cualquier otro mencionado allí (cambiar los permisos también funcionaría, por ejemplo chmod a-x libgcc.so)

reinicie su servidor y todo debería estar bien.

Para debian / ubuntu y parientes use:

locate bvxktwwnsb

y elimine los archivos encontrados en / etc y / bin

Espero que esto ayude a mucha gente.

¡¡¡Encontré algo!!!

busque / etc / crontab

En mi servidor, hay un cronjob cada 3 minutos para ejecutar 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

Mi solución:

1. deshabilitar permiso (rwx 000) para: /etc/init.d/ {/ usr} / bin / /lib/libgcc.so
2. eliminar la entrada de cronjob en / etc / crontab
3. eliminar el script cron en /etc/cron.hourly/cron.sh
4. reiniciar el servidor

nota: las ubicaciones de los archivos pueden variar

Truco adicional complementario a la solución Serhii. Detener todos los procesos puede ser difícil ya que esto afecta la red y la CPU. Por lo tanto, agregue esta línea a su /etc/crontabpara DETENER automáticamente todos los procesos desagradables (detiene todos los procesos con 10 caracteres en el nombre cada tres minutos):

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

Es bueno hacer esto después de la limpieza para asegurarse de que el proceso no regrese. Ejecútelo por un tiempo hasta que esté seguro de que su caja está limpia.