Linux EDR изнутри: как агенты собирают телеметрию и где у них слепые зоны

Последний наша команда разворачивала 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'ы - как EDR вписывается в общую картину защиты рядом с SIEM и NDR, я разобрал в полной карте обнаружения APT атак.

Три механизма сбора телеметрии в 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:

1. Разработчик определяет системные события, на которые агент должен реагировать (execve, connect, open, clone).
2. Для каждого события пишется eBPF-программа, компилируемая в байт-код.
3. При запуске агент загружает программы в ядро через системный вызов bpf().
4. Верификатор ядра проверяет программу на безопасность памяти и целостность потока управления.
5. Программа прикрепляется к хуку ядра (kprobe, tracepoint, LSM hook).
6. При срабатывании хука программа обрабатывает событие и передаёт данные в user-space через perf buffer или ring buffer.

По данным Red Canary, eBPF даёт ощутимое преимущество в производительности: часть фильтрации и анализа происходит прямо в ядре, что снижает объём данных, передаваемых в user-space. Spyderbat заявляет о менее чем 2% нагрузки на CPU для своего eBPF-агента. На практике - это единственный подход, который production-команды принимают без скрежета зубов.

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) достаточно мощны для атак. То есть механизм, созданный для защиты, сам становится вектором.

Применимость: modern-инфраструктура с ядром 5.8+ (BPF ring buffer, стабильные LSM hooks) для полноценного security monitoring - Ubuntu 20.04+, Rocky 9. Базовые kprobe-сенсоры работают с 4.1+, но без LSM hooks и CO-RE. Для legacy-серверов с ядром 3.x eBPF-based агент не подходит.

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​

Когда что ставить:

• Ядро 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 - стандартные тактики для этого этапа.
Если на хосте работает eBPF-based EDR, 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 (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-аналитики.
Слепое пятно: polling-модель. Между запросами (interval 30–300 секунд) short-lived процесс может отработать и исчезнуть незамеченным. Шелл отработал за 2 секунды, osquery опросил через 30 - в таблице пусто.

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

Большинство Linux-серверов в production работают без EDR. Не потому что админы не знают про угрозы - ни один вендор не дал им продукт, который не сломает production при обновлении ядра. Kaspersky делает ставку на собственный kernel module, CrowdStrike и Red Canary - на eBPF, Sandfly вообще отказался от агентов в пользу SSH-сканирования. По данным Mandiant M-Trends 2025, медианное время обнаружения злоумышленника в сети составляет 11 дней - исторический минимум. Но это глобальная цифра. Linux-серверы без EDR тянут её вверх: там, где нет сенсора, нет и обнаружения - инцидент всплывает, когда данные уже утекли.

На практике комбинация 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 - тишину, у вас та самая слепая зона, о которой вся эта статья.