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


14

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ę!


Jeśli Twój serwer został przejęty, bardzo trudno będzie stwierdzić, w jaki sposób został zainfekowany i co zostało zrobione, ponieważ intruz może troszczyć się o lekarza / usunąć pliki dziennika. Najlepszą praktyką jest przechowywanie plików dziennika poza siedzibą w innym miejscu, więc jeśli komputer zostanie naruszony, będziesz mieć przynajmniej dzienniki prowadzące do włamania. Ostatecznie myślę, że będziesz musiał ponownie zainstalować - jedyny sposób, aby zapewnić czysty niezainfekowany system.

Odpowiedzi:


24

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.

1
na /etc/rc6.d/ jest kilka złych skryptów, zaczynają się od K90
mazgalici,

1
zrób, find / -name "*rguoywvrf*"aby znaleźć inne pliki, zastępując rguoywvrfje nazwą pliku
Mohamed Hafez,


3

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.


1

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

  1. 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

  2. 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.


Twoja odpowiedź może być trudna do odczytania, ponieważ wydaje się, że nie jest poprawnie sformatowana. Jeśli potrzebujesz pomocy, centrum pomocy zawiera więcej informacji na temat prawidłowego formatowania postów.
bwDraco

0

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ć


0

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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.