Зеркало для облака: как мы научили OVN отдавать трафик виртуальных машин для NTA/NDR

До нас ни одно российское публичное облако не поддерживало зеркалирование трафика виртуальных машин. Это означало одно: NTA/NDR‑системы, в частности, PT Network Attack Discovery (PT NAD) от Positive Technologies в отечественных облаках нормально не разворачивались. Не потому что продукт этого не поддерживает. Просто облако не могло дать ему главное — копию сетевого трафика с интерфейсов ВМ.

Мы решили эту проблему. Реализовали зеркалирование трафика в overlay‑сети на базе OVN, отправили патч в апстрим — и он был принят. Теперь это часть основной кодовой базы проекта.

Привет, Хабр! Меня зовут Влад Одинцов, я Product Owner сетевых сервисов K2 Cloud. В этой статье подробно расскажу, как устроено облачное зеркалирование под капотом, почему без фильтров трафика сложно жить и что показало нагрузочное тестирование, которое мы проводили совместно с Positive Technologies.

Почему облачная безопасность — это не опция

Рынок облачных сервисов растет примерно на 21% в год и к 2029 году достигнет около 801 млрд рублей. Бизнес идет в облако, и вместе с ним туда идут злоумышленники.

Атакующие используют классические векторы (фишинг, эксплуатацию уязвимостей) и специфику облачной среды: компрометацию identity‑провайдеров, атаки на Kubernetes и контейнерные инфраструктуры. Облачную защиту выстраивают в двух измерениях: превентивное (identity‑провайдеры, zero trust, MFA, управление уязвимостями) и детектирование с реагированием на инциденты. С последним была серьезная проблема.

Виктор Еременко, лидер продуктовой практики PT NAD в Positive Technologies на одном из наших совместных эфиров сказал фразу, которая хорошо описывает ситуацию: «До недавнего времени среди отечественных облаков не было ни одного, которое бы умело зеркалировать трафик». Не «мало кто умел» — именно ни одного. Видимости сетевого трафика в российских публичных облаках попросту не было, а значит, детектировать угрозы на сетевом уровне было нечем.

Зачем NTA/NDR‑системе нужен трафик 

На примере PT NAD расскажу, как мы тестировали и отлаживали зеркалирование. Но то же самое верно для любой NTA/NDR‑системы, так как всем им для работы нужна копия сетевого трафика. PT Network Attack Discovery — система поведенческого анализа трафика от Positive Technologies, относится к классу NTA/NDR. Она анализирует копию сетевого трафика и выявляет следы присутствия злоумышленников, обеспечивая возможность автоматизированного сдерживания угроз. Работает тремя классами методов.

Классические методы работают в реальном времени на живой сессии. Это сигнатурный анализ, проверка индикаторов компрометации (IoC) и интеграция с PT Sandbox: файлы извлекаются из потока трафика и отправляются в песочницу на лету. Глубокая экспертиза ловит сложные многошаговые атаки, где отдельные сессии не связаны между собой, но артефакты злоумышленника есть в каждой. Сюда же входит обнаружение новых активов и инвентаризация сервисов. Машинное обучение отвечает за поведенческий анализ и обнаружение аномалий.

Всё это работает только при одном условии — на сенсор должна поступать исходная копия сетевого трафика, без него PT NAD не функционирует.

Почему зеркалирования не было и что мы сделали

В физической инфраструктуре задача решается через SPAN‑порт на коммутаторе или TAP‑устройство. В облаке у вас нет доступа к физическому сетевому оборудованию провайдера, и просто перенести эту схему нельзя.

Причина не в том, что зеркалирования не было вообще, а в том, что оно не подходило для облака. В OVN уже была нативная поддержка нескольких типов зеркалирования — Local (SPAN), ERSPAN и GRE, но все они работали только на уровне физических портов гипервизора, то есть с underlay‑сетью. Мы же в K2 Cloud строим виртуальные сети на базе OVN (Open Virtual Network) — open source SDN‑решения, в развитии которого активно участвуем. И нам нужно было зеркалировать трафик виртуальных портов ВМ в overlay‑сети, а такой функциональности не было. 

