DDoS-Virus-Infektion (als Unix-Dienst) auf einem Debian 8 VM-Webserver

Ich verwalte ein (vollständig aktualisiertes) WordPress für ein Schülerteam auf einer virtuellen Maschine mit dem Dienst ~ okeanos für ein paar Jahre. Heute teilte mir der Helpdesk mit, dass ich DDoS-Angriffe durchführe, was ich natürlich nicht bin (mit diesem Dienst sind meine akademischen Qualifikationen verbunden ..). Nachdem sie die Maschine angehalten hatten und ich ihr Mailing-System geflammt hatte, versuchte ich herauszufinden, was passiert ist.

Als erstes starte ich ein, um ps -ejzu überprüfen, was läuft:

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

Beachten Sie die bvxktwwnsb und die rguoywvrf

Dann habe ich a gemacht ps aux, um die Dienste zu bekommen (wieder ein Schwanz):

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     

Beachten Sie die Punkte [-4: -1]. Dann habe ich online darüber gefunden, chkconfig --listalso habe ich das ausgeführt und das ist herausgekommen:

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 bis 5 wo onaber ich sie gedreht habe off. Dann habe ich neu gestartet und es hat den Namen geändert. Dann habe ich locatedie acdnfhruvxund diese rausgeknallt:

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

Der Inhalt von einem von ihnen (sie sind alle gleich): 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    

Dies wurde nach einem Neustart gefunden, so /bin/acdnfhruvxwar nirgendwo. Später fand ich Exes (ELF-formatiert) /usr/binunter

Eine umfangreiche Liste der Befehle, die ich sah, als die Maschine ausgeführt wurde, ohne die Herkunft zu kennen (von aufeinanderfolgenden ps -ejs und 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 ist sinnlos, da es immer nach Dateien fragt, diese entfernt /etc/init.d/und /{usr/,}binauch sinnlos, da es nach dem Neustart eine neue (identische) Version der ausführbaren Datei gibt. Nach all diesen Informationen habe ich zwei Fragen: Kann ich herausfinden, wie ich infiziert wurde? Kann ich das loswerden? Danke im Voraus!

Wir haben eine ähnliche Infektion bei Suse erlitten, wahrscheinlich durch die Anmeldung bei ssh brute force .

Die zu reinigenden Schritte sind:

1. Überprüfen Sie die Datei /etc/crontab. Sie haben wahrscheinlich alle 3 Minuten einen Eintrag, um den Virus aufzurufen

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

   Löschen Sie diese Zeile.

2. Identifizieren Sie den übergeordneten Prozess des Virus. Das rguoywvrfin deinem ps -ej. Die anderen Prozesse werden fortlaufend erstellt und beendet.
3. Hör auf, töte es nicht, mit kill -STOP 1632
4. Überprüfen Sie mit einem anderen, ps -ejdass nur die Eltern leben, die Kinder sollten schnell sterben
5. Jetzt können Sie die Dateien in /usr/binund löschen /etc/init.d. Es gibt Varianten des Virus, die auch /bootoder verwenden /bin. Verwenden Sie ls -lt | headdiese Option , um nach Dateien zu suchen, die kürzlich geändert wurden.
6. Checken Sie das Skript ein /etc/cron.hourly/cron.sh. Auf unserem Server rief es eine andere Kopie des Virus auf /lib/libgcc.so. Löschen Sie beide Dateien.
7. Jetzt können Sie den rguoywvrfProzess definitiv beenden.

Um Ihre Fragen zu beantworten:

1. Ohne die notwendigen Vorkehrungen (externes Syslog, IDS, Protokollüberwachung usw.) werden Sie wahrscheinlich nie herausfinden, was passiert ist.
2. Ich würde Matt zustimmen müssen. Sie investieren Zeit, um eine Maschine zum Laufen zu bringen, der Sie nie wirklich vertrauen werden. Meiner Meinung nach ist die beste Lösung, die Daten vom Standort zu verschieben und die Maschine zu wiederholen.

Natürlich, für was es sich lohnt, ist dies nur meine Meinung. Selbstverständlich können Sie beim Wiederherstellen der Maschine die erforderlichen Vorsichtsmaßnahmen treffen und sich in Zukunft besser schützen.

Dies ist eine Bedrohung, die viele Probleme verursacht, da sie einen DDOS-Angriff startet und Tausende von Verbindungen zu externen Servern auf Port 80 herstellt. Wenn dies nicht beabsichtigt oder nicht der Fall ist, wird die Verbindung überlastet, bis die Router / Firewalls einfrieren, wenn dies nicht der Fall ist DDOS-Angriffsregeln.

Wie können Sie diese Bedrohung entfernen?

1. Finden Sie Ihre Bedrohung, verwenden Sie

Centos / Redhat

ps -ely 

Debian

ps -ej

du wirst sehen:

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

Das " bvxktwwnsb" ist Ihr Ziel

2. dann musst du deinen linux server im single user modus booten, änderungen im multiuser modus machen ist sinnlos, normalerweise kannst du mit folgendem befehl wechseln:

   telinit S

3. Danach müssen Sie Dateien löschen, die beim Start ausgeführt werden

in Centos / Redhat ist das Verfahren

Schritt a)

