Технология eBPF (Extended Berkeley Packet Filter) — инновационный инструмент, позволяющий запускать изолированные программы в ядре операционной системы. Благодаря этому можно безопасно расширять функциональность ядра без изменения его кода или загрузки дополнительных модулей.

Исторически ядро ОС — идеальная платформа для задач мониторинга, безопасности и сетей, но его развитие ограничивалось высокими требованиями к стабильности. eBPF кардинально меняет ситуацию: благодаря JIT-компилятору и верификатору она позволяет разработчикам добавлять возможности в реальном времени с гарантированной безопасностью и эффективностью. 

Сегодня eBPF активно используется для высокопроизводительных сетей, мониторинга безопасности, отслеживания приложений и анализа производительности. Ее потенциал открывает широкие горизонты для дальнейших инноваций в области ИТ-безопасности и не только.

У eBPF-программ разные типы для решения задач в области трассировки, безопасности, сетевого взаимодействия и управления ресурсами. Программы работают на основе eventdriven-модели, запускаясь в ответ на события в ядре: системные вызовы, сетевые пакеты или доступ к файлам. Это обеспечивает сбор данных в реальном времени с минимальными накладными расходами. 

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

Типичное приложение с использованием eBPF состоит из двух частей: kernel и user mode. Разработка обычно проводится с использованием специализированных библиотек libbpf ©, cilium/ebpf (Go), aya (Rust), причем eBPF-часть, работающая в ядре, может разрабатываться только на языках C или Rust. 

Компиляция eBPF-программы в байткод происходит с помощью clang или rustc. Чтобы она была совместима с разными версиями ядра Linux, используется технология CO-RE. С помощью вызова из специализированных библиотек, а точнее системного вызова bpf, происходит загрузка eBPF-программы в ядро. Перед загрузкой программа должна пройти верификацию, за которую отвечает отдельный компонент в ядре. После этого с помощью JIT-компилятора байткода программа транслируется в машинный код, после чего готова к выполнению.

Современные средства безопасности, например EDR (Endpoint Detection and Response), не обходятся без применения технологии eBPF. EDR-системы требуют глубокого анализа поведения операционной системы, включая системные вызовы, сетевую активность и взаимодействие процессов. 

Традиционные подходы часто требуют установки дополнительных модулей ядра или изменений в его коде, что может привести к снижению стабильности и безопасности системы. eBPF выглядит привлекательно: технология позволяет извлекать множество полезной информации из ядра ОС, при этом гарантируя безопасность (eBPF-программы проходят стадию верификации при загрузке в ядро). Разработка EDR-решений ведется не только крупными ведущими коммерческими компаниями, но и в open-source-сообществе. Вот примеры SoTA open-source-проектов:

• Tetragon.
• Falco.
• Tracee.

Tetragon использует низкоуровневые контекстные политики, которые учитывают процессы, файлы, сетевые соединения, метаданные Kubernetes (Pod, namespace). Falco — YARA-like-правила с поддержкой логических операций и переменных. Tracee позволяет реализовывать пользовательские сигнатуры на Go, имеет библиотеку готовых сигнатур.

Актуальные задачи по направлению. Крупные технологические компании основательно подходят к внедрению open-source-инструментов, предъявляя высокие требования к надежности и производительности. 

Задача сравнительного анализа SoTA-инструментов (Tetragon, Falco, Tracee) необходима для понимания возможности их масштабного внедрения. Сравнительный анализ производительности агентов (потребления CPU, памяти) осложняется тем, что агент — не только приложение в user mode, но и eBPF-программы, которые работают в контексте ядра.

Часть нагрузки, которая производится агентскими eBPF-программами, растворяется в общем потреблении ресурсов ядром и привычными способами мониторинга не выявляется. Поэтому актуальна задача по измерению потребления ресурсов eBPFпрограммами на высоко нагруженных системах и разработке соответствующего инструментария для измерения.

Современные low-code-решения позволяют эффективно и быстро масштабировать бизнес-процессы. В Т-Банке используется решение собственной разработки — TWork-процедуры. 

