Системы семейства Linux трудно атаковать, но и защищать их сложно. В инфраструктурах на их базе нет единого центра управления, проводить аудит надо для каждого хоста отдельно. Логика работы ОС требует иногда искать следы атак в неочевидных местах. Что учесть, что требует особого внимания от эксперта?
- 1. Введение
- 2. Как устроен процесс по поиску следов атаки
- 3. Проблема: отсутствие единого центра управления
- 4. Что изучать и на что обращать внимание
- 5. Специфика закрепления в Linux-системах
- 6. SSH-ключи и скрытые учётные записи как инструмент долгосрочного доступа
- 7. Выводы
Введение
Compromise Assessment — это ретроспективная проверка инфраструктуры на признаки компрометации, которая могла произойти в прошлом и остаться незамеченной. Исследователи ищут следы состоявшихся ранее атак и действуют как цифровые криминалисты.
При этом принципы реализации проекта по поиску следов компрометации в разных инфраструктурах неодинаковы. Linux-инфраструктура особенно выделяется своей сложностью как для атакующих, так и для ИБ-специалистов, защищающих её. В этой статье мы рассмотрим, на что стоит обратить внимание при проведении Compromise Assessment.
Как устроен процесс по поиску следов атаки
Поиск следов компрометации состоит из нескольких этапов. Сначала специалисты собирают контекст: какие системы входят в периметр проверки, какие роли они выполняют, какие сетевые взаимодействия для них типичны. Без этого возникает риск воспринять нормальное для конкретной системы поведение как аномалию и наоборот.
Следующий шаг — сбор артефактов с каждой системы на момент проверки: список процессов и сетевых соединений, история команд, содержимое критически значимых конфигурационных файлов, список запланированных задач, перечень установленных пакетов и их контрольных сумм, журналы аутентификации. Этот процесс требует детальной проработки, так как пропущенный артефакт может означать упущенный след атаки.
Далее специалисты проводят анализ лог-файлов, процессов, служб и сетевого трафика, кросс-анализ и проактивный поиск угроз (Threat Hunting), т. е. сопоставление собранных данных с глобальными базами киберразведки и индикаторами компрометации.
Финальный этап — валидация полученных данных. Важно понимать, что не каждая аномалия становится признаком компрометации. Задача аналитика — отличить реальный инцидент от шума, и здесь крайне важны уровень знаний и компетенций эксперта. Compromise Assessment — сложная процедура, которая требует особого подхода.
Проблема: отсутствие единого центра управления
Принципиальное отличие Linux от Windows, которое определяет всю методологию дальнейшей работы с инфраструктурой, — отсутствие единого центра управления системой. В Active Directory есть возможность настроить централизованный сбор логов, используя механизм Microsoft WEF / WEC (Windows Event Forwarding / Windows Event Collector). В Linux-инфраструктуре, если не развёрнуты специальные решения централизованного управления, такого нет.
Каждая система в Linux-инфраструктуре является изолированной, со своей локальной конфигурацией, своими учётными записями и журналами. Практическое следствие: аудит нельзя провести «по домену». Его нужно проводить по каждой системе отдельно, и в крупной инфраструктуре с сотнями серверов это кардинально меняет экономику проверки.
Процесс аудита можно ускорить с помощью инструментов автоматизации, например Ansible-плейбуков. Но даже с ними анализ всё равно требует понимания специфики каждой роли сервера: веб-сервер, база данных, сервер сборки и джамп-хост могут быть скомпрометированы с использованием разных инструментов, которые оставляют разные следы.
Что изучать и на что обращать внимание
Первое, с чего стоит начинать на каждой системе, — список процессов и сетевых соединений. Команды «ps», «netstat», «ss» и «lsof» дадут снимок текущего состояния. Подозрительные процессы с нетипичными именами, маскирующиеся под системные (например, процесс с именем «[kworker/0:1]» без квадратных скобок — классическая техника маскировки), процессы, запущенные из нетипичных директорий вроде «/tmp» или «/dev/shm», и сетевые соединения к незнакомым внешним адресам, особенно на нестандартных портах, — явные признаки прошедшей компрометации.
Второе — это история команд в оболочке. Файлы «.bash_history», «.zsh_history» содержат историю выполненных команд, но важно помнить: опытный атакующий либо чистит историю, либо работает в оболочке с отключенным логированием, либо модифицирует переменную HISTFILE. Отсутствие истории там, где она ожидается, — само по себе индикатор. Стоит также проверять временные метки файлов истории на предмет несоответствия остальной активности в системе.
Третье — это содержимое критически значимых конфигурационных файлов «/etc/passwd» и «/etc/shadow», их проверка на предмет новых или неожиданных учётных записей, особенно с UID 0 у аккаунтов, которые не должны иметь привилегий суперпользователя (root). Следует также проверять файл «/etc/sudoers» и директорию «/etc/sudoers.d» на предмет избыточных или неожиданных прав, изучать файлы PAM-конфигурации в «/etc/pam.d/», которые иногда модифицируют для встраивания бэкдоров прямо в механизм аутентификации.
Четвёртое — это список запланированных задач: «crontab» для каждого пользователя, системные директории «/etc/cron.d/», «/etc/cron.daily/» и аналогичные, а также systemd-таймеры. Это один из наиболее часто встречающихся механизмов закрепления, который заслуживает отдельного внимания.
Пятое — это список установленных пакетов и сопоставление их контрольных сумм с эталонными значениями из репозиториев. Команды вроде «rpm -Va» для систем на базе RPM или «debsums» для Debian-дистрибутивов позволяют быстро выявить модифицированные системные файлы.
Шестое — это журналы аутентификации: «/var/log/auth.log» или «/var/log/secure», в зависимости от дистрибутива. Здесь аудиторы ищут неудачные попытки входа, успешные входы в нетипичное время и с нетипичных IP-адресов, использование учётных записей, которые давно должны были быть деактивированы.
Специфика закрепления в Linux-системах
Злоумышленники используют специальный набор техник для закрепления в Linux-инфраструктуре, и часть из них сложно обнаружить стандартными средствами.
Инициализаторы и скрипты автозапуска — самые удобные для атакующих механизмы закрепления. Создание нового юнита в «/etc/systemd/system/» или модификация существующего позволяет гарантировать запуск вредоносного кода при каждой загрузке системы, причём маскировка под легитимное имя службы, например похожее на системный сервис, делает такой юнит незаметным при просмотре списка. Init-скрипты в «/etc/init.d/» работают по той же логике.
Отдельное внимание стоит уделить файлам профиля оболочки: «/etc/profile», «/etc/bash.bashrc», а также пользовательским «.bashrc» и «.profile». Код, добавленный в эти файлы, выполняется при каждом входе пользователя в систему или открытии новой сессии оболочки.
Модификация легитимных библиотек и перехват системных вызовов — более изощрённые техники, чем простое добавление файла в автозагрузку, и именно они чаще всего остаются незамеченными при поверхностном аудите. Механизм LD_PRELOAD позволяет загрузить в память произвольную разделяемую библиотеку прежде стандартных системных библиотек, и если в ней переопределены функции работы с директориями (вроде «readdir») или сетевыми сокетами, то для атакующих становится возможным скрывать процессы, файлы или сетевые соединения от стандартных утилит мониторинга. Проверка переменной LD_PRELOAD в «/etc/ld.so.preload» и в окружении подозрительных процессов — обязательный пункт аудита, который часто пропускают.
Более глубокий уровень — руткиты уровня ядра, модифицирующие таблицу системных вызовов или использующие легитимные механизмы загрузки модулей ядра для встраивания вредоносной функциональности непосредственно в ядро операционной системы. Обнаружить такую компрометацию штатными средствами самой системы практически невозможно, так как скомпрометированное ядро может выдавать недостоверную информацию о собственном состоянии любому инструменту, который запрашивает это состояние через системные вызовы.
Решением здесь является только сравнение с заведомо доверенным образом (проверка хешей загружаемых модулей), анализ памяти с внешнего носителя или, что более реалистично в большинстве случаев, детектирование по косвенным признакам: нетипичная задержка в выполнении системных вызовов, расхождение между данными из разных источников получения одной и той же информации.
Закладки в системных и прикладных бинарных файлах в виде подмены легитимных утилит на модифицированные версии, скрывающие определённые файлы или процессы, остаются рабочей и относительно простой техникой. Сверка контрольных сумм системных утилит с эталонными значениями — простой и эффективный способ их обнаружить.
SSH-ключи и скрытые учётные записи как инструмент долгосрочного доступа
Особое внимание следует уделить технике, которую атакующие используют практически в любой Linux-инфраструктуре, в которую получили устойчивый доступ: создание дополнительных способов вернуться.
Самый распространённый вариант — добавление собственного публичного ключа в файл «~/.ssh/authorized_keys» существующего пользователя, особенно сервисных учётных записей или заброшенных аккаунтов, за активностью которых никто не следит. Это даёт атакующему возможность в любой момент подключиться по SSH, не вводя пароль и не оставляя следов неудачных попыток аутентификации. При аудите «authorized_keys» стоит проверять на каждой системе и для каждого пользователя, сопоставляя найденные ключи с реестром авторизованных администраторов, где любой незнакомый ключ требует расследования.
Второй вариант — создание новой учётной записи, замаскированной под сервисную или системную, с присвоением ей прав, достаточных для последующих действий. Злоумышленники нередко выбирают имена, похожие на легитимные системные аккаунты, с минимальными отличиями, которые легко пропустить при беглом просмотре «/etc/passwd».
Третьим, менее очевидным, вариантом считается модификация конфигурации «sshd_config» для открытия дополнительных портов прослушивания, разрешения входа по паролю там, где политика безопасности это запрещает, или добавления обходного механизма аутентификации через систему привилегированного доступа PAM.
Если в системе обнаружен хотя бы один из признаков компрометации, проверка SSH-доступа становится обязательной на всех связанных системах. Горизонтальное перемещение в Linux-инфраструктуре часто строится именно на цепочке SSH-ключей между серверами.
Выводы
Процедура Compromise Assessment в Linux-инфраструктуре сложна из-за особенностей самой ОС, множества изолированных систем и отсутствия единого центра управления. Проверка здесь проводится дольше (по сравнению, например, с Windows-инфраструктурой) и требует от исследователя более высокого уровня компетенций.
При этом ключевым аспектом успеха такой проверки становится именно внимание специалистов к деталям: обнаружение следов компрометации здесь зачастую требует выхода за пределы стандартных чек-листов.
