Любой компьютер, который имеет публичный IP-адрес постоянно подвергается атакам. Целые ботнеты пытаются подобрать имя пользователя и пароль.
Если у вас есть виртуальный VDS сервер, и вы подключитесь по ssh и введете команду «ss -nt | grep :22» вероятно, вы увидите, что кроме вас подключен кто-то еще.
Какое-то из этих подключений ваше. Но не все.
Означает ли, что вас уже взломали, и еще 5 пользователей орудуют на вашем сервере? Слава богу нет. Пока.
Потому как ботнеты подключаются по ssh, устанавливается соединение, после чего программа злоумышленника вводит очередной пароль из словаря. Затем ей приходит ответ, что пароль не верный, это повторяется еще пару раз, после чего сеанс завершается. Злоумышленник заново подключается и процесс повторяется.
Собственно об этом вам система скажет и при входе.
Целых 4970 неудачных попыток с последнего входа!
Вышли и вошли еще раз зашли
Уже 210 за несколько минут.
Но, раз есть попытки взлома, значит есть и успешные случаи. То есть если кто-то использует имя пользователя «admin» и пароль «q1w2e3r4» то скорее всего его машину уже взломали.
Зачем взламывают машины?
Ради денег.
Ведь на взломанной машине можно майнить криптовалюту. Может возникнуть вопрос, «Кому понадобится мой слабенький CPU?», ведь для майнинга нужны мощные фермы на видеокартах. Да, так-то оно так, на дешевых тарифах VDS минимальные ресурсы, и нет GPU, но во-первых есть криптовалюты, которые майнятся на обычных процессорах, во-вторых, слабая мощность процессора компенсируется их количеством.
Потому ботнет расширяет свою сеть, кроме майнинга пытается подобрать пароли к другим таким же машинам в сети, имеющим публичный IP-адрес.
Рассмотрим ситуацию из жизни
Итак, ваши друзья решили сделать стартап. Арендовали виртуальный VDS сервер у провайдера, настроили сервис, ждут первых клиентов.
И тут VDS блокируется провайдером, с указанием, что с вашего сервера велась подозрительная активность, поступила жалоба.
Просят вас помочь в расследовании данного инцидента и возобновлении работоспособности.
Вы говорите, чтобы ваши начинающие стартаперы попросили провайдера включить машину обратно. Им пошли на встречу, включили на полчаса.
Сами найти и полечить зловред не смогли, только зачем-то установили fail2ban (он уже не поможет, и не факт что тогда помог бы. Хотя шансы заражения снизил бы, но не до нуля).
Просят помочь, вы соглашаетесь.
Ищем зловреда
Вам дали логин и пароль от машины, вы зашли на нее, честно подключившись по ssh и введя пароль, после чего начинаете изучать что не так.
Смотрим список процессов командой ps ax
Как будто тоже глаза ни за что не цепляется.
Тут осеняет догадка: может посмотреть список сетевых сокетов?
ss -nt
Одно из подключений наше. Спрашиваем у наших друзей стартаперов, никто из них не подключен? Говорят никто.
Но тут мы понимаем, что остальное — это не входящие соединения, а исходящие. Три исходящих соединения на 22 порт.
Снова спрашиваем, а ваш сервер никуда не подключался?
Снова говорят что нет.
А еще зачем-то подключение на порт 7777.
Пробуем запустить ss, чтобы отображались процессы, которые открыли соединения. Для этого используем ключ «-ntp»
Снова спрашиваем —вы что резервную копию с помощью rsync делаете?
Говорят нет.
Мы вспоминаем, что rsync фигурировал в списке процессов (и не только он).
Убиваем rsync и xmrig с помощью kill
kill 3214 3409 3240 3275
Вроде все отлично
Но повторив команду, мы понимаем, что службы перезапустились
Вы пытаетесь найти службу в перечне юнитов, введя команду
systemctl list-units --type service
но глазами искомые программы не находятся.
Тогда пытаемся посмотреть список юнитов отфильтровав их по rsync и xmrig. Для того, чтобы удостовериться, что мы фильтруем правильно, мы также добавляем cron
rsync и xmrig отсутствуют, cron есть.
Раз вспомнили про cron, cмотрите crontab, например командой cat /etc/crontab
Тоже ничего не обычного.
И тут мы вспоминаем, что кроме /etc/crontab есть локальный кронтаб.
Для пользователя deploy лежит он в /var/spool/cron/crontabs/deploy
Этот файл мы можем отредактировать обычным пользователем, для чего используется утилита crontab
Запускаем crontab -e для редактирования локального кронтаба:
Видим, что там есть подозрительная строка
Каждую минуту запускается некий сервис sync, причем запускаемое приложение находится в папке пользователя.
Закомментируем с помощью значка комментария «#» строку, чтобы остановить повторный запуск зловредного ПО и сохраним кронтаб, нажав F2, yes и Enter
Видим, что crontab установлен
Cнова убьем процессы злоумышленника с помощью kill и известных нам их PID и проверим, что подозрительных соединений больше нет.
Через некоторое время проверяем. Подозрительные процессы не появились
Осталось разобраться, где находятся файлы злоумышленника. В crontab указан путь в скрытом каталоге. Переходим в него и смотрим, какие там есть файлы.
Смотрим что в config.json
Видим: а вот и майнерский кошелек
Смотрим, что за файлы xmrig и rsync
Это двоичные файлы. Очевидно что rsync занимался подбором паролей по ssh, а xmrig зарабатыванием денег для злоумышленника.
Проверяем что за файлы sync и sync.sh
Это скрипты
Смотрим sync.sh
Видим, что этот скрипт запускал майнер
И упомянутый в crontab sync тоже оказался скриптом
Не сложно догадаться, и по его запуску из crontab и по содержимому, что этот скрипт проверял, не был ли убит процесс майнинга и процесс перебора паролей и в случае, если не находил этих процессов среди запущенных, то запускал их заново!
Удаляем папку
И замечательно, мы починили машину!
Можно обрадовать друзей, что все, можно использовать машину.
Или нет?
А что это у нас тут в .ssh в домашнем каталоге пользователя?
А ключ злоумышленника (мы-то знаем, что наши друзья использовали только пароли).
И это означает, что через некоторое время скрипт злоумышленника подключится на нашу машину, увидит, что нужное ему ПО удалено, и поставит заново.
Поэтому сносим ключ тоже. В данном случае можно целиком удалить папку .ssh
Далее еще раз проверить сетевые сокеты с помощью ss -ntp и локальный crontab с помощью crontab -e. И если все хорошо, теперь можно радовать друзей.
Радуем друзей
Напишем друзьям в мессенджере и сообщим, что если на машине остались каике-то несохраненные данные, то пора их сохранить и переустановить машину. (Можно и просто удалить пользователя, вдруг мы что-то не усмотрели и что-то осталось. Но лучше переустановить).
И рекомендуем больше никогда не использовать пользователей со словарными именами и паролями. А лучше вообще запретить доступ к ssh по паролям!
Как вы видите, не обязательно иметь доступ к root, чтобы заразить машину.
Еще выводы
Какие еще выводы надо сделать?
Не использовать пароли для удаленного доступа, настроить в ssh авторизацию по ключам, а еще лучше, чтобы ssh вообще не был доступен в публичной сети, только в приватной, которая доступна из офиса и/или через впн.
Или пользоваться только VNC провайдера, он не доступен через публичную сеть.
И не забывать про бэкапы и резервное копирование. Тогда возможно не пришлось бы возиться с машиной (хотя это и было интересно), а удалить ее и создать заново.
Дисклеймер
Разобранный пример основан на случае из практики. Меня действительно попросили полечить машину. Но этот пример разобран на написанном мной имитаторе злоумышленника, все возможные совпадения ключей, хешей и IP-адресов случайные.
Не каждый rsync зловред. Действительно есть такая программа для синхронизации. Вместо rsync зловред может маскироваться под другую программу, такую как ssh, mdadm, и т.д.
Не обязательно xmrig может быть установлен злоумышленником. Может майнингом специально ваши друзья пытались заниматься, а их уже позже взломали.
Архитектура зловреда, названия файлов, имена программ, под которые они маскируются могут отличаться. Описан только один из многих вариантов.
Подписывайтесь на мой канал в дзен и будете в курсе новых моих статей по компьютерным сетям и ОС/Linux.
Всегда с вами,
Сергей Кручинин
преподаватель GNU/Linux и компьютерных сетей