TWork-процедура — автоматизированный алгоритм в виде блок-схемы для управления бизнес-процессом. Процедура может иметь UI для ввода и вывода информации, взаимодействовать с разными сервисами, обрабатывать данные, проводить операторов и клиентов по бизнес-процессу. Процедуры позволяют легко масштабироваться и быстро выводить любой бизнес-процесс в продуктивную среду. 

Процедура представлена массивом переменных и графом из блоков. У каждого блока есть указатель на следующий. Блок — форма, выражение, подпроцедура, вызов интеграции (колл) — интерпретируется обработчиком на backend. 

В процедурах поддерживается встроенный язык выражений. Выражение — формула с данными, которые должны рассчитываться в процессе выполнения процедуры. Язык выражений реализован на базе Spring Expression Language SpEL. Пример выражения:

#IF (#DATE == null, 'Нет даты', #FORMAT_DATE (#DATE))

Сильная сторона процедур — множество готовых интеграций со многими системами банка. Для эффективного масштабирования проверки безопасности требуют все большей автоматизации.

Low-code-решения значительно отличаются от классических языков программирования. Доработка open-source-SAST-инструментов требует значительных усилий.

Semgrep/CodeQL:

• Добавление парсера языка. Проблема: low-code-решение — это не язык, описываемый контекстно-свободной грамматикой, а граф вычислений/выполнения.
• Интеграция парсера с основным движком. Проблема: требуются значительные изменения в движке.

Bpmnlint — общая концепция подходит для решения задачи, но есть много технических различий между BPMN и TWork-процедурами: скудный набор проверок, нет правил на безопасность.

Актуальные задачи по направлению. Портирование классических подходов, применяемых в статическом анализе, на TWork-процедуры:

• Разработка AST-анализатора для языка выражений TWork-процедур.
• Анализ путей в графе выполнения процедуры, поиск шаблонов на графе.
• Анализ помеченных для TWork-процедур.

Невозможно представить современную эксплуатацию программного обеспечения без периодического сканирования известных уязвимостей. Попытки поэксплуатировать уже известные уязвимости активно используются злоумышленниками, потому что это значительно проще и дешевле, чем разрабатывать 0-day-эксплойты. 

Важно своевременно обнаруживать версии ПО, которые содержат известные уязвимости, и затем проводить оперативное обновление до версий с устранением этих уязвимостей. Для этого широко распространены инструменты сканирования уязвимостей: osv-scanner, grype, trivy, которые можно назвать SoTA-open-source-решениями в данной области.

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

Этап извлечения информации о пакетах и версиях можно назвать ключевым, и ошибки на нем напрямую влияют на результат. Например, не всегда удается определить версии исполняемых бинарных файлов, если они установлены на систему не с помощью пакетных менеджеров (apt, rpm, и так далее). Такая ситуация может привести к пропуску уязвимостей. Возникают ситуации, когда версия определена неправильно, например не учтен патч (часто мейнтейнеры дистрибутивов сам бэкпортят патчи). Это приводит к ложным сообщениям о найденных уязвимостях.

Поиск уязвимостей по открытым базам — нетривиальная задача: нужно проанализировать много источников и у разных баз данных своя информация об уязвимостях. Сканеры решают эту задачу, добавляя слой абстракции. Например, osv-scanner работает с OSV-базой, у который единая схема определения уязвимостей для разных типов активов (dpkg, cargo, python, etc). Grype решает эту проблему с помощью инструмента vunnel, который агрегирует данные об уязвимостях из разных источников.

Описанная схема работы предполагает, что сбор информации об установленных активах и процесс сканирования проходят на целевой системе. Такой подход может столкнуться с ограничениями, сканеру нужен будет доступ к базе с уязвимостями либо через интернет, либо базу потребуется развернуть локально. Кроме того, сканирование на хосте — дополнительная трата вычислительных ресурсов, особенно когда у вас 10+ тысяч хостов. Современные сканеры позволяют разделить этап сбора информации об установленных активах на системе (SBOM) и этап непосредственного сканирования. Такая схема дает больше гибкости, но вместе с этим возникают новые вызовы.

Актуальные задачи по направлению. Разработка универсального агента сбора SBOM с хостов. Агент позволяет собирать SBOM для разных типов источников активов, в том числе бинарных файлов. Полученные SBOM должны быть совместимы с SoTA-сканерами (osv-scanner, grype, trivy).