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 -ej
pour 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 aux
pour 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 --list
donc 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ù on
mais je les ai tournés off
. Puis j'ai redémarré et il a changé de nom. Alors je locate
d l' acdnfhruvx
ce 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/acdnfhruvx
nulle 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 -ej
s et ps aux
es 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
pkill
ing est inutile, car il bifurque toujours, supprimant des fichiers /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 m'en débarrasser? Merci d'avance!
Réponses:
Nous avons subi une infection similaire sur Suse, probablement via la connexion par force brute ssh .
Les étapes de nettoyage sont les suivantes:
Vérifiez le fichier
/etc/crontab
. Vous avez probablement une entrée pour appeler le virus toutes les 3 minutesSupprimez cette ligne.
rguoywvrf
dans votreps -ej
. Les autres processus sont créés et tués continuellement.kill -STOP 1632
ps -ej
que seul le parent vit, les enfants devraient mourir rapidement/usr/bin
et/etc/init.d
. Il existe des variantes du virus qui utilisent également/boot
ou/bin
. Utilisezls -lt | head
pour rechercher les fichiers qui ont été modifiés récemment./etc/cron.hourly/cron.sh
. Sur notre serveur, il appelait une autre copie du virus/lib/libgcc.so
. Supprimez les deux fichiers.rguoywvrf
processus.la source
find / -name "*rguoywvrf*"
pour trouver les autres fichiers, en les remplaçantrguoywvrf
par le nom de votre fichierPour répondre à vos questions:
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.
la source
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?
Centos / redhat
Debian
tu verras:
le "
bvxktwwnsb
" est votre objectifalors 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
après cela, vous devez supprimer les fichiers exécutés au démarrage
dans Centos / Redhat, la procédure est
Étape a)
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
vous devez voir le contenu
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)
vérifiez si votre fichier crontab a été modifié récemment, regardez son contenu, recherchez une ligne
ou
vous devez modifier le fichier et supprimer cette ligne.
vérifiez le contenu de
udev.sh
oucrontab.sh
et vous verrez quelque chose comme çavous 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:
et supprimez les fichiers trouvés dans / etc et / bin
espérons que cela aide beaucoup de gens.
la source
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:
Ma solution:
remarque: l'emplacement des fichiers peut varier
la source
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/crontab
pour arrêter automatiquement tous les processus méchants (arrête tous les processus avec 10 caractères dans le nom toutes les trois minutes):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.
la source