cd /etc/init.d          
ll -tr 

Mit dem letzten Befehl ordnen Sie Ihre Dateien in umgekehrter Reihenfolge an. Am Ende werden die letzten 1 oder 2 Dateien mit dem Namen like angezeigt

acdnfhruvx
kmrkuwbrng
gqpjiestmf
bvxktwwnsb

Sie müssen den Inhalt sehen

cat /etc/init.d/gqpjiestmf

Normalerweise sehen Sie die Ausführung einer Datei, die sich in / bin oder / usr / sbin mit demselben Namen befindet

Sie müssen beide Dateien löschen.

Schritt b)

cd /etc/
ll -tr 

Überprüfen Sie, ob Ihre crontab-Datei kürzlich geändert wurde, schauen Sie sich den Inhalt an und suchen Sie nach einer Zeile

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

oder

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

Sie müssen die Datei bearbeiten und diese Zeile entfernen.

Überprüfen Sie den Inhalt von udev.shoder crontab.shund Sie werden so etwas sehen

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

Sie müssen die Datei "libgcc4.4.so" oder eine andere dort erwähnte Datei entfernen (das Ändern der Berechtigungen würde zum Beispiel auch funktionieren chmod a-x libgcc.so).

Starten Sie Ihren Server neu und alles sollte in Ordnung sein.

Für Debian / Ubuntu und Verwandte:

locate bvxktwwnsb

und löschen Sie die Dateien in / etc und / bin

hoffe das hilft vielen menschen.

Ich habe etwas gefunden!!!

Suchen Sie nach / etc / crontab

Auf meinem Server gibt es alle 3 Minuten einen Cronjob, um etwas auszuführen:

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

Meine Lösung:

1. Deaktivieren Sie die Berechtigung (rwx 000) für: /etc/init.d/ {/ usr} / bin / /lib/libgcc.so
2. Entfernen Sie den Cronjob-Eintrag in / etc / crontab
3. Entfernen Sie das Cron-Skript in /etc/cron.hourly/cron.sh
4. Starten Sie den Server neu

Hinweis: Die Speicherorte der Dateien können variieren

Zusätzlicher Trick zur Serhii-Lösung. Das Stoppen aller Prozesse kann schwierig sein, da dieses Ding ein Spam-Netzwerk und eine CPU darstellt. Fügen Sie daher diese Zeile zu Ihrer hinzu, /etc/crontabum alle bösen Prozesse automatisch zu stoppen (stoppt alle drei Minuten alle Prozesse mit 10 Zeichen im Namen):

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

Dies ist eine gute Sache, um nach der Bereinigung sicherzustellen, dass der Prozess nicht zurückkehrt. Führen Sie es eine Weile aus, bis Sie sicher sind, dass Ihre Box sauber ist.