eBPF-сенсоры и 18-минутное окно атаки на Kubernetes

Любой платформенный лид, которому хоть раз приходилось поднимать свежий AKS-кластер в пятницу после обеда, знает это напряжение: вы ещё не дописали NetworkPolicy, а боты уже ломятся в дверь. Восемнадцать минут — таков медианный период до первого атакующего зонда на AKS-кластер, согласно отчёту Wiz. EKS получает чуть больше — 28 минут. Оба числа меньше, чем большинство процедур передачи дежурства.

Цифры

Восемнадцать минут — это слишком мало для того, что обычно делает человек. Недостаточно, чтобы нормально проверить план Terraform. Недостаточно, чтобы обсудить в Slack, стоит ли открывать дашборд. И уж точно недостаточно, чтобы запустился еженедельный скан уязвимостей, сформировал PDF и команда безопасности успела его разобрать.

Как сообщает CyberSecurityNews, окна в 18 минут для AKS и 28 минут для EKS взяты из собственного Kubernetes Security Report компании Wiz. Десятиминутная разница между двумя управляемыми сервисами почти наверняка является шумом от паттернов сканирования ботов, а не реальным защитным преимуществом EKS. Воспринимайте оба числа как одну и ту же проблему: ваш кластер попадает в список целей ещё до того, как CI-пайплайн завершит первый деплой.

Переведём это в операционные термины. Если у вас платформенная команда из 10 человек, и дежурный инженер ротируется через провижининг Kubernetes, вам нужно автоматизированное закалывание кластера прямо в bootstrap-процессе — человек просто не успеет среагировать быстрее бота. Это реальная бюджетная статья. В производственных инцидентах, которые я наблюдал в финтех-компаниях на управляемом Kubernetes, именно кластер из серии «закалим после демо» к понедельничному утру оказывался занят майнингом Monero.

Ещё одна цифра, заслуживающая внимания: хорошие runtime-инструменты работают с задержкой детектирования в секунды. Сравните это с 18-минутным окном атаки — математика очевидна. Вы не можете обогнать автоматизированных атакующих с помощью ревью, которое делают люди. Детектирование нужно сжать до того же порядка величин, что и автоматизация атакующих, — то есть до единиц секунд.

Kubernetes по умолчанию поставляется с широкими правами, открытыми дашбордами и сервисными аккаунтами с избыточным доступом. Именно эта комбинация в сочетании с публичным IP делает 18-минутные цифры воспроизводимыми, а не анекдотическими. Ботам не нужен zero-day, когда входная дверь не заперта.

Что действительно нового

eBPF сам по себе не новинка. Extended Berkeley Packet Filter встраивается в Linux-ядро уже много лет, и Falco, Tetragon и Cilium поставляют runtime-детектирование на его основе примерно столько же времени. Что изменилось — так это то, что лагерь «безагентной» защиты теперь включил eBPF в свои платформы, а не рассматривает его как конкурирующую категорию.

Wiz построил репутацию на сканировании облачных сред без деплоя агентов. Добавление Wiz Sensor в виде опционального агентного дополнения к Wiz Defend — это реальное архитектурное признание: вы не можете видеть эксплуатацию в памяти снаружи ноды. Статическое сканирование проверяет, что упаковано в образ контейнера, сверяя с известными CVE. Оно ничего не говорит о том, что фактически загружено в память после запуска контейнера. Уязвимый пакет, который никогда не импортируется, — теоретическая угроза. Безобидно выглядящий бинарник, используемый для бокового перемещения, — живая угроза.

Wiz Sensor валидирует уязвимости по тому, что загружено в память, а не просто по тому, что лежит на диске. Это действительно полезное инженерное утверждение, потому что оно сворачивает шумную очередь CVE, в которой тонет каждая команда безопасности. Половина того, что флагирует ваш SBOM-сканер, — это код, который никогда не выполняется. Подтверждение достижимости в runtime — вот как перестать платить двум инженерам за охоту на призрачные находки.

Ещё одна относительно новая составляющая: Wiz Runtime Sensor для Windows, выпущенный в июне, использует лёгкий kernel-модуль, который встраивается в Windows security API и пересылает данные активности в пользовательское пространство, где работает логика детектирования. Оба сенсора — Linux и Windows — отчитываются в одну платформу. Для тех, кто эксплуатирует гибридные кластеры (а их в корпоративных iGaming и legacy-финтехе больше, чем готовы признавать вендоры), единый телеметрический пайплайн — это настоящий дифференциатор, а не eBPF-брендинг.

