Что сравнивали и к какому выводу пришли

Тест на стенде с Debian 12 и ядром 6.1.0 прогнал пять инструментов аудита событий Linux: классический auditd и четыре решения на базе eBPF — falco (C++), tetragon (Go), kunai (Rust) и Sysmon for Linux, портированный с Windows. Каждый запускали дважды: из коробки и с расширенным набором правил. Проверяли расход ресурсов, объём телеметрии и её качество на шести сценариях — запуск процессов, сетевые соединения, операции с файлами, подмена бинарей и атрибутов, вход пользователя, действия внутри Docker-контейнера.

Единого победителя нет. Falco дал самый низкий порог входа для написания политик и лучший результат по контейнерам и сети. Auditd остаётся выбором для статичных систем, где заранее известны критичные файлы и службы, а поверх стоит SIEM. Kunai собирает максимум форензики, но перегружает хост и терпимо работает только при разовом триаже. Для устойчивого мониторинга описанный опыт приводит к связке из двух-трёх инструментов и к разработке собственного слоя агрегации — по сути к своему EDR-агенту.

Цена входа: ресурсы и требования к ядру

eBPF-решения зависят от версии ядра. Kunai требует ядро 5.4+ и в тесте жаловался на «слишком новое» ядро 6.1, из-за чего часть проб не подгружалась. Tetragon стартует с 4.19, falco с 4.x, Sysmon с 4.15. Для auditd этого вопроса нет, он работает через штатную подсистему аудита.

Расход ресурсов расходится на порядки. Из коробки auditd почти не трогает CPU и занимает около 2 МБ памяти. После подключения расширенных правил картина меняется: auditd поднимается до 7% CPU в среднем и 18% в пике, а журнал под нагрузкой ротируется примерно каждые 40 секунд. Kunai с адаптированными правилами показал около 31% CPU и 395 МБ памяти, falco — около 32% CPU и 180 МБ. При первом применении политики почти у всех наблюдался кратковременный всплеск CPU, который потом устаканивался.

Объём телеметрии тоже разный. Kunai из коробки выдал 81 МБ за прогон (примерно 76 событий в секунду), auditd — 23 КБ (0,04 EPS). После включения правил kunai собрал 42 МБ, auditd — 8 МБ. Большой поток — это не только диск, но и нагрузка на дальнейшую обработку в SIEM.

Где auditd показывает возраст

Событие auditd из коробки содержит только числовые идентификаторы. Чтобы увидеть имена пользователей и расшифровку системных вызовов, нужно выставить log_format = ENRICHED в /etc/audit/auditd.conf. Одно действие пользователя порождает несколько связанных записей — SYSCALL, EXECVE, CWD, PATH — с общим идентификатором, и для анализа их приходится схлопывать в одно логическое событие.

Командная строка и адреса сетевых соединений часто попадают в лог в HEX, иногда это касается и поля key. Правила и исключения можно писать только на сущности, которыми оперирует auditd: системные вызовы, аргументы, пути, результат операции, идентификатор пользователя. Сформулировать «логируй только обращения к /etc/passwd» или «только соединения на порт 53» нельзя — либо весь класс событий, либо ничего. Каждое активное правило висит в оперативной памяти, поэтому безоглядное логирование всех процессов и соединений на нагруженном сервере СУБД быстро создаёт проблему с ресурсами.

При этом на входе пользователя auditd сразу выдаёт события USER_AUTH, USER_LOGIN и CRED_* и оказался единственным, кто явно показывает результат аутентификации — успех или отказ.

Что дают eBPF-инструменты по отдельности

Falco выводит командную строку в читаемом виде, строит дерево процессов и в сценарии с сетью единственный показал реальное соединение с адресами и портом (10.0.2.15 → 195.208.4.1:53 UDP). В Docker-сценарии он сразу определил контейнер: короткий id, имя, образ alpine:latest и сработку правила «Drop and execute new binary in container». Политики пишутся просто — списки контролируемых файлов и формат вывода с фильтром по адресам, подсетям, доменам, портам. Ограничение: событие формируется на каждый факт, встроенной агрегации нет.

Tetragon фиксирует и запуск, и завершение процесса и вместе с kunai единственный чётко показал, что sleep 60 был убит сигналом SIGKILL. Расплата — высокий порог входа: политики требуют знания функций ядра, их аргументов и возвращаемых значений. Данные не обогащаются, auid=1000 в логе есть, а то, что это root, надо выяснять отдельно. Параметры родительского процесса закодированы в base64, адреса в сети не резолвятся.

Kunai пишет несколько типов хешей, разбирает заголовок файла по magic bytes, строит полную цепочку процессов и навешивает теги MITRE ATT&CK, в том числе несколько наборов на одно событие. Обратная сторона — до 52 событий на одну команду (около 30 после адаптации), потеря событий под нагрузкой и падения с ошибкой нехватки памяти при инициализации.

Sysmon for Linux даёт читаемый XML и SHA256 запускаемого файла, что помогает ловить подмену бинарей. Готовая конфигурация от Microsoft старше пяти лет, и после её применения инструмент потерял часть событий, включая nslookup и запуск nc. Его также приходится перезапускать после установки новых пакетов.

Слепые зоны, общие для всех

Ни один инструмент не разобрал чисто bash-овые конструкции: конвейеры, встроенную команду history, отправку сигнала через kill. При дописывании строки в /etc/sudoers через echo большинство увидело лишь открытие файла с флагом на запись, но не подтвердило сам факт изменения содержимого. Это общая граница подхода: событие фиксирует обращение, а оценка того, что именно поменялось в файле и чем это грозит, остаётся за SIEM, EDR или аналитиком.

Как выбирать

Отправная точка — тип инфраструктуры и наличие внешней экспертизы. Для набора серверов с фиксированным составом служб и уже развёрнутой SIEM auditd закрывает базовый хостовый аудит с минимальным расходом ресурсов, если принять стоимость ручной агрегации событий и HEX в логах. Для окружений с активным использованием Docker falco даёт больше полезного контекста при низком пороге написания правил. Kunai имеет смысл держать наготове для триажа и разбора инцидентов в песочнице, а не гонять постоянно. Tetragon оправдан там, где есть компетенция по ядру и нужна глубокая трассировка.

Проверяемый критерий готовности к любому из eBPF-вариантов — версия ядра и запас по CPU и памяти на самом нагруженном узле: тест показал разброс расхода в десятки раз и всплески при загрузке политик. Следующий шаг после выбора инструмента — решить, где будет происходить фильтрация и агрегация потока, потому что без этого слоя даже подробная телеметрия остаётся набором разрозненных событий.