Ранее мы уже публиковали статьи о поисках вирусов на VDS с Linux. Также до сих пор многие полагают, что вирусов в Linux нет, считая это одним из преимуществ данного семейства операционных систем. И в чём-то эти люди правы. Ведь вредоносных программ, которые самовольно распространялись бы по Linux-системам и заражали другие серверы и компьютеры по сети, во много раз меньше, чем на Windows, а опубликованная ранее статья относилась к вирусам на сайте и веб-уязвимостям, нежели к самой операционной системе.
Но есть и другой тип угроз, к сожалению, характерный для Linux. Это руткиты — программы или скрипты, которые устанавливаются вручную (либо попадают в систему через уязвимости) и скрывают свою деятельность в системе.
Эти программы могут предоставлять установившему их человеку полный доступ к вашей системе, ресурсам и данным. Для этого даже не обязательно знать IP-адрес вашего сервера. Злоумышленник может просто перебирать адреса по подсетям через специальных ботов, и если на вашем сервере окажется искомая им уязвимость, например, слабый пароль ssh или любая другая «дыра» в системных или веб-службах, сайте или ошибка в настройке — ваш сервер может быть взломан.
Ранее мы уже рассказывали о том, как защититься от взлома, а сегодня поговорим о том, какими способами можно выявить сам факт взлома.
Проверка логов на несанкционированные авторизации
Чтобы понять, не подключался ли кто к вашему серверу, вы можете просмотреть содержимое файла /var/log/audit.log или /var/log/secure.
tail -f /var/log/secure
Здесь фиксируются все события в системе, в том числе неудачные попытки входа по ssh. Можете не удивляться, если увидите там записи о попытках подключения — так сканирующие боты перебирают пароли к серверам. Также можно посмотреть логи сервиса sshd с помощью journalctl:
journalctl -u ssh
В примере на скриншоте отмечены две последние попытки подключения по ssh. Как можно заметить авторизация была неудачной, а производилась она с незнакомых IP. Пугаться стоит, если вы в этом логе обнаружите запись об удачной авторизации, но IP вам будет всё так же незнаком.
Также небольшую выдержку об авторизациях можно получить с помощью команды:
last
Пример вывода команды:
root pts/0 181.23.456.189 Sat Mar 23 12:27 still logged in user1 pts/11 181.45.678.912 Wed Mar 20 05:30 - 05:49 (00:19) user2 pts/22 181.45.678.312 Fri Mar 15 00:01 - 02:27 (02:26) ftpuser ftpd25 181.45.678.411 Wed Mar 13 11:02 - 11:28 (00:26) ...
Как вы можете видеть, выводится таблица с информацией. В ней содержатся имена пользователей, IP-адрес, с которого осуществлялся вход, дата и время входа и продолжительность сессии. Запись вида pts/0 означает, что для входа использовалось SSH соединение (или другое удаленное соединение, например, telnet).
Если злоумышленник уже получил доступ к вашей системе, вариантов развития ситуации может быть много. Например, могут быть использованы внутренние уязвимости в системных библиотеках и ядре для обхода защитных механизмов Linux и повышения привилегий в системе.
Поэтому не лишним будет следить за актуальностью своего программного обеспечения: в новом ПО скорее всего, уже закрыли известные уязвимости, об этом мы уже говорили здесь и здесь, но также можно иногда проверять сервер специальной программой для поиска руткитов. Дальше мы рассмотрим, как провести такой поиск.
Для поиска руткитов мы будем использовать утилиту RkHunter, или RootkitHunter. Мы рассмотрим, как её установить и настроить для правильной проверки. Но помните, этот метод хорош только для первичной проверки системы на безопасность. И не может выступать как универсальный инструмент для анализа вредоносной активности на уровне системы.
Поиск руткитов с помощью RkHunter
RkHunter (Rootkit Hunter) — это достаточно популярный и удобный инструмент для сканирования системы Linux / Unix с открытым исходным кодом, выпущенный под лицензией GPL. Утилита выполняет сканирование Linux на предмет руткитов, бэкдоров, эксплойтов и уязвимостей. На данный момент в базе около 350 руткитов, и все их можно найти, если они были использованы в вашей системе.
RkHunter представляет собой скрипт, который позволяет проверить локальные файлы и обнаружить известные руткиты. Кроме того, он анализирует изменения системных команд, файлов запуска и проверяет сетевые интерфейсы на предмет прослушивания определенных портов.
Установка и начальная настройка RkHunter
Установить программу в Debian/Ubuntu можно командой:
apt install rkhunter
В CentOS надо выполнить такую команду:
yum install rkhunter
Если у вас другой дистрибутив или в репозиториях системы пакет не был найден, вы всегда можете скачать установочный скрипт на SourceForge:
cd /tmp wget https://sourceforge.net/projects/rkhunter/files/rkhunter/1.4.6/rkhunter-1.4.6.tar.gz tar -xvf rkhunter-1.4.6.tar.gz cd rkhunter-1.4.6 ./installer.sh --layout default --install cp -p /usr/local/bin/rkhunter /usr/bin/rkhunter
Для установки последней версии скрипта рекомендуем использовать именно этот способ.
Перед тем, как запускать проверку, необходимо обновить базу данных утилиты. Для этого выполните:
rkhunter --update
Обновление желательно выполнять регулярно, поэтому мы предлагаем вам создать специальный скрипт и добавить его в cron на регулярный запуск, раз в неделю или даже каждый день Создайте файл скрипта:
- для ежедневной проверки в директории /etc/cron.daily:
nano /etc/cron.daily/rkhunter.sh
- для еженедельной /etc/cron.weekly:
nano /etc/cron.weekly/rkhunter.sh
Созданный файл тут же откроется, туда мы впишем следующее содержимое:
#!/bin/sh ( /usr/local/bin/rkhunter --versioncheck /usr/local/bin/rkhunter --update /usr/local/bin/rkhunter --cronjob --report-warnings-only ) | /usr/bin/mail -s 'rkhunter Daily Run (Ваш сервер)' your@email.com
Здесь мы выполняем проверку версии скрипта, обновление баз руткитов, и в последней строчке мы запланировали проверку и отправку уведомления на еmail. Для работы необходимо заменить your@email.com на адрес вашей электронной почты.
Теперь осталось только дать скрипту права на выполнение:
chmod 755 /etc/cron.daily/rkhunter.sh
Далее необходимо собрать информацию о файлах в системе. Это нужно, чтобы при следующей проверке можно было выявить, пытался ли кто-то модифицировать системные файлы за время между проверками. Для этого выполните:
rkhunter --propupd
Теперь давайте рассмотрим основные опции программы (ключи запуска), которые мы уже использовали, или те, что могут вам пригодиться:
--verbose-logging — максимально подробный вывод
--quiet — минимум информации в выводе
-l, --logfile — записать лог программы в свой файл
--cronjob — неинтерактивный режим проверки, используется для запуска с помощью cron, отсюда и название.
--list — позволяет посмотреть, какие возможности поддерживает программа, можно передать несколько параметров: test — тесты, lang — языки, rootkits — руткиты.
--unlock — удаляет файл блокировки базы данных, может быть полезна, если предыдущий сеанс работы с программой был завершен некорректно.
--check — проверка операционной системы
--update — обновление баз руткитов
--versioncheck — обновление программы
--propupd — создать запись о файловой системе
Например, чтобы посмотреть все руткиты, которые может найти программа, выполните:
rkhunter --list rootkits
Перед проверкой необходимо сделать кое-что важное. По умолчанию некоторые тесты в RkHunter отключены с ориентиром на десктопные машины. Но так как мы проверяем сервер, то для полного анализа нам нужны результаты всех тестов.
Вернуть все тесты в проверку можно следующим образом. Откроем конфигурационный файл RkHunter:
nano /etc/rkhunter.conf
Находим строку, начинающуюся с DISABLE_TESTS
Если в начале строки стоит знак #, то все в порядке, если нет, то добавьте этот знак и сохраните изменения. Теперь в будущие проверки будут входить все варианты тестов.
Запуск проверки и просмотр результатов
Для того чтобы проверять всю операционную систему, запуск следует выполнять под пользователем root . Используйте команду:
rkhunter --check
В процессе проверки информация о её ходе выводится на экран. Одновременно с этим создается лог проверки — именно в нём хранится вся необходимая информация для последующего удобного анализа. Просмотреть его можно командой:
cat /var/log/rkhunter.log
Как и большинство логов в Linux, этот лог на английском, поэтому, чтобы понять в каком состоянии ваша система, вам нужны некоторые знания языка или помощь онлайн-переводчиков.
Чтобы было понятнее, что находит программа и как анализировать её результаты, давайте рассмотрим это на примере.
Пример сканирования и анализа лога
Сначала программа инициализируется и загружает конфигурационные файлы, здесь нет ничего интересного. Заметьте, что мы рассматриваем лог проверки системы, а логи обновления и создания базы данных (они находятся выше в этом же файле) нас не интересуют. Проверка системы начинается с этих строк:
RkHunter сканирует системные утилиты и пытается выявить там подозрительные признаки, в том числе проводится сравнение хеша утилиты с хешем, сохраненным в базе данных, чтобы понять, не была ли она изменена. Обычно, если с утилитами все хорошо, лог заполнен такими строками:
Также выполняется проверка параметров файлов, например, как довольно частый случай, если файл должен быть бинарным, а он является скриптом, то это явный признак того, что что-то не так.
При обнаружении подозрительного файла программа тут же дает расшифровку своей версии выявленной проблемы. Возможно, что это ложное срабатывание, однако стоит проверить эти файлы или переустановить пакеты, которым они принадлежат.
Далее ведётся проверка на известные руткиты:
Обычно, если в этом разделе что-то обнаружено, это значит, что в системе есть руткит. В ином случае мы видим строки Not found (не найдено).
После ведётся поиск нежелательного программного обеспечения:
А также проверка опасных портов:
На этапе проверки конфигурационных файлов можем получить такое предупреждение:
Warning: Unable to check for passwd file differences: no copy of passwd file exists.
В данном случае проблема не в вирусе, а в том, что программе просто не с чем сравнить.
Затем идёт проверка настроек системы, и здесь также программе может не все понравиться:
А именно две вещи — разрешенный root доступ по ssh и возможность использовать протокол первой версии для подключения к ssh. В этом действительно есть доля опасения, так как в случае взлома, доступ к серверу будет полный. Как это исправить, можете почитать вот здесь.
Далее будет выполнено сканирование файловой системы:
Вполне вероятно, что будет обнаружено несколько скрытых файлов: само их наличие в системе — это нормально. Однако вам все-таки необходимо посмотреть в логе, какие из них кажутся подозрительными, незнакомыми, либо вы можете отследить, какая программа работает с опредёленным файлом с помощью команды lsof:
lsof | grep /адрес/до/файла
И в завершении пройдёт проверка приложений:
[12:16:25] Info: Starting test name 'apps' [12:16:25] Checking application versions..
А также небольшой отчёт о найденных проблемах:
Возможно, вам покажется сложным подробное изучение всего лога программы — он достаточно большой. Поэтому для удобства вы можете не смотреть его полностью, а выбрать только предупреждения:
cat /var/log/rkhunter.log | grep -A5 "\[ Warning \]"
Параметр A5 означает: показывать ещё пять строк после строки с обнаруженным вхождением. Так вы сможете прочитать не только все предупреждения, но, возможно, и важную сопроводительную информацию. В любом случае так выше шанс ничего не упустить.
Выводы и что делать в случае обнаруженных руткитов
Главная сложность в поиске руткитов — избавление от найденных зловредов. Это всегда достаточно индивидуально, поэтому описать все случаи в статье, к сожалению, не получится. Но если говорить в общем, то необходимо сделать следующее:
- удалить сторонние файлы, убить вредоносные процессы, поправить права доступа,
- переустановить ПО заново на версии, которые являются актуальными,
- проверить, что в системе подозрительной активности больше нет.
Если после этих действий и повторной проверки проблема не решилась, то, остается самый надёжный способ — сделать бэкап только ваших данных и перенести их на новую чистую систему.
Главное, что хотелось бы отметить в конце: метод, который мы описали в статье, не является панацеей. Но с его помощью вы можете обнаружить ряд потенциальных проблем с безопасностью.
Вероятность взлома, тем не менее, останется всегда. Поэтому лучшим решением в данном вопросе всегда является профилактика — проводите сканирование всей системы регулярно, вовремя обновляйте ПО, меняйте пароли и не избегайте мер дополнительной профилактики и защиты.
