В поисках лучшего аудита событий Linux: auditd vs eBPF-решения

Вот важная новость с фронта ИИ: ibtivist 36 минут назад В поисках лучшего аудита событий Linux: auditd vs eBPF-решения Средний 74 мин 1. 5K Блог компании Бэклог Информационная безопасность * Linux * Серверное администрирование * Обзор Доброго времени суток, Хабр! Я ИБтивист Александр, скоро как 10 лет профессионально увлекаюсь информационной безопасностью и применяю свои исследования на практике.

Эта статья будет полезна ИТ- и ИБ-специалистам, которые интересуются аспектами логирования (аудита) и мониторинга безопасности в операционных системах семейства Linux. Рассмотрим и сравним классический подход к логированию auditd с осовремененными решениями на базе eBPF – tetragon, kunai, falco и Sysmon for Linux. Сразу скажу, что в статье не будет прорывных технологий – это чисто техническое сравнение инструментов для решения классических задач по безопасности.

Технические детали

Надеюсь, кому-то поможет подобрать оптимальный стек для решения своих задач, и научиться детектировать самые изощрённые вредоносные активности, или просто поможет с расширением кругозора в части возможностей различных средств мониторинга/аудита. TL;DRFalco – прожорливый, но герой (особенно для docker), а остальные решения … лучше оставить решать специфичные для них задачи))Tetragon – больше инструмент трассировки, его использование в контексте безопасности требует глубокого понимания работы ядра Linux. Нет каких-то суперконфигураций, поэтому для ИБ в чистом виде инструмент пока тяжеловат.

Kunai – отличное решение сбора объёмной телеметрии, но из-за слабоватой поддержки я бы отнёс это к решениям для активного триажа, а не регулярной работы. SysmonForLinux – простое решение, когда хочется структурированного вывода и закрытия самых базовых историй (что запустилось, с кем соединилось), но вряд ли справится со сложными атаками. Auditd – классическое решение, но работа с ним не приносит радости, особенно при контейнерах.

Если его обвязать объёмной детектирующей логикой SIEM/EDR/XDR, то ещё можно подумать. Старичок всё ещё хорош, когда речь идёт о чисто хостовом аудите благодаря нативности. В целом разработка суперконфигураций аудита приводит к выводу: необходима разработка и поддержка своего собственного EDR :(СодержаниеТипы событий мониторингаПодопытные проектыМетодика и условия тестированияРезультаты испытанийПо потреблению ресурсовПо количеству телеметрииПо качеству телеметрииСценарий 1: запуск процессовСценарий 2: взаимодействие с сетьюСценарий 3: операции с файламиСценарий 4: изменение файлов и атрибутовСценарий 5: вход пользователяСценарий 6: dockerИные критерии: впечатления от испытаний и инструментовВыводыТипы событий для мониторингаПредставим, что у нас есть потребность в защите конечных станций или серверов под управлением любой операционной системы семейства Linux.

Не углубляясь и спускаясь именно на уровень операционки, можно (условно! ) выделить следующие классы событий безопасности. Создание, завершение процесса.

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.