Мы реализовали ее с нуля, отправили патч в апстрим OVN, и в прошлом году его приняли. Теперь это часть основной кодовой базы проекта.

Как устроено зеркалирование в K2 Cloud

Зеркалирование — это копирование сетевого трафика виртуальных машин на порт ВМ‑сенсора, в нашем случае PT NAD. Работает похоже на SPAN‑порт, но с важным отличием: функционирует в рамках любых сетей проекта, включая разные VPC. Зеркалируется тот же трафик, который вы видели бы внутри ВМ при запуске tcpdump.

Для управления зеркалированием есть три ресурса. Источник — это сетевой интерфейс отслеживаемой ВМ, именно на нем мы подписываемся на трафик. Приемник — интерфейс ВМ с PT NAD, куда уходит копия. Сессия зеркалирования связывает источник с приемником: без нее трафик никуда не пойдет. К каждой сессии опционально добавляется фильтр — о фильтрах расскажу отдельно, потому что именно тут прячутся основные нюансы

Есть одно ограничение, о котором важно помнить при проектировании инфраструктуры: зеркалирование работает внутри одной зоны доступности. Если ВМ распределены по нескольким AZ, в каждой зоне потребуется свой сенсор PT NAD.

Что происходит с пакетом

Пакет приходит из внешнего мира, проходит через Load Balancer (если настроен) и через облачный Firewall, и только после этого попадает на функцию зеркалирования. Там он клонируется: оригинал уходит на целевую ВМ, копия на PT NAD. Для исходящего трафика обратная ситуация: ВМ отправляет пакет, он сразу клонируется, копия уходит на PT NAD, оригинал идет через Firewall и так далее.

Фильтры зеркалирования — самая важная часть

Когда мы начали тестировать, сразу столкнулись с несколькими проблемами. Без фильтров зеркалирование работает, но создаёт лишний трафик и может испортить анализ. Расскажу на конкретных примерах.

1. Проблема дублей

Представьте, что ВМ1 и ВМ2 общаются между собой, и мы зеркалируем и входящий, и исходящий трафик с обеих машин. В результате один пакет приходит на PT NAD дважды: первый раз как исходящий от ВМ1, второй раз как входящий на ВМ2. PT NAD такие дубли умеет разбирать корректно, но зачем гонять двойной объем трафика по сети и создавать лишнюю нагрузку на сенсор? При большом числе ВМ это становится реальной проблемой.

2. Проблема односторонних сессий

Обратная крайность — зеркалировать только входящий трафик. Тогда пакеты, которые ВМ отправляет в интернет, вообще не попадут на PT NAD. В интерфейсе это выглядит как асинхронные сессии: видно, что что‑то происходит, но половина картины отсутствует. Для расследования инцидента этого недостаточно.

3. Проблема тяжелого трафика (Elephant Flow)

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

Что такое фильтр и как он работает

Фильтры зеркалирования — это наборы правил match/action, похожих на пакетный фильтр. Ключевая деталь: они применяются к клонированному пакету и никак не влияют на оригинальный трафик между ВМ. Фильтры решают три задачи: устраняют дубли, снижают нагрузку на сенсор, позволяют распределять трафик между несколькими анализаторами.

Пример: весь трафик VPC без дублей

Для сценария «весь трафик VPC без дублей» логика такая. Во входящих правилах мы отбрасываем трафик от других ВМ внутри VPC — он уже попадет на PT NAD как исходящий с машины‑отправителя, дублировать его нет смысла. Трафик из интернета пропускаем. Весь исходящий зеркалируем полностью.

Нюанс со шлюзом по умолчанию

Это не очевидно и вылезло у нас в первых же тестах. В облачных средах шлюз по умолчанию не просто маршрутизатор — он еще предоставляет DNS и DHCP. Если в исходящих правилах исключить трафик до IP‑адреса шлюза, DNS и DHCP‑запросы выпадут из зеркалирования, и сессии в PT NAD станут неполными. Правильная логика: явно разрешить трафик до шлюза, затем отбросить дублирующий внутренний трафик VPC, остальное пропустить.

Дополнительные сценарии с фильтрами

Помимо устранения дублей, фильтры позволяют снижать нагрузку на сенсор. Например, трафик бэкапов между конкретными IP по конкретному порту легитимен и не нужен для расследований, его можно исключить из зеркалирования. Это дает экономию и на сетевой полосе, и на ресурсах PT NAD. Еще один сценарий — распределение трафика по нескольким анализаторам: HTTP/HTTPS (80/443) направить на один сенсор, весь остальной трафик на другой. Удобно, когда за разные зоны отвечают разные команды.

Управление

Все ресурсы — источники, приемники, сессии и фильтры — управляются стандартными для K2 Cloud способами. В веб‑консоли появился новый раздел «Зеркалирование трафика» с полным управлением всеми объектами. С помощью API всё работает через Amazon EC2-совместимый интерфейс, поэтому любой AWS‑совместимый тулинг подходит при правильно указанных API endpoints. Для тех, кто строит инфраструктуру через код, есть поддержка в Terraform Provider — сессии, приемники и фильтры управляются декларативно.

Нагрузочное тестирование

Нагрузочное тестирование проводил архитектор PT NAD со стороны Positive Technologies. Стенд: клиент плюс два сервера, три сессии зеркалирования по одной на каждый интерфейс ВМ, приемник PT NAD. Сознательно выбрали HTTP как один из наиболее ресурсоемких типов трафика.

Официальные ТТХ PT NAD — 2 Гбит/с. Мы тестировали выше этой планки, и потери пакетов при этом были минимальными. Если нужна большая пропускная способность, это решается через настройку multiqueue для сетевого интерфейса сенсора — поддержка K2 Cloud поможет с конфигурацией.

Несколько практических замечаний

Есть вещи, которые не очевидны из документации и вылезают только в реальном развёртывании. Первое — IP на интерфейсе захвата. DPDK, на котором работает PT NAD, забирает сетевой интерфейс полностью под себя, из‑под контроля ОС, а вместе с ним и IP‑адрес, если он на этом интерфейсе висит. Отсюда и требование: на интерфейсе захвата не должно быть IP. Логика простая — если через этот интерфейс подключался админ, а DPDK его заберёт, админ обрубит доступ сам себе.

В облаке IP на интерфейсах назначается автоматически, как раз для того чтобы админ случайно не остался без доступа. Но для PT NAD это работает в минус: автоматически назначенный IP надо убрать. Для этого нужно удалить пакет c2-ec2-netutils (sudo apt remove c2-ec2-netutils) и вручную подправить конфигурацию портов захвата, иначе ptdpi не запустится.

Второе — IOPS. По умолчанию IOPS диска ограничен и растет с объемом трафика. PT NAD пишет достаточно активно, особенно при хранении сырого трафика. Если замечаете деградацию производительности — это первое, что стоит проверить. Решается через поддержку K2 Cloud.

Третье — несколько инстансов PT NAD. Центральная консоль позволяет смотреть трафик из нескольких инсталляций в одном месте, и предоставляется бесплатно. Актуально как раз для сценария с несколькими AZ.

Итого

Раньше задача «полноценный NTA/NDR‑мониторинг в российском публичном облаке» либо решалась сложными обходными схемами, либо не решалась совсем. Теперь это стандартная конфигурация. PT NAD разворачивается в облаке так же, как в физической инфраструктуре. На момент публикации функция зеркалирования доступна во всех регионах присутствия К2 Облака. 

Что нужно помнить при развертывании:

1. Зеркалирование работает внутри одной AZ. При multi‑AZ нужен сенсор в каждой зоне

2. Без фильтров будут дубли трафика — это увеличивает нагрузку и мешает анализу

3. Шлюз по умолчанию работает как DNS/DHCP‑сервер, его трафик нужно явно разрешить в фильтрах

4. IP с интерфейса захвата нужно убрать, иначе ptdpi не стартует

5. За IOPS нужно следить на высоких нагрузках

6. Официальные ТТХ PT NAD — 2 Гбит/с, расширяется через multiqueue с поддержкой K2 Cloud

Если разворачивали PT NAD в облаке или сталкивались с похожими задачами — пишите в комментариях.