Когда речь заходит про наблюдаемость безопасности на Linux, чаще всего всплывают два подхода: классический аудит через auditd и событийный мониторинг на базе eBPF (например, Falco и Tracee). Оба умеют «слышать» системные вызовы и важные действия в системе, но делают это по-разному — и дают разную ценность для админа, инженера по безопасности и тех, кто строит детектирование и отправку событий в SIEM.
Ниже — практическое сравнение: какие события реально увидите, как устроены правила, где появляется нагрузка, почему «шумит» и как это приземлить на hardening и detection engineering на сервере.
Коротко о моделях: «аудит» против «событий»
auditd — пользовательский демон, который читает события подсистемы Linux Audit (ядро) и пишет их в журнал (обычно /var/log/audit/audit.log). Его сильная сторона — формализованный аудит: “кто сделал что” в терминах syscalls, путей, прав, UID/AUID, SELinux-контекста и т.д. Это удобно для комплаенса и постфактум-разбора (forensics).
eBPF-инструменты уровня Falco/Tracee — это скорее сенсоры потоковой телеметрии: они подключаются к событиям ядра, обогащают их контекстом (дерево процессов, аргументы, cgroup/namespace, метаданные контейнера, сетевые атрибуты) и превращают низкоуровневые события в более удобные для детектирования «сценарии».
Если упростить:
auditd— это «строгий журнал действий», а eBPF-стек — «сенсор, из которого проще делать детекты и алерты в реальном времени».
Что именно видно: какие события реально поймаете
auditd: сильные стороны покрытия
Сильная сторона auditd — привязка к модели безопасности Linux и доказуемость: пользователи, группы, права, факты доступа и изменения. Он особенно хорош там, где нужно точно зафиксировать факт и иметь устойчивую цепочку “кто/когда/чем”. Типовые кейсы:
Доступ к конкретным файлам и каталогам (ключи SSH, конфиги, секреты приложений).
Изменения критичных конфигураций (например,
/etc/passwd,/etc/sudoers, unit-файлы systemd).Аудит использования привилегий: запуск программ, смена идентичности, попытки обхода контроля доступа.
Комплаенс: формализованная политика аудита и воспроизводимые отчёты.
Практический нюанс: auditd отлично логирует то, что вы явно описали правилами. Но если включить «слишком широко», вы быстро упрётесь в поток событий, размер логов и I/O.
eBPF security (Falco/Tracee): сильные стороны покрытия
Falco и Tracee чаще воспринимаются как runtime-сенсоры: их сила — богатый контекст и удобство поведенческих детектов. Типовые кейсы:
Поведенческие сигналы: «веб-процесс внезапно запустил shell», «в контейнере пошли неожиданные утилиты».
Мониторинг syscalls в контейнерных средах с привязкой к namespace/cgroup.
Готовые сигнатуры/правила на уровне runtime, которые легко тюнить под стек.
Удобный real-time pipeline: фильтрация, обогащение, алертинг.
Нюанс eBPF-подхода: это не «единый стандартный журнал», а инструментальная телеметрия. Семантика и поля события зависят от сенсора, версии ядра, драйвера и качества правил.
Правила и детекты: Linux audit rules vs Falco/Tracee
Как мыслит auditd
Linux audit rules — это в первую очередь “политика, что логировать” (audit policy), а не «логика детектирования атак». Детекты обычно строятся поверх аудита: в SIEM, в корреляционном движке или в собственном пайплайне.
Практический эффект: хорошая конфигурация audit rules — это набор точечных правил на критичные пути и минимально достаточные syscalls. Попытка «логировать всё» быстро упирается в хранение, разбор, I/O и поддержку правил.
Минимальная база для старта обычно выглядит как «наблюдаем изменения в /etc и чувствительных директориях, плюс фиксируем ключевые события запуска/привилегий». Пример (адаптируйте под вашу политику и ОС):
# Debian/Ubuntu: правила обычно хранятся в /etc/audit/rules.d/
# Перезагрузка правил
sudo augenrules --load
sudo systemctl restart auditd
# Проверить, что загружено
sudo auditctl -lОбратите внимание: в auditd вы выиграете, если будете маркировать правила ключами и заранее договоритесь, какие ключи важны для SIEM-корреляции.
Как мыслит Falco
Falco — это движок детектирования поверх событий: правила описывают паттерны поведения (условия на процесс, аргументы, пользователя, контейнер, сетевые атрибуты) и действие (alert). Поэтому Falco часто внедряют как runtime IDS (по факту IDS, не «магическая защита»).
Особенность: правила Falco проще читать как детекты, но их нужно сопровождать как код: тестировать, версионировать, делать ревью изменений и аккуратно работать с исключениями для легитимной автоматизации.
Если вы только начинаете, полезно сначала собрать «карту нормального»: какие процессы и утилиты реально запускаются на хосте и в контейнерах. Дальше любые «шеллы», «пакетные менеджеры», «инструменты сети» вне ожидаемого контекста становятся хорошими сигналами.
Как мыслит Tracee
Tracee фокусируется на наблюдении и детектировании на базе eBPF с уклоном в богатую телеметрию и готовые детекты. На практике его часто используют как инструмент для detection engineering: посмотреть, какие события происходят на самом деле, и какие поля помогут собрать качественный сигнал.
Если Falco часто воспринимают как «алертинг-движок с правилами», то Tracee — как «сенсор и платформа для событий», откуда вы строите цепочку: фильтры, экспорт, корреляция, дополнительные проверки.
Производительность и стоимость: где обычно “болит”
В выборе между auditd и eBPF security часто решает не философия, а ресурсная и операционная стоимость: CPU, I/O, объём событий, стоимость хранения/парсинга и сложность сопровождения.
auditd: типичные источники нагрузки
I/O и объём логов.
audit.logможет расти очень быстро, если включить широкие правила на файловые события или syscalls.Очередь аудита и потери. При перегрузке возможны дропы/задержки; важно контролировать настройки очередей и поведение при переполнении.
Сложность точного охвата. Чем больше правил, тем дороже сопровождение и объяснение, почему логируете именно это.
eBPF (Falco/Tracee): типичные источники нагрузки
Высокая частота событий. Syscall monitoring на нагруженном вебе/БД даёт огромный поток. Нужны фильтры и ограничение контекста.
Обогащение контекстом. Цепочки процессов, аргументы, контейнерные метаданные — всё это повышает стоимость события.
Совместимость и обновления ядра. eBPF зрелый, но отдельные возможности зависят от версии ядра и реализации драйвера/проб.
Рекомендация для VDS почти всегда одна: начните с минимально полезного набора сигналов, замерьте поток событий и только потом расширяйте покрытие. И auditd, и eBPF легко превращаются в «лог-пушку», если включать всё подряд.
false positives: почему “шумит” и как снижать
Ложные срабатывания почти всегда связаны с тем, где именно вы делаете детектирование и насколько хорошо описали «норму» для вашего сервера.
auditd и ложные срабатывания
Если auditd используется как источник для SIEM, то false positives обычно появляются из-за:
слишком широких правил (например, мониторинг записи в директорию, куда постоянно пишет приложение);
недостатка контекста на уровне события (без обогащения сложно отличить админскую активность от автоматизации);
ошибок нормализации/парсинга в пайплайне (когда поля интерпретируются неправильно).
Снижение шума в auditd почти всегда начинается с пересмотра правил: точнее указать пути, ограничить события только записью/изменением, сузить набор syscalls, аккуратно маркировать ключами и отдельно сопровождать исключения под легитимную автоматизацию.
Falco/Tracee и ложные срабатывания
В eBPF security false positives чаще связаны с поведенческими правилами: они удобны, но ловят редкие и легитимные сценарии (деплой, миграции, отладка, бэкапы, healthcheck-агенты).
Рабочая тактика тюнинга:
Сегментация по ролям. Разные правила и исключения для prod/stage/CI.
Исключения по подписи процесса. Белые списки по
proc.name,proc.exepath, аргументам.Учет пользователя/контейнера. То, что критично на хосте, может быть нормой внутри build-контейнера.
Лимиты и дедупликация. Чтобы бурст событий не превращался в сотни одинаковых алертов.
Отдельно полезно выстроить процесс «принятия шума»: каждое исключение должно быть объяснимым (почему это легитимно), воспроизводимым (как проверить) и ограниченным по контексту (хост, сервис, контейнер, путь).
Интеграция с SIEM и лог-пайплайном
Для многих команд именно интеграция с SIEM определяет, чем пользоваться: строгим аудитом или runtime-детектами.
auditd → SIEM
У auditd понятная модель: лог-файл/поток, стабильные поля, строгая политика. Для SIEM это удобно в долгой перспективе:
формат событий относительно стабилен;
легко доказать покрытие (“вот политика аудита, вот события”);
проще выстроить ретеншн и контроль целостности журнала.
Минус — часто не хватает контекста «как именно выглядела атака», и приходится обогащать данные: сведения из инвентаризации, данные о деплоях, контейнерный контекст. Для задач «алертинг здесь и сейчас» иногда получается тяжеловато по времени разработки.
Falco/Tracee → SIEM
eBPF-сенсоры часто дают уже «готовый сигнал» (alert) плюс полезные поля контекста. Это сокращает время triage в SOC-процессах.
Чтобы не потерять расследовательскую ценность, удобно разделять два потока:
alert stream — оперативные алерты для SIEM/SOAR;
event stream — выборочный сырой поток для расследований и обучения детектов.
Если хотите глубже разобраться с eBPF-инструментами для диагностики и кастомных наблюдений (bcc, bpftrace), посмотрите материал про диагностику Linux через eBPF — он хорошо помогает понять ограничения и стоимость разных типов проб.
Hardening VDS: что выбрать в реальном админском сценарии
Для hardening на VDS обычно важны три вещи: не убить производительность, получить управляемый поток событий и иметь понятный процесс сопровождения правил.
Сценарий 1: “Нужен строгий аудит и комплаенс”
Если есть требование хранить и предъявлять журнал действий (кто менял конфиги, кто трогал ключи, кто лазил в /etc), то auditd — базовый кандидат. Его проще формализовать, проще обеспечить ретеншн и целостность логов.
Сценарий 2: “Нужно детектирование атак в рантайме и быстрые алерты”
Если цель — runtime-дetects и быстрые сигналы (подозрительный запуск shell, неожиданные сетевые действия процесса, попытки чтения секретов), то Falco/Tracee обычно быстрее дают ценность. Особенно когда у вас контейнеры и много микросервисов.
Сценарий 3: “Нужна комбинация”
На практике часто выигрывает гибрид:
auditd — точечный аудит критичных файлов и административных действий (минимальный, но качественный).
Falco/Tracee — поведенческие алерты и runtime-детекты, с тюнингом под ваш стек.
Так вы получаете и «журнал для расследований», и практичные сигналы для реагирования.
Если вы подбираете площадку под такие задачи, на VDS проще контролировать ядро, агентный стек и объём телеметрии, чем на «сверх-общем» окружении.
Практика внедрения: как стартовать без боли
Самый частый провал — попытка «включить максимум» в первый день. Рабочий план внедрения обычно такой:
Определить активы и угрозы. Какие ключи/конфиги/сервисы критичны, какие сценарии атак вероятны.
Собрать базовую телеметрию. Минимальный набор audit rules или базовые правила Falco/Tracee, чтобы увидеть реальный шум.
Замерить поток событий. Сколько событий в минуту, что самое шумное, сколько стоит хранение и разбор.
Тюнить false positives. Исключения для деплоя, бэкапа, мониторинга, CI-агентов.
Оформить правила как код. Версионирование, ревью, тестовый стенд, понятные изменения.
Привязать к реакции. SIEM без реагирования превращается в архив: заведите playbooks хотя бы для топ-5 сигналов.
Как практичный пример «сигнала, который легко приземлить в процесс», хорошо работают алерты на подозрительные SSH-входы и эскалации. Это можно строить как на audit/journald, так и в связке с runtime-детектами. Для идей и разметки событий пригодится статья про алерты на SSH-логины через PAM и journald.
Итоги: как выбрать между auditd и eBPF security
Выбор между auditd и eBPF (Falco/Tracee) — это не «или/или», а про приоритеты и операционную зрелость.
auditd — когда важны строгий аудит, формальная доказуемость, точечный контроль доступа к файлам и предсказуемая интеграция с SIEM как с журналом.
Falco/Tracee — когда нужен runtime security, syscall monitoring с богатым контекстом, быстрые детекты и удобный язык правил для detection engineering.
Гибрид — часто лучший баланс: auditd как «чёрный ящик» для расследований, eBPF как «сигнализация» в реальном времени.
Стартуйте с инвентаризации критичных точек (ключи, конфиги, пайплайны деплоя), включите минимально полезное логирование и детекты, а затем расширяйте покрытие, контролируя шум и стоимость. В безопасности выигрывает не тот, кто собрал больше событий, а тот, кто умеет превращать события в действия.
