null

Как поймать майнер на linux VDS

Думаю ни для кого не секрет, что вирусы существуют не только для windows систем, но и для linux.
Недавно мы столкнулись лицом к лицу с одним из них и именно об этом далее пойдет речь.

Как определить, что нашей машиной пользуемся не только мы сами, но и кто-то еще?
Первое что приходит в голову -- письмо от поставщика VDS, примерно следующего содержания:
 

An attempt to brute-force account passwords over SSH/FTP by a machine in your domain or in your network has been detected. 
Please take the necessary action(s) to stop this activity immediately.
...

Получается кто-то с нашей машины пытается подобрать пароль к другим хостам с SSH.
Разумеется, это делаем не мы, поэтому давайте разбираться.

При логине в системе, сразу бросилась в глаза плохая отзывчивость SSH сессии.
А запущенный `top`, показал 100% загрузку CPU процессом `xmrig`.
`xmrig` -- майнер с открытым исходным кодом, подробнее можно прочитать здесь.

Убить его просто так (послать SIGKILL процессу) не получается, что-то постоянно перезапускает процесс.
Зато `top` нам подсказал, от чьего имени запущен процесс. Поиск по `auth.log` подтвердил наши опасения -- к нам пробрались.
По факту, нашим хостом был LXD контейнер созданный для тестовых целей, поэтому там существовал пользователь со слабым паролем создаваемый по умолчанию при поднятии контейнера.

В `crontab` нашего пользователя были найдены следующие строки:

* */12 * * * /home/user/.ttp/a/upd>/dev/null 2>&1
@reboot /home/user/.ttp/a/upd>/dev/null 2>&1
5 8 * * 0 /home/user/.ttp/b/sync>/dev/null 2>&1
@reboot /home/user/.ttp/b/sync>/dev/null 2>&1
#5 1 * * * /tmp/.mountfs/.rsync/c/aptitude>/dev/null 2>&1

Один из способов решения проблемы(как мы это сделали):
Первым делом запрещаем исходящие соединения на 22 порту, чтобы не принести вреда другим:

ufw deny out 22

Не забываем почистить `crontab` от лишних записей.

Убиваем все процессы нашего пользователя:

pkill -KILL -u user

Удаляем пользователя и все его файлы:

deluser --remove-all-files user

На данном этапе проблема должна быть решена, можем убедиться в этом посмотрев на исходящие соединения на порт 22:

netstat -peanut | grep 22

​​
А так же посмотрим на вывод `top` и убедимся, что не запущено лишних процессов.

Но это еще не все. Нужно принять меры, чтобы этого больше не повторилось.
Тут не помешает щепотка паранойи.

Отключаем доступ к нашему хосту по SSH по паролю. В файле `/etc/ssh/sshd_config` должна присутствовать строка:

PasswordAuthentication no

В идеале, стоит создать белый лист ip-адресов с которых можно будет подключаться к хосту.
Разрешить подключения только с конкретного ip можно так, пример с `ufw`:

# ufw status numbered
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 443/tcp                    ALLOW IN    Anywhere                  
[ 2] 22/tcp                     ALLOW IN    Anywhere
...

# ufw delete 2
# ufw allow from IP_ADDRESS to any port 22/tcp


Таким образом мы удалили правило разрешающее каждому ходить в наш sshd, а потом разрешили подключения с нашего IP_ADDRESS.

Если Вы не хотите так себя ограничивать, то стоит посмотреть в сторону `fail2ban`.
Он будет сам банить ip-адреса с которых было много безуспешных попыток логина на наш хост.
И, конечно, пришлет нам об этом письмо, чтобы мы сами могли решить, как поступить.

Напоследок хотелось бы напомнить, в первую очередь себе, что о безопасности следует думать всегда, а не когда случилась беда.
Используйте сложные пароли и не доверяйте дефолтным конфигурациям слепо.

Назад Вперед

Коротко о себе:

Работаю программистом в компании Tune-it.

Занимаюсь какими-то проектами, связанными с чем-то.