Infection par le virus DDoS (en tant que service Unix) sur un serveur Web Debian 8 VM

Je maintiens un Wordpress (entièrement mis à jour) pour une équipe d'étudiants sur une machine virtuelle sur le service ~ okeanos pendant quelques années. Aujourd'hui, le helpdesk m'a informé que je menais des attaques DDoS, ce que - bien sûr - je ne suis pas (ce service a mes références académiques connectées ..). Après qu'ils aient suspendu la machine et que j'ai flambé leur système postal, j'ai essayé de découvrir ce qui s'était passé.

Tout d'abord, je lance un ps -ejpour vérifier ce qui fonctionne:

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

Remarquez le bvxktwwnsb et le rguoywvrf

Ensuite, j'ai fait un ps auxpour obtenir les services (encore une fois):

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     

Notez les éléments [-4: -1]. Ensuite, j'ai trouvé en ligne sur chkconfig --listdonc je lance cela et cela est sorti:

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 à 5 où onmais je les ai tournés off. Puis j'ai redémarré et il a changé de nom. Alors je located l' acdnfhruvxce qui émergea:

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

Le contenu de l'un d'eux (ils sont tous les mêmes): 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    

Cela a été trouvé après un redémarrage, donc /bin/acdnfhruvxnulle part. Plus tard, j'ai trouvé des ex (format ELF) à /usr/bin(je pense que je peux le partager s'il y a un homme courageux parmi vous)

Une liste complète des commandes que j'ai vu la machine s'exécuter sans connaître l'origine (à partir des ps -ejs et ps auxes successifs :

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 est inutile, car il bifurque toujours, supprimant des fichiers /etc/init.d/et /{usr/,}binest également inutile car après le redémarrage, il existe une nouvelle version (identique) de l'exécutable. Après toutes ces informations, j'ai deux questions: puis-je savoir COMMENT j'ai été infecté? Puis-je m'en débarrasser? Merci d'avance!

Nous avons subi une infection similaire sur Suse, probablement via la connexion par force brute ssh .

Les étapes de nettoyage sont les suivantes:

1. Vérifiez le fichier /etc/crontab. Vous avez probablement une entrée pour appeler le virus toutes les 3 minutes

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

   Supprimez cette ligne.

2. Identifiez le processus parent du virus. Le rguoywvrfdans votre ps -ej. Les autres processus sont créés et tués continuellement.
3. Arrêtez-le, ne le tuez pas, avec kill -STOP 1632
4. Vérifiez auprès d'un autre ps -ejque seul le parent vit, les enfants devraient mourir rapidement
5. Vous pouvez maintenant supprimer les fichiers dans /usr/binet /etc/init.d. Il existe des variantes du virus qui utilisent également /bootou /bin. Utilisez ls -lt | headpour rechercher les fichiers qui ont été modifiés récemment.
6. Archivez le script /etc/cron.hourly/cron.sh. Sur notre serveur, il appelait une autre copie du virus /lib/libgcc.so. Supprimez les deux fichiers.
7. Maintenant, vous pouvez définitivement tuer le rguoywvrfprocessus.

Pour répondre à vos questions:

1. Sans les précautions nécessaires (syslog hors site, IDS, surveillance des journaux, etc.), vous ne saurez probablement jamais ce qui s'est passé.
2. Je devrais être d'accord avec Matt. Vous investirez du temps pour faire fonctionner une machine à laquelle vous ne ferez jamais vraiment confiance. À mon avis, la meilleure solution est de déplacer les données hors site et de refaire la machine.

Bien sûr, pour ce que ça vaut, ce n'est que mon avis. Cependant, lorsque vous refaites la machine, vous pouvez bien sûr prendre les précautions nécessaires et mieux vous protéger à l'avenir.

c'est une menace qui génère beaucoup de problèmes car lancez une attaque DDOS et générez des milliers de connexions aux serveurs externes sur le port 80, mais je ne le fais pas si intentionnellement ou non, cela tend à surcharger votre connexion jusqu'à ce que les routeurs / pare-feu se bloquent s'il n'y en a pas Règles d'attaque DDOS.

maintenant, comment pouvez-vous supprimer cette menace?

1. trouvez votre menace, utilisez

Centos / redhat

ps -ely 

Debian

ps -ej

tu verras:

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

le " bvxktwwnsb" est votre objectif

2. alors vous devez démarrer votre serveur linux en mode mono-utilisateur, apporter des modifications en mode multi-utilisateur est inutile, vous pouvez généralement basculer avec la commande suivante:

   telinit S

3. après cela, vous devez supprimer les fichiers exécutés au démarrage

dans Centos / Redhat, la procédure est

Étape a)

cd /etc/init.d          
ll -tr 

la dernière commande commande vos fichiers en date inverse, vous allez voir un dernier 1 ou 2 fichiers à la fin avec un nom comme

acdnfhruvx
kmrkuwbrng
gqpjiestmf
bvxktwwnsb

vous devez voir le contenu

cat /etc/init.d/gqpjiestmf

normalement, vous verrez l'exécution d'un fichier situé dans / bin ou / usr / sbin du même nom

vous devez supprimer les deux fichiers.

Étape b)

cd /etc/
ll -tr 

vérifiez si votre fichier crontab a été modifié récemment, regardez son contenu, recherchez une ligne

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

ou

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

vous devez modifier le fichier et supprimer cette ligne.

vérifiez le contenu de udev.shou crontab.shet vous verrez quelque chose comme ça

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

vous devez supprimer le fichier "libgcc4.4.so" ou tout autre qui y est mentionné (la modification des autorisations fonctionnerait également, par exemple chmod a-x libgcc.so)

redémarrez votre serveur et tout devrait bien se passer.

Pour Debian / Ubuntu et ses proches, utilisez:

locate bvxktwwnsb

et supprimez les fichiers trouvés dans / etc et / bin

espérons que cela aide beaucoup de gens.

J'ai trouvé quelque chose!!!

recherchez / etc / crontab

Sur mon serveur, il y a un cronjob toutes les 3 minutes pour exécuter quelque chose:

*/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

Ma solution:

1. désactiver l'autorisation (rwx 000) pour: /etc/init.d/ {/ usr} / bin / /lib/libgcc.so
2. supprimer l'entrée cronjob dans / etc / crontab
3. supprimer le script cron dans /etc/cron.hourly/cron.sh
4. redémarrez le serveur

remarque: l'emplacement des fichiers peut varier

Astuce supplémentaire complémentaire à la solution Serhii. L'arrêt de tous les processus peut être difficile car cette chose spamme le réseau et le processeur. Par conséquent, ajoutez cette ligne à votre /etc/crontabpour arrêter automatiquement tous les processus méchants (arrête tous les processus avec 10 caractères dans le nom toutes les trois minutes):

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

C'est une bonne chose à faire après le nettoyage pour vous assurer que le processus ne revient pas. Exécutez-le pendant un certain temps jusqu'à ce que vous soyez sûr que votre boîte est propre.