Моё мнение: история здесь не в том, что «eBPF — это круто». eBPF был крутым ещё с 2018 года. История в том, что безагентные вендоры тихо признали необходимость агента для runtime, и теперь они гонятся, чтобы прикрутить его раньше, чем чистые runtime-инструменты съедят их выручку от расширения.

Что уже учтено командами безопасности

Если вы следили за безопасностью Kubernetes последние три года, большая часть этого уже есть в вашей модели угроз. Вы уже знаете, что конфигурации по умолчанию опасны. Вы уже знаете, что сервисные аккаунты имеют избыточные права, потому что узкие области ломают вещи, а ни у кого нет времени разбираться с RBAC во вторник. Вы уже знаете, что living-off-the-land бинарники — curl, bash и пакетные менеджеры — нельзя убрать сканированием, потому что ваше приложение их легитимно использует. Команды, с которыми я работал в платёжной инфраструктуре, уже годами сопоставляют это с техниками MITRE ATT&CK для контейнеров.

Чего ещё не учтено — и именно здесь я вижу, как команды попадают впросак, — это операционная стоимость самого eBPF-агента. eBPF специфичен для Linux. Он работает только на Linux-нодах. Это означает, что каждая Windows-нода, каждый управляемый сервис, абстрагирующий ноду, каждый бессерверный контейнерный runtime без доступа к ядру — это пробел в покрытии. Ваш дашборд будет показывать зелёный цвет, пока целые срезы вашего флота остаются без мониторинга.

Неудобная правда: большинство команд покупают runtime-детектирование, деплоят его на Linux worker pools, которые контролируют, и тихо игнорируют тот факт, что их Windows-ноды, Fargate-задачи и GKE Autopilot-воркнагрузки находятся за пределами охвата сенсора. Выпуск Windows-сенсора закрывает один из этих пробелов. Остальные остаются.

Альтернативная точка зрения

Вот аргумент, с которым я бы поспорил: что добавление eBPF-агента на каждую ноду — очевидно правильный ответ. Это совсем не очевидно. Агенты уровня ядра имеют историю вызова сбоев, которые превосходят по масштабу инциденты, которые они должны были предотвращать. Все, кто пережил одно июльское утро 2024 года, знают, что происходит, когда kernel-модуль ведёт себя неправильно в масштабе.

eBPF безопаснее сырого kernel-модуля, потому что работает в верифицированной песочнице, но «безопаснее» — не то же самое, что «безопасно». Каждый дополнительный хук в системные вызовы, выполнение процессов и сетевые пути — это CPU, который вы тратите на наблюдение, а не на обслуживание запросов. На высокопроизводительных нагрузках эти накладные расходы реальны, и я видел, как команды откатывали runtime-сенсоры после того, как бенчмаркинг показал измеримый налог на задержку на p99.

Альтернативная позиция: для многих нагрузок закалывание кластера на этапе провижининга (строгий RBAC, никаких публичных дашбордов, admission controllers, подпись образов) даёт больше безопасности за доллар, чем добавление runtime-сенсора поверх плохо сконфигурированного кластера. Runtime-детектирование добавляется после того, как основы сделаны, а не вместо них.

Ключевые выводы

• Окна атак в 18 минут для AKS и 28 минут для EKS означают, что закалывание кластера должно быть автоматизировано на этапе провижининга, а не проверяться людьми постфактум.
• Статическое сканирование образов не видит эксплуатацию в памяти и living-off-the-land злоупотребление curl, bash и пакетными менеджерами. Runtime-видимость — единственный способ их поймать.
• eBPF-сенсоры (Falco, Tetragon, Cilium, Wiz Sensor) закрывают пробел в Linux-runtime, но eBPF работает только на Linux. Windows-ноды требуют отдельного подхода на основе kernel-модуля.
• Валидация уязвимостей по тому, что загружено в память (а не по тому, что на диске), — самая полезная функция для сокращения шума в очереди CVE. Приоритизируйте инструменты, которые это делают.
• Прежде чем добавлять агент уровня ядра на каждую ноду, заблокируйте настройки по умолчанию, ужесточьте сервисные аккаунты и закройте открытые дашборды. Runtime-детектирование — это слой поверх правильной гигиены, а не её замена.