Рантайм-безопасность на Go и eBPF: что это за класс инструментов и зачем он нужен

Я перекатываюсь из бэкенда на Go в сторону AppSec, и по дороге разбираюсь с темой, про которую у нас на русском пишут мало — рантайм-безопасность через eBPF. Хочу разложить идею: что это за инструменты, как они устроены изнутри, что уже есть в мире и почему именно сейчас на это смотрят в России. Без рекламы конкретного продукта, просто как карта местности для тех, кто думает, куда копать.

С чего вообще растёт эта идея

Антивирус и сканер уязвимостей проверяют систему в какой-то момент и уходят. Они говорят, что у тебя могло сломаться. Между двумя проверками остаётся окно, и в этом окне обычно и случается компрометация: кто-то залез через свежую дыру в зависимости, выполнил пейлоад, прочитал креды, ушёл.

Рантайм-агент закрывает другую задачу. Он постоянно смотрит, что происходит на хосте прямо сейчас: какие процессы запускаются, к каким файлам обращаются, какие сетевые соединения открываются. Открыли /etc/shadow — он это видит в момент открытия. Подняли root-шелл внутри контейнера, который должен крутить один веб-сервер — видит и это. Не постфактум по логам через неделю, а на месте.

Чем тут помогает eBPF

eBPF позволяет повесить свой код на события ядра, не собирая модули ядра и не трогая приложения. Ты загружаешь крошечную программу в ядро, она срабатывает на системные вызовы и отдаёт тебе данные в userspace. Один процесс при этом видит весь хост целиком, включая все контейнеры — потому что контейнер это те же процессы того же ядра.

Раньше под такое писали модули ядра, и это был отдельный вид боли: ошибка валит всю машину, под каждое ядро своя сборка. eBPF гоняется в песочнице с верификатором, который не пускает программу, способную уронить ядро. Цена входа резко упала, и за последние годы вокруг этого вырос целый пласт инструментов.

Что уже есть в мире

Чтобы не изобретать велосипед вслепую, полезно знать ориентиры.

Falco — самый известный, проект из CNCF. Ловит подозрительное поведение по правилам, отдаёт алерты, давно живёт в проде у больших команд. Фактически эталон жанра.

Tetragon от Isovalent (это команда Cilium) — упор на observability и на возможность не только заметить, но и прервать действие прямо в ядре. Заметно мощнее и тяжелее.

Tracee от Aqua Security — трейсинг и детект событий, удобен для разбора инцидентов и форензики.

Cilium — это уже не про детект, а про сеть: eBPF как датаплейн для Kubernetes, политики, балансировка. Но из той же технологической семьи.

Все они написаны на Go. Это не совпадение: для такого класса софта Go подходит почти идеально. Один статический бинарь без зависимостей, кросс-компиляция под amd64 и arm64 одной командой, нормальная конкурентность для разбора потока событий. Загрузчик eBPF в экосистеме тоже готовый — github.com/cilium/ebpf, чистый Go без cgo.

Как такая штука устроена внутри

Идея, которую стоит подсмотреть у взрослых проектов: программа в ядре не принимает решений. Она тупая по дизайну. Её задача — собрать факт и отдать наверх, а не рассуждать, опасно это или нет.

Схематично поток выглядит так:

        ядро  tracepoint на execve ─┐  tracepoint на openat ─┴─► ring buffer                            │        userspace           ▼  читатель ──► канал событий ──► движок правил ──► алерты ──► лог / SIEM

В ядре висят обработчики на нужные системные вызовы (execve для запуска процессов, openat для открытия файлов и так далее), они складывают событие в BPF ring buffer. Наверху, в обычном Go, программа читает эти события и прогоняет через правила: «открыт файл из чёрного списка», «запущен шелл от рута», «стартовала разведывательная утилита вроде nc или nmap».

Почему правила живут наверху, а не в ядре. eBPF-проекты известны тем, что их тяжело тестировать: нужен Linux нужной версии, рут, BTF, иногда отдельный стенд. Если вынести логику детекта в обычные Go-пакеты без единого импорта из мира eBPF, её можно покрыть юнит-тестами и гонять go test -race на любой машине, хоть в CI, без ядра и без прав. Правило получается чистой функцией от события:

type Rule interface {ID() stringEval(ev event.Event) (alert Alert, ok bool)}

Никакого общего состояния, никаких походов в ядро внутри Eval. За счёт этого движок безопасно вызывать из пула воркеров вообще без мьютексов, а программу ядра держать настолько простой, что её и ломать почти негде.

На что обычно ловят

Если смотреть на типовые правила в этих инструментах, набор довольно устойчивый:

• чтение чувствительных файлов (/etc/shadow, ключи в /root/.ssh/, конфиги);

• запуск шелла там, где его быть не должно, особенно от рута внутри контейнера;

• запуск разведывательного и пост-эксплуатационного инструментария (nc, nmap, socat, tcpdump);

• эскалация привилегий и подозрительные сетевые соединения.

Каждое такое событие хорошо ложится на тактики MITRE ATT&CK, так что алерты сразу получаются осмысленными для аналитика SOC, а не просто «что-то произошло».

Почему на это смотрят в России

С 2026 года ФСТЭК заметно ужесточает требования к защите ГИС и объектов КИИ, и поведенческий мониторинг там идёт как одна из мер. Параллельно идёт импортозамещение, и в спешке замены зарубежного софта на отечественный наплодили уязвимостей — рантайм-защита как раз страхует от того, когда сам продукт дырявый, но аномальное поведение всё равно видно.

При этом российский SIEM/SOC-рынок уже зрелый и движется к экосистемности: KUMA, R-Vision и прочие. Инструмент, который умеет отдавать события в формат, который эти системы понимают, встраивается в существующий контур сразу. А вот живого отечественного аналога Falco в нише почти нет. Западный класс инструмента понятен, спрос регуляторный, а место полупустое — комбинация редкая.

Куда тут можно копать

Если кому-то идея заходит, мест приложить руки хватает. Можно сделать правила конфигом в YAML вместо кода и подружить формат с Sigma. Можно вешать на алерты идентификаторы из БДУ ФСТЭК и MITRE, чтобы закрывать отчётность по КИИ. Можно писать экспортёр под KUMA, чтобы агент жил внутри SOC, а не отдельной коробкой. Можно расширять телеметрию: сеть, эскалация привилегий, загрузка модулей ядра.

Порог входа ниже, чем кажется издалека. Самое неприятное в eBPF — отладка, но если держать в ядре минимум, а логику гонять как обычный Go, львиная доля сложности уходит. А на выходе получается тема, в которой у нас на русском мало кто пишет, и которая закрывает реальный спрос.

Если у кого есть опыт eBPF в проде — интересно почитать, на что вы натыкались. Тема живая, граблей наверняка больше, чем видно с берега.