В поисках лучшего аудита событий Linux: auditd против решений на базе eBPF
Аудит событий Linux остаётся одной из базовых задач информационной безопасности. Администратору и специалисту SOC важно понимать, какие процессы запускаются на сервере, с какими узлами устанавливаются соединения, кто изменяет файлы и каким образом пользователь получил доступ к системе. От качества этой телеметрии зависят расследование инцидентов, поиск следов компрометации и построение детектирующих правил.
На практике для таких задач применяются как классический auditd, так и современные инструменты на базе eBPF: Tetragon, Kunai, Falco и Sysmon for Linux. У каждого подхода есть собственная область применения, уровень нагрузки и особенности представления данных. Универсального победителя нет: выбор зависит от того, требуется ли глубокий хостовый аудит, наблюдение за контейнерами, оперативный триаж или интеграция с SIEM и EDR.
Какие события необходимо контролировать
Минимальный набор телеметрии для Linux-систем обычно включает несколько категорий.
Запуск и завершение процессов. Командная строка, пользователь, родительский процесс и путь к исполняемому файлу часто позволяют быстро понять, что происходило на машине. Запуск shell из веб-сервера, выполнение подозрительного интерпретатора или появление процесса из временного каталога могут быть важными признаками атаки.
Сетевые соединения. Информация о подключениях нужна для поиска каналов управления, несанкционированной передачи данных, загрузки полезной нагрузки и обращения к подозрительным внешним адресам. Особенно ценны сведения о процессе-инициаторе, направлении соединения и порте назначения.
Создание и удаление файлов. Такие события помогают отслеживать появление скриптов, временных файлов, новых конфигураций и попытки удалить артефакты атаки. Для серверов критично наблюдать за системными каталогами, директориями приложений и местами хранения секретов.
Изменение файлов и атрибутов. В Linux большое количество объектов представлено файлами, поэтому изменение конфигурации, прав доступа, владельца или временных меток может быть значимым событием. При этом сам факт изменения не всегда показывает, какие именно строки были переписаны: для содержательного контроля потребуется дополнительное сравнение или контроль целостности.
Аутентификация и завершение сеанса. Эти данные позволяют связать операцию с конкретной учётной записью, способом входа и источником подключения. Без такой привязки расследование часто сводится к анализу обезличенных процессов и файлов.
Манипуляции с процессами и библиотеками. Клонирование процессов, внедрение кода, загрузка нестандартных библиотек и изменение адресного пространства относятся к более сложным сценариям. Они особенно важны при анализе постэксплуатационной активности.
События контейнеров. В контейнерной среде нужно видеть не только действие на хосте, но и контекст: имя контейнера, образ, namespace, pod, рабочую директорию и пользователя внутри изолированной среды.
Сравниваемые инструменты
auditd
auditd - традиционный механизм аудита Linux, тесно связанный с ядром и системными вызовами. Он хорошо подходит для контроля хостовых операций, а его правила позволяют отслеживать запуск программ, доступ к файлам, изменения идентификаторов, работу с правами и другие действия.
Главный недостаток - сложность сопровождения. Для приемлемого покрытия требуется набор из большого количества правил. Чем шире конфигурация, тем выше риск получить избыточный поток событий, дублирование и дополнительную нагрузку. Отдельные трудности возникают в контейнерах: контекст процесса приходится восстанавливать по косвенным признакам, а результат не всегда удобно интерпретировать.
При этом auditd остаётся сильным вариантом для классического хостового аудита. Он нативен, распространён, поддерживается большинством дистрибутивов и хорошо интегрируется с существующими системами сбора журналов.
Tetragon
Tetragon использует eBPF и ориентирован прежде всего на трассировку процессов и событий ядра. Инструмент способен предоставлять подробные сведения о жизненном цикле процессов, сетевых действиях, доступе к ресурсам и работе контейнеров.
Его сильная сторона - глубокий контекст и возможность отслеживать события в современных оркестрационных средах. Однако для применения в информационной безопасности требуется хорошее понимание Linux kernel, namespaces, capabilities и механики eBPF. Без собственной логики детектирования Tetragon скорее становится мощным источником данных, чем готовым средством обнаружения атак.
Kunai
Kunai делает акцент на сборе объёмной телеметрии и последующем анализе. Он способен дать широкую картину происходящего на узле, что полезно при активном триаже и расследовании неизвестной активности.
Ограничением становится зрелость экосистемы и удобство регулярной эксплуатации. Для постоянного использования в крупной инфраструктуре важно заранее проверить стабильность, формат событий, поддержку нужных дистрибутивов и возможности интеграции с внутренними процессами SOC.
Falco
Falco хорошо известен благодаря ориентации на обнаружение подозрительного поведения, особенно в Kubernetes и Docker. Он способен реагировать на запуск shell в контейнере, доступ к чувствительным файлам, неожиданные сетевые действия и другие опасные сценарии.
Цена широкого покрытия - заметное потребление ресурсов. При высокой нагрузке и большом количестве контейнеров необходимо аккуратно настраивать правила, исключения и маршрутизацию событий. Тем не менее для контейнерной безопасности Falco часто оказывается наиболее практичным из рассматриваемых вариантов.
Sysmon for Linux
Sysmon for Linux предлагает более простой и структурированный подход. Его удобно использовать, когда нужно быстро получать сведения о запуске процессов, сетевых соединениях и некоторых базовых действиях.
Инструмент подходит для стандартизации формата событий и последующей передачи данных в SIEM. Однако сложные атаки, глубокие операции с ядром, контейнерный контекст и продвинутые техники внедрения он покрывает ограниченно. Это хороший стартовый вариант, но не полноценная замена EDR.
Как проводить сравнение
Корректное тестирование должно выполняться в одинаковых условиях: на сопоставимых виртуальных машинах, с одинаковой нагрузкой, версиями ядра и набором сценариев. Важно измерять не только факт появления события, но и несколько параметров:
- загрузку CPU;
- потребление оперативной памяти;
- объём создаваемых журналов;
- задержку появления события;
- полноту контекста;
- долю ложных срабатываний;
- удобство фильтрации и дальнейшего анализа.
Сценарий запуска процессов
Проверяются обычный запуск программ, выполнение команд через shell, запуск дочерних процессов, использование интерпретаторов и запуск бинарных файлов из нестандартных каталогов. Здесь auditd обычно предоставляет устойчивое покрытие, особенно при правильно составленных правилах.
eBPF-инструменты чаще дают более удобное представление о цепочке процессов: видны родитель, контейнерный контекст, namespace и дополнительные атрибуты. Для расследования это полезнее, чем отдельная запись о системном вызове, однако объём событий может оказаться значительно выше.
Сценарий сетевого взаимодействия
Важны не только факт подключения, но и процесс, который его инициировал. Простая сетевой статистика без связи с исполняемым файлом плохо помогает при расследовании.
Sysmon for Linux удобен для базового контроля соединений. Falco и Tetragon могут добавлять контекст контейнера и процесса. auditd способен фиксировать сетевые операции, но итоговая аналитика часто требует сложной корреляции нескольких записей.
Сценарий работы с файлами
При создании, удалении и открытии файлов auditd обеспечивает широкие возможности, но неправильная настройка быстро приводит к лавине событий. Для eBPF-решений важным преимуществом становится возможность фильтровать действия по процессу, namespace, пользователю или конкретному пути.
Отдельно следует учитывать, что наблюдение за фактом записи не равно контролю содержимого. Если необходимо знать, какие данные изменились, аудит нужно дополнять контролем целостности, хешированием или анализом версий конфигурации.
Сценарий изменения прав и атрибутов
Изменение владельца, разрешений, extended attributes и временных меток может быть частью легитимной работы администратора или этапом сокрытия следов. Поэтому такие события необходимо рассматривать вместе с пользователем, процессом, источником команды и временем.
Наиболее полезной становится не максимальная детализация, а способность быстро отделить штатные операции от необычных. Для этого нужны исключения, списки доверенных процессов и корреляция с изменениями конфигурации.
Сценарий входа пользователя
Аудит входов обычно строится на системных журналах, PAM и событиях управления сессиями. Здесь важны тип аутентификации, успешность попытки, источник подключения, итоговый пользователь и последующие действия.
Сам по себе успешный вход ещё не означает компрометацию. Гораздо информативнее цепочка: вход по SSH, запуск интерпретатора, загрузка файла, изменение прав и исходящее соединение с внешним узлом.
Сценарий Docker
Контейнеры демонстрируют главное различие между подходами. На уровне хоста один и тот же процесс может выглядеть как обычный запуск, тогда как специалисту нужно видеть имя контейнера, образ, pod, namespace и пользователя внутри него.
Falco и Tetragon обычно удобнее для таких сценариев благодаря контексту контейнерной среды. auditd способен фиксировать низкоуровневые действия, но восстановление связи с конкретным контейнером требует дополнительной обработки. Чем динамичнее инфраструктура, тем заметнее это ограничение.
Дополнительные критерии выбора
При выборе инструмента следует учитывать не только производительность. Большое значение имеют стабильность формата событий, совместимость с ядрами, наличие готовых правил, качество документации и возможность безопасного обновления.
Нужно заранее определить, где будет обрабатываться телеметрия. Локальная фильтрация уменьшает объём передачи и нагрузку на сеть, но повышает риск потерять данные из-за слишком агрессивных исключений. Передача всех событий в SIEM сохраняет больше контекста, однако требует ресурсов для хранения и корреляции.
Не менее важна защита самого механизма аудита. Злоумышленник, получивший привилегии, может попытаться отключить агент, изменить правила, удалить журналы или перегрузить канал событий. Поэтому конфигурацию необходимо контролировать отдельно, а логи - отправлять на удалённую систему с ограничением прав на удаление.
Практичный вариант для многих организаций - комбинированная архитектура. auditd можно оставить источником базового хостового аудита, eBPF-инструмент использовать для контейнеров и глубокого контекста, а SIEM или EDR - для корреляции и детектирования. Такой подход сложнее в сопровождении, зато позволяет не возлагать все задачи на один продукт.
Итоги
auditd остаётся надёжным решением для традиционного аудита Linux, особенно когда требуется нативность, предсказуемость и контроль системных операций. Его слабые места - сложная настройка, избыточная телеметрия и неудобство работы с контейнерами.
Falco выглядит наиболее убедительно в задачах контейнерной безопасности, хотя требует контроля потребления ресурсов. Tetragon предоставляет богатую телеметрию и глубокую трассировку, но нуждается в квалифицированной настройке. Kunai полезен для активного расследования и сбора расширенных данных. Sysmon for Linux подойдёт для простого структурированного мониторинга процессов и сетевых соединений.
Главный вывод заключается в том, что готовый агент сам по себе не превращается в EDR. Для качественной защиты нужны модель угроз, осмысленные правила, фильтрация, корреляция, контроль целостности и процесс реагирования. Во многих случаях оптимальным решением становится не поиск единственного "лучшего" инструмента, а аккуратное сочетание нескольких источников с учётом реальной нагрузки и задач инфраструктуры.