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

Question

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

Tout d'abord, je lance un ps -ej pour vérifier ce qui est en cours d'exécution:

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

Notez le bvxktwwnsb et le rguoywvrf

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

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 à propos de chkconfig --list alors je l'ai exécuté et ceci est apparu:

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ù on mais je les ai transformés off. Ensuite, j'ai redémarré et le nom a changé. Ensuite, j'ai located la acdnfhruvx et ceci est apparu:

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 identiques): 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/acdnfhruvx n'était nulle part. Plus tard, j'ai trouvé des exes (formatés ELF) à /usr/bin (je pense pouvoir les partager s'il y a un homme courageux parmi vous)

Une liste complète des commandes que j'ai vues sur la machine s'exécuter sans connaître l'origine (à partir de 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, puisqu'il supprime toujours, supprimer des fichiers de /etc/init.d/ et /{usr/,}bin est é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 me débarrasser de ça? Merci d'avance!

Serxipc · Accepted Answer

Nous avons subi une infection similaire sur Suse, probablement par le biais de login en force brute ssh .

Les étapes pour nettoyer sont:

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 
```
Supprimer cette ligne.
Identifiez le processus parent du virus. La rguoywvrf dans votre ps -ej. Les autres processus sont créés et tués continuellement.
Arrêtez-le, ne le tuez pas, avec kill -STOP 1632
Vérifiez avec un autre ps -ej que seul le parent vit, les enfants devraient mourir rapidement
Vous pouvez maintenant supprimer les fichiers dans /usr/bin et /etc/init.d. Il existe des variantes du virus qui utilisent également /boot ou /bin. Utilisez ls -lt | head pour rechercher les fichiers récemment modifiés.
Vérifiez le script dans /etc/cron.hourly/cron.sh. Sur notre serveur, il appelait une autre copie du virus sur /lib/libgcc.so. Supprimer les deux fichiers.
Maintenant, vous pouvez définitivement arrêter le processus rguoywvrf.

Eamonn Travers · Answer

Pour répondre à vos questions:

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

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

Jorge Arenas · Answer

c'est une menace qui génère beaucoup de problèmes car lance une attaque DDOS et génère des milliers de connexions aux serveurs externes sur le port 80, mais je ne le fais pas intentionnellement ou non, cela a tendance à 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?

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

"bvxktwwnsb" est votre cible

ensuite, vous devez démarrer votre serveur linux en mode mono-utilisateur, toute modification en mode multi-utilisateur est inutile, vous pouvez généralement basculer avec la commande suivante:

telinit S
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 ordonne vos fichiers à la date inversée, vous allez voir un ou deux derniers fichiers à la fin avec nommés 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 avec le même nom

vous devez supprimer les deux fichiers.

Étape b)

cd /etc/ ll -tr

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

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

ou

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

vous devez éditer le fichier et supprimer cette ligne.

vérifiez le contenu de udev.sh ou crontab.sh et vous verrez quelque chose comme ceci

#!/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 fichier qui y est mentionné (modifier les 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 présents dans/etc et/bin

espérons que cela aidera beaucoup de gens.

lzap · Answer

Astuce supplémentaire complémentaire à la solution Serhii. Il peut être difficile d’arrêter tous les processus, car cette opération est un spam sur le réseau et le processeur. Par conséquent, ajoutez cette ligne à votre /etc/crontab pour arrêter automatiquement tous les processus malveillants (arrête tous les processus avec un nom de 10 caractères 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 retourne pas. Lancez-le un moment jusqu'à ce que vous soyez sûr que votre boîte est propre.

Andi Bobinsky · Answer

J'ai trouvé quelque chose!!!

cherche/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:

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

remarque: l'emplacement des fichiers peut varier