Последний наша команда разворачивала eBPF-сенсоры на production Linux-серверах - CentOS 7, Ubuntu 22.04, Rocky 9. Итог неутешительный: агент endpoint detection response стабильно видит
execve и connect, но пропускает ptrace-инъекцию в легитимный процесс. И дело не в конкретном продукте - архитектура сбора телеметрии в Linux принципиально отличается от Windows, и большинство вендоров эту разницу до сих пор не закрыли.По данным CrowdStrike Global Threat Report 2025, 79% атак (по всем платформам) идут без malware - hands-on-keyboard, living off the land. Для Linux отдельной статистики CrowdStrike не публикует, но living-off-the-land здесь особенно характерен: штатный toolchain настолько богат (см. GTFOBins), что агент обнаружения угроз должен видеть не только запуск бинарей, но и манипуляции с процессами, модулями ядра, eBPF-программами. Разберём, как Linux EDR агенты собирают данные, где у них слепые зоны и какие open-source решения закрывают конкретные gap'ы.
Три механизма сбора телеметрии в Linux EDR
Любой Linux EDR агент - набор сенсоров, каждый из которых тянет события из одного или нескольких источников. По данным исследования Outflank, коммерческие агенты собирают минимум четыре типа событий: запуск процессов, сетевые соединения, файловые операции, изменения пользователей и групп. Способ сбора определяет и возможности, и ограничения агента безопасности Linux.eBPF: основа современного eBPF security monitoring
eBPF (extended Berkeley Packet Filter) - технология, позволяющая запускать пользовательский код внутри ядра Linux в изолированной песочнице. Согласно исследованию Invary, eBPF изначально создавался для фильтрации пакетов, но вырос в универсальный фреймворк для observability, security enforcement и мониторинга производительности. Эволюция впечатляющая - от пакетного фильтра до полноценной платформы для security monitoring.Как это работает в контексте endpoint detection response Linux:
- Разработчик определяет системные события, на которые агент должен реагировать (
execve,connect,open,clone). - Для каждого события пишется eBPF-программа, компилируемая в байт-код.
- При запуске агент загружает программы в ядро через системный вызов
bpf(). - Верификатор ядра проверяет программу на безопасность памяти и целостность потока управления.
- Программа прикрепляется к хуку ядра (kprobe, tracepoint, LSM hook).
- При срабатывании хука программа обрабатывает событие и передаёт данные в user-space через perf buffer или ring buffer.
Red Canary описывает реализацию eBPF-сенсора через проект oxidebpf - Rust-библиотеку для управления eBPF-программами. Подход Compile-Once, Run-Most-Places решает проблему зоопарка дистрибутивов: несколько версий probe загружаются в один ELF-бинарь, и агент выбирает подходящую для текущего ядра. Например, probe может использовать
clone3 на новых ядрах и fallback на clone на старых.Ограничения eBPF для security monitoring:
- eBPF появился в ядре 3.18 (2014), kprobe-программы (BPF_PROG_TYPE_KPROBE) - с 4.1, tracepoint-программы - с 4.7, raw_tracepoint - с 4.17, CO-RE (BTF) - с 5.2+, BPF LSM hooks - с 5.7, BPF ring buffer - с 5.8. Реальная совместимость зависит от конкретной сборки. Kaspersky прямо пишет: «нюансов здесь столько же, сколько сборок Linux». И это не преувеличение.
- Смещения структур ядра (kernel offsets) различаются между версиями и дистрибутивами, что превращает создание универсального сенсора в квест. Red Canary строит систему LKCCB (Linux Kernel Component Cloud Builder) для автоматического определения offsets по каждой сборке - отдельный проект ради одной проблемы.
- eBPF-программы не вызывают произвольные функции ядра - только предопределённые helper functions. Но некоторые из них (
bpf_probe_write_user,bpf_override_return) достаточно мощны для атак. То есть механизм, созданный для защиты, сам становится вектором.
auditd: legacy-подход с проблемой монопольного режима
Linux Auditing System (auditd) - стандартный механизм аудита, доступный практически на любом дистрибутиве. Работает из user-space, подключаясь к аудит-подсистеме ядра через netlink-сокет. Штука старая, проверенная - и с характерными болячками.Главная проблема для обнаружения угроз Linux: по данным Kaspersky, для гарантированного получения всех событий защитное решение должно использовать auditd в монопольном режиме. Это создаёт конфликт - если EDR и SIEM одновременно требуют аудит-события, один из них не получит полных данных. В немонопольном режиме «нельзя гарантировать доставку событий» и «не получится разделить потоки для разных подписчиков». На практике это значит: EDR и SIEM получают один и тот же нефильтрованный поток, перегружая SIEM нерелевантным шумом.
Red Canary подтверждает: auditd создаёт заметную нагрузку на производительность, телеметрия ограничена предопределёнными типами событий, и «once events are consumed from AuditD, they're gone» - один потребитель съел, второму ничего не досталось.
Когда auditd оправдан: legacy-инфраструктура (CentOS 6/7, ядро 2.6.x–3.x), compliance-сценарии, среды с жёсткими требованиями совместимости. Если у вас CentOS 6 в production (а я такое видел чаще, чем хотелось бы) - auditd единственный вариант.
Kernel modules (LKM): максимальный доступ, максимальные риски
Загружаемые модули ядра дают агенту прямой доступ к kernel telemetry Linux через внутренние структуры. Kaspersky использует этот подход в технологии ULKM (Universal Linux Kernel Module) для Kaspersky Endpoint Security for Linux - по их данным, нагрузка на систему снижается «в 20 и более раз по сравнению с предыдущими версиями».Звучит красиво, но Sandfly Security описывает обратную сторону: ошибка в модуле ядра приводит к kernel panic, а не к простому падению процесса. Модуль нужно компилировать под конкретную версию ядра, и при тысячах вариантов сборок полное тестирование невозможно. Sandfly прямо указывает: «it is simply impossible for an agent-based EDR vendor to test against all the permutations, architectures, patch-levels». Организации попадают в парадокс: откладывают security-патчи ОС, чтобы не сломать EDR-агент. Защита, которая мешает обновляться - ирония, но реальность.
Применимость: серверы с контролируемым обновлением ядра, фиксированная версия внутри организации, критичность производительности. CrowdStrike Falcon, SentinelOne, Cybereason EDR Linux - все используют kernel-level компоненты в той или иной форме.
Сравнение подходов: decision tree
| Критерий | eBPF | auditd | LKM |
|---|---|---|---|
| Минимальная версия ядра | 3.18+ (kprobe 4.1+, tracepoint 4.7+, raw_tracepoint 4.17+, BTF/CO-RE 5.2+, LSM 5.7+, ring buffer 5.8+) | 2.6+ | Любая (привязка к конкретной) |
| Нагрузка на CPU | Менее 2% | 5-15% | Зависит от реализации |
| Параллельная работа с SIEM | Да, множество потребителей | Только монопольный режим гарантирует доставку | Да |
| Риск kernel panic | Минимальный (верификатор) | Нет (user-space) | Высокий |
| Гибкость сбора | Произвольные точки ядра | Предопределённые события | Полный доступ |
| Совместимость между дистрибутивами | Проблемная (offsets) | Отличная | Требует пересборки под каждое ядро |
Когда что ставить:
- Ядро 5.8+ (ring buffer, стабильный LSM), modern-инфраструктура → eBPF (базовые kprobe-сенсоры - с 4.1+)
- Legacy CentOS 6/7, compliance → auditd
- Контролируемая среда с фиксированным ядром → LKM
- Смешанная инфраструктура → гибрид (eBPF + auditd fallback)
Fingerprinting Linux EDR: recon на целевом хосте
При внутреннем пентесте после получения initial access первая задача - понять, какой агент безопасности стоит на хосте. Результат fingerprinting определяет всю стратегию evasion. Process Discovery (T1057, Discovery) и System Information Discovery (T1082, Discovery) по MITRE ATT&CK - стандартные тактики для этого этапа.
Bash:
# Поиск известных EDR-процессов (внутренний пентест, post-exploitation)
ps aux | grep -iE 'falcon-sensor|ossec|wazuh|falco|osqueryd|elastic-agent|SentinelOne|cybereason'
# eBPF-программы (требует root или CAP_SYS_ADMIN)
bpftool prog list 2>/dev/null | head -20
# Загруженные kernel modules
lsmod | grep -iE 'falcon|cbsensor|kaspersky|ulkm|wazuh|sysdig'
# Правила auditd (требует root)
auditctl -l 2>/dev/null | head -10
# Примечание: все команды выше требуют root для полного вывода.
# На Ubuntu 22.04+ unprivileged_bpf_disabled=1 по умолчанию -
# без root bpftool prog list вернёт ошибку даже при наличии загруженных программ.bpftool prog list покажет программы типа kprobe, tracepoint, lsm с характерными именами или ID. Типичные хуки для мониторинга процессов Linux: sys_execve, sys_connect, sys_open, sys_clone, sys_ptrace.Контекст применимости: эти команды работают на любом дистрибутиве.
bpftool может отсутствовать на legacy-серверах - альтернативы: ls /sys/fs/bpf/ (если pin'ы доступны), ss -xp | grep bpf, анализ /proc/[pid]/maps на наличие libbpf. /proc/kallsyms покажет лишь наличие BPF-инфраструктуры в ядре, но не загруженные программы. Для auditd-based агентов auditctl -s покажет статус подсистемы и имя процесса-потребителя.Ограничения при внешнем пентесте: fingerprinting возможен только после получения shell. До этого - косвенные признаки: паттерны блокировки соединений, DNS-запросы к облачным консолям вендоров (
sensor-[I].crowdstrike.com, [/I].cybereason.net). Негусто, но иногда хватает, чтобы сузить список.Обход EDR Linux: техники и их детектируемость
Знание evasion-техник нужно и при построении detection engineering, и при пентесте. Каждая техника ниже - с указанием, какой механизм сбора её видит, а какой пропускает.Open-source EDR Linux: Falco, osquery, Wazuh
Три open-source решения покрывают разные аспекты Linux threat hunting. Ни одно из них не заменяет коммерческий EDR (CrowdStrike Falcon, SentinelOne, Cybereason EDR Linux), но в комбинации они закрывают большинство use-cases. А для серверов, где коммерческого EDR нет и не будет - это вообще единственный вариант.| Критерий | Falco | osquery | Wazuh |
|---|---|---|---|
| Механизм сбора | eBPF / kernel module | Virtual tables (procfs, /sys) | Собственные модули (logcollector, syscheck, rootcheck) + опциональная интеграция с auditd |
| Режим работы | Real-time, event-driven | Polling (scheduled queries) | Real-time + scheduled |
| Язык правил | YAML (Falco rules) | SQL (osquery schema) | XML (rules) + JSON (decoders) |
| Мониторинг процессов | execve, clone, fork | process_events table | Через auditd syscall rules |
| Сетевая телеметрия | connect, accept, sendto | socket_events, listening_ports | Частично (через auditd) |
| File integrity | Не основная задача | file_events table | Нативно (syscheck) |
| Контейнеры / K8s | Нативно (CNCF graduated) | Через расширения | Через агент в контейнере |
| Статус проекта | CNCF Graduated, активно | osquery Foundation, активно | Wazuh Inc., активно |
Falco (CNCF graduated project) использует eBPF или kernel module для перехвата syscall-хуков и генерации алертов в реальном времени. Из коробки детектирует: запуск shell в контейнере, чтение
/etc/shadow, ptrace-атаки, изменение namespace. Покрывает Process Injection (T1055) и Proc Filesystem credential access (T1003.007). Слепое пятно: если событие не генерирует хукнутый syscall - Falco его не увидит. Чтение /proc/[pid]/maps через cat выглядит как обычный open + read, и без тонко настроенного правила алерт не сработает.osquery (osquery Foundation) превращает ОС в реляционную базу данных. Вместо хуков - опрос системных таблиц по расписанию. SQL-интерфейс - это то, за что его любят SOC-аналитики.
SQL:
-- Обнаружение процессов с LD_PRELOAD (Linux threat hunting)
SELECT p.pid, p.name, p.cmdline, pe.key, pe.value
FROM processes p
JOIN process_envs pe ON p.pid = pe.pid
WHERE pe.key = 'LD_PRELOAD';
-- видит только LD_PRELOAD, заданный на момент execve (через /proc/[pid]/environ);
-- runtime-инъекция через ptrace+dlopen этим запросом не детектируетсяWazuh (Wazuh Inc.) - наследник OSSEC. Единая платформа: агент, менеджер, SIEM, compliance-отчёты. Поддерживает широкий спектр дистрибутивов, включая legacy. Слепое пятно: для syscall-телеметрии Wazuh опирается на интеграцию с auditd, наследуя его ограничения (монопольный режим, фиксированные типы событий, нагрузка на I/O), хотя FIM и rootcheck работают независимо. Wazuh-агент - постоянный процесс с известным именем (
wazuh-agentd), что делает его мишенью для Disable or Modify Tools (T1562.001). Название процесса - как табличка «убей меня первым».Decision tree: что развернуть
- Kubernetes / контейнерная среда, ядро 4.15+ → Falco (real-time eBPF, CNCF ecosystem)
- Threat hunting, ad-hoc расследования → osquery (SQL, кросс-платформенный)
- Compliance + detection + SIEM, включая legacy → Wazuh (auditd-based, широкая совместимость)
- Минимальный overhead на production → Falco (eBPF) + osquery (scheduled, низкая нагрузка между запросами)
- Максимальное покрытие → комбинация всех трёх + коммерческий EDR для critical assets
Требования к окружению для тестового стенда
Чтобы воспроизвести описанные техники fingerprinting и проверить детектирующие правила:- ОС: Ubuntu 22.04 LTS или Rocky 9 (ядро 5.15+ для полной поддержки eBPF)
- RAM: минимум 4 ГБ для Falco + osquery на одной VM, 8 ГБ для Wazuh с менеджером
- CPU: 2 vCPU минимум
- Зависимости:
bpftool(пакетlinux-tools-commonна Ubuntu),auditd, Docker для контейнерных сценариев Falco - Сетевой режим: offline-развёртывание возможно для Falco и osquery (пакеты скачиваются заранее). Wazuh-менеджер требует сетевого доступа для обновления ruleset
- Права: root или sudo для загрузки eBPF-программ и управления auditd
На практике комбинация Falco (real-time eBPF) + osquery (scheduled hunting) + минимальный набор auditd-правил покрывает основную массу MITRE ATT&CK-техник для Linux. Оставшееся - eBPF-rootkitы и fileless-атаки через ptrace - не закрывает ни один open-source HIDS Linux агент. Для них нужен либо коммерческий EDR с kernel-level компонентом, либо agentless-подход с внешней верификацией integrity.
Рынок Linux EDR сейчас в том же состоянии, в котором был рынок Windows EDR лет семь назад: базовая телеметрия собирается, adversary simulation для Linux-хостов никто не делает системно, а вендоры конкурируют по количеству поддерживаемых дистрибутивов, а не по глубине детекта. Кто первым закроет gap между eBPF-observability и полноценным behavioral detection - тот заберёт рынок. Проверьте свои Linux-серверы командами из раздела fingerprinting. Если
bpftool prog list возвращает пустоту, а ps aux | grep falcon - тишину, у вас та самая слепая зона, о которой вся эта статья.
Последнее редактирование:
