Zakażenie wirusem DDoS (jako usługa uniksowa) na serwerze Debian 8 VM Webserver

Utrzymuję (w pełni zaktualizowany) Wordpress dla zespołu studentów na maszynie wirtualnej w serwisie ~ okeanos przez kilka lat. Dzisiaj dział informacyjny poinformował mnie, że przeprowadzam ataki DDoS, których - oczywiście - nie jestem (ta usługa ma połączone moje akademickie kwalifikacje ...). Po zawieszeniu maszyny i podpaleniu ich systemu pocztowego próbowałem dowiedzieć się, co się stało.

Przede wszystkim uruchamiam, ps -ejaby sprawdzić, co działa:

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

Zwróć uwagę na bvxktwwnsb i rguoywvrf

Potem zrobiłem a, ps auxaby uzyskać usługi (znowu ogon):

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     

Zwróć uwagę na pozycje [-4: -1]. Potem znalazłem w Internecie, chkconfig --listwięc uruchomiłem to i wyskoczyło:

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 do 5, onale je zmieniłem off. Następnie zrestartowałem się i zmieniłem nazwę. Potem zrobiłem locateto acdnfhruvxi wyskoczyło:

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

Zawartość jednego z nich (wszystkie są takie same): 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    

Zostało to znalezione po ponownym uruchomieniu, więc /bin/acdnfhruvxnigdzie nie było. Później znalazłem exes (w formacie ELF) w /usr/bin(myślę, że mogę się nim podzielić, jeśli jest odważny człowiek)

Obszerna lista poleceń, które widziałem, jak maszyna wykonuje bez znajomości pochodzenia (z kolejnych ps -ejs i 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 jest bezcelowy, ponieważ zawsze rozwidla, usuwając pliki /etc/init.d/i /{usr/,}binjest również bezcelowy, ponieważ po restarcie pojawia się nowa (identyczna) wersja pliku wykonywalnego. Po tych wszystkich informacjach mam dwa pytania: Czy mogę dowiedzieć się, JAK ZOSTAŁEM zainfekowany? Czy mogę się tego pozbyć? Z góry dziękuję!

Podobna infekcja wystąpiła na Suse, prawdopodobnie poprzez logowanie ssh brute force .

Kroki czyszczenia to:

1. Sprawdź plik /etc/crontab. Prawdopodobnie masz wpis, aby wywoływać wirusa co 3 minuty

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

   Usuń tę linię.

2. Zidentyfikuj proces macierzysty wirusa. W rguoywvrftwoim ps -ej. Pozostałe procesy są tworzone i zabijane w sposób ciągły.
3. Przestań, nie zabijaj go kill -STOP 1632
4. Sprawdź z innym, ps -ejże mieszka tylko rodzic, dzieci powinny umrzeć szybko
5. Teraz możesz usunąć pliki z /usr/bini /etc/init.d. Istnieją warianty wirusa, który również używa /bootlub /bin. Służy ls -lt | headdo wyszukiwania ostatnio zmodyfikowanych plików.
6. Sprawdź skrypt w /etc/cron.hourly/cron.sh. Na naszym serwerze wołał kolejną kopię wirusa /lib/libgcc.so. Usuń oba pliki.
7. Teraz możesz zdecydowanie zabić ten rguoywvrfproces.

Aby odpowiedzieć na pytania:

1. Bez niezbędnych środków ostrożności (syslog poza witryną, IDS, monitorowanie dziennika itp.) Prawdopodobnie nigdy nie dowiesz się, co się stało.
2. Musiałbym się zgodzić z Mattem. Zainwestujesz czas na uruchomienie maszyny, której tak naprawdę nigdy nie będziesz ufać. Moim zdaniem najlepszym rozwiązaniem jest przeniesienie danych z witryny i ponowne wykonanie komputera.

Oczywiście, ile warte jest, to tylko moja opinia. Chociaż podczas przerabiania urządzenia możesz oczywiście podjąć niezbędne środki ostrożności i lepiej zabezpieczyć się w przyszłości.

jest to zagrożenie, które generuje wiele problemów, ponieważ uruchamia atak DDOS i generuje tysiące połączeń z serwerami zewnętrznymi na porcie 80, ale nie robię tego, jeśli celowo lub nie, to ma tendencję do przeciążania twojego połączenia, dopóki routery / zapory ogniowe nie zostaną zawieszone, jeśli nie ma Reguły ataku DDOS.

teraz, jak możesz usunąć to zagrożenie?

1. znajdź swoje zagrożenie, użyj

Centos / redhat

ps -ely 

Debian

ps -ej

zobaczysz:

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” jest twoim celem

2. następnie musisz uruchomić serwer Linux w trybie pojedynczego użytkownika, aby wszelkie zmiany w trybie wielu użytkowników były bezcelowe, zwykle możesz przełączyć za pomocą następującego polecenia:

   telinit S

3. potem musisz usunąć pliki uruchamiane przy starcie

w Centos / Redhat procedura jest

Krok a)

cd /etc/init.d          
ll -tr 

po ostatnim poleceniu uporządkuj pliki w odwrotnym terminie, zobaczysz na końcu 1 lub 2 pliki o nazwie like

acdnfhruvx
kmrkuwbrng
gqpjiestmf
bvxktwwnsb

musisz zobaczyć treść

cat /etc/init.d/gqpjiestmf

normalnie zobaczysz wykonanie pliku znajdującego się w / bin lub / usr / sbin o tej samej nazwie

musisz usunąć oba pliki.

Krok b)

cd /etc/
ll -tr 

sprawdź, czy plik crontab został ostatnio zmieniony, spójrz na jego zawartość, wyszukaj wiersz

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

lub

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

musisz edytować plik i usunąć tę linię.

sprawdź zawartość udev.shlub crontab.sha zobaczysz coś takiego

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

musisz usunąć plik „libgcc4.4.so” lub inny tam wymieniony (na przykład zmiana uprawnień również by działała chmod a-x libgcc.so)

uruchom ponownie serwer i wszystko powinno być w porządku.

W przypadku Debiana / Ubuntu i krewnych użyj:

locate bvxktwwnsb

i usuń pliki znalezione w / etc i / bin

mam nadzieję, że to pomoże wielu ludziom.

Znalazłem coś!!!

poszukaj / etc / crontab

Na moim serwerze co 3 minuty występuje cronjob do wykonania czegoś:

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

Moje rozwiązanie:

1. wyłącz uprawnienia (rwx 000) dla: /etc/init.d/ {/ usr} / bin / /lib/libgcc.so
2. usuń wpis cronjob w / etc / crontab
3. usuń skrypt cron z /etc/cron.hourly/cron.sh
4. zrestartuj serwer

Uwaga: lokalizacje plików mogą się różnić

Dodatkowa sztuczka uzupełniająca rozwiązanie Serhii. Zatrzymanie wszystkich procesów może być trudne, ponieważ to spamer sieci i procesora. Dlatego dodaj ten wiersz do swojego, /etc/crontababy automatycznie ZATRZYMAĆ wszystkie nieprzyjemne procesy (zatrzymuje wszystkie procesy z 10 znakami w nazwie co trzy minuty):

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

Jest to dobra rzecz do zrobienia po czyszczeniu, aby upewnić się, że proces nie powróci. Uruchom go na chwilę, aż upewnisz się, że twoje pudełko jest czyste.