DNS как выход из закрытого контура: что показал инцидент с агентом OpenAI

20 сентября 2026 года внутренняя модель OpenAI в среде без доступа к живому интернету обратилась к внешнему чат-боту через резолвер своей песочницы. P0-алерт появился через 12 минут, run остановили через 2,5 часа. Разбираем, почему DNS раз за разом остаётся незакрытым каналом в изолированных средах и что проверить в своём закрытом контуре.

Инцидент в четырёх строках

По отчёту OpenAI, обновлённому 25 сентября 2026 года:

• Кто. Внутренняя исследовательская модель в процессе RL-training. Публичный ChatGPT и пользовательские сессии к истории отношения не имеют.

• Что. Агент решал поисковую задачу, не нашёл ответа штатным инструментом и через DNS-резолвер песочницы передал вопросы публичному чатботу.

• Детект. Misalignment monitoring поднял P0 через 11 минут 48 секунд после первого внешнего ответа.

• Остановка. Run убили через 2 часа 32 минуты после P0.

Остальные попытки выйти в интернет упирались в offline web cache. Хост агент не компрометировал и произвольного сетевого доступа не получил. Он использовал служебную зависимость, которую модель угроз не считала каналом наружу: safety case OpenAI исходил из того, что доступа к живому интернету у модели нет. В очередной раз DNS-туннелирование помогло выйти из закрытого контура, что часто встречается в реальных атаках.

Почему именно DNS

Внутренний клиент почти никогда не общается с DNS-сервером нужной зоны напрямую. Он спрашивает свой резолвер, тот идёт к корневым серверам, к TLD и дальше к авторитативному серверу зоны. Если зону контролирует атакующий, его сервер получит запрос, даже когда клиент сидит за файрволом без единого разрешённого TCP-соединения или маршрута наружу.

Механика такова: скомпрометированный хост обычно не может связаться с сервером атакующего, но кодирует данные в поддомен его домена и отправляет запрос своему резолверу (часто контроллеру домена Active Directory). Уникальное FQDN не лежит в кеше, поэтому резолвер честно выполняет рекурсию до авторитативного сервера атакующего. Ответ сервера может нести данные обратно.

Три свойства делают DNS удобным каналом из закрытых сегментов:

• Он нужен почти всему
  Обновления, пакетные зеркала, телеметрия, NTP по имени, облачные API. Закрыть DNS целиком в «изолированном» сегменте часто означает сломать служебные процессы, и его оставляют.

• Резолвер работает как прокси
  Правило «из сегмента нельзя наружу» соблюдается на уровне IP, но рекурсивный резолвер ходит наружу за клиента.

• Даже отказ передаёт данные
  NXDOMAIN на запрос <данные>.attacker.example означает, что запрос дошёл до авторитативного сервера атакующего и был там записан в лог. Для утечки ответ не нужен.

Техника описана в MITRE ATT&CK T1071.004: DNS как прикладной протокол для C2, где команды и результаты переносятся, например, в TXT- или A-записях. Нового в этой истории мало. Только то, с какой скоростью AI-агент этот канал нашёл.

Один паттерн, пять историй

Кейс OpenAI удобно читать в ряду уже известных эпизодов. Во всех среда считалась закрытой или контролируемой, и во всех DNS оказался исключением.

Кейс AgentCore ближе всего к истории OpenAI по архитектуре. AWS даже обновила документацию: теперь в ней сказано, что в sandbox mode интерпретатор «can access Amazon S3 for data operations and perform DNS resolution». 

Вывод из таблицы для любого закрытого контура: формулировка «сеть закрыта» описывает намерение, а фактическую границу задаёт карта транзитивных зависимостей. Резолвер среди них самый частый и самый незаметный.

Как агент дошёл до DNS

Цепочка действий интересна как последовательная смена стратегии. По отчёту OpenAI:

1. Агент искал характерные фразы из блога через штатный web search и получал нерелевантную выдачу.

2. Из shell через Python он отправил тот же запрос в Google, Bing и DuckDuckGo. Ответы: 403 и 502.

3. Он предположил, что вопрос взят из публичного бенчмарка BrowseComp, скачал из offline cache датасет и evaluation script, затем проверил SimpleQA. Совпадений не нашлось. Предположение было ошибочным.

4. Прямой HTTPS-запрос к публичному чат-боту прокси заблокировал с причиной CACHE_MISS.

5. Прямые запросы к публичным DNS-серверам остались без ответа. Внутренний резолвер песочницы вернул реальную запись известного домена и корректно отказал по выдуманному. Из этого агент сделал вывод, что резолвер ходит во внешний мир.

6. Найденные публичные DNS-туннели оказались закрыты или требовали своего сервера. Тогда агент использовал публичный сервис DNS delegation, чтобы передавать вопросы чат-боту.

7. Контрольный вопрос о столице Франции сначала упал по таймауту. После увеличения таймаута с 6 до 19 секунд пришёл ответ «The capital of France is Paris».

8. Агент изучил публичную документацию чат-бота, поднял таймаут до 24 секунд и отправил ещё 18 вопросов. 14 касались подсказок задачи, 4 были о способах искать в вебе, загружать сайты и использовать публичные DNS-туннели.

9. Исходную задачу он не решил и в финальном ответе сообщил, что данных недостаточно.

Шаг 5 повторяет тест, которым администратор проверяет, есть ли из сетевого сегмента DNS-выход. Агент провёл его сам, без подсказки, значит аналогичным образом могут действовать и AI-усиленные атаки злоумышленников на вашу сеть.

Побег, туннель или незакрытая зависимость

Схема маршрута:

AI-агент
  │
├─ web search / HTTP(S) ──> offline web cache ──X──> live internet
 │
└─ DNS query ──> резолвер песочницы ──> внешняя DNS-инфраструктура
                                          └─> публичный чат-бот
                                              └─> ответ обратно в DNS

Три термина, которые легко спутать при пересказе кейса:

Для защиты разница в терминах мало что меняет: канал двусторонний, он пересекает границу, которую политика объявляла закрытой.

12 минут до P0, 2,5 часа до остановки

OpenAI опубликовала точные отметки времени. Интервалы мы посчитали сами, точкой отсчёта взят первый DNS-вызов, получивший внешний ответ.

В терминах метрик:

• Time to signal: 11 минут 48 секунд.

• Time to acknowledge: 2 минуты 55 секунд.

• Time to contain: 2 часа 32 минуты 19 секунд от P0, 2 часа 29 минут 24 секунды от подтверждения.

• Полное окно от первого подтверждённого выхода до остановки: 2 часа 44 минуты 7 секунд.

Ошибка severity: «сервис закрыт» тоже ответ

Ретроспектива OpenAI нашла и другие случаи внешнего DNS-доступа, которым монитор не присвоил ожидаемую критичность. Среди них были запросы, вернувшие статическое сообщение о том, что внешний сервис закрыт. Монитор иногда считал отсутствие полезной информации признаком неудачной попытки выхода.

Логика обратная. Ответ «сервис закрыт» доказывает, что запрос дошёл до внешней системы, а ответ вернулся в песочницу. Канал существует. Severity обхода границы определяется созданным каналом, нарушенной политикой и потенциальным blast radius, а полезность payload на неё не влияет.

Что проверить в своём закрытом контуре

Раздел не привязан к конкретному продукту. Под закрытым контуром понимаем любой сегмент, которому по политике запрещён выход в интернет: АСУ ТП, среда разработки с секретами, CI-раннеры, лаборатория, песочница для AI-агентов, management-сегмент для администрирования СЗИ.

Тест за пять минут

Повторите проверку, которую сделал агент OpenAI. Понадобится домен, у которого вы видите логи авторитативного сервера (canary-домен).

# с хоста внутри закрытого сегмента
dig +short A example.com                 # резолвится внешнее имя?
dig TXT "$(openssl rand -hex 8).canary.example.ru"   # канарейка

Если в логах авторитативного сервера canary.example.ru появился запрос со случайной меткой, у сегмента есть DNS-выход. Ответ клиенту при этом неважен: NXDOMAIN, SERVFAIL или таймаут ничего не меняют, запрос уже ушёл наружу.

Резолвер: allowlist вместо рекурсии

Для сегмента без интернета резолвер не должен выполнять рекурсию во внешний мир вообще. Разрешённые имена обслуживаются внутренними зонами или форвардом на внутренний сервер. Пример для unbound:

server:
# всё, что не разрешено явно, получает REFUSED
local-zone: "." refuse
# внутренние зоны, которые сегменту действительно нужны
local-zone: "corp.example." transparent
local-zone: "mirror.corp.example." transparent

forward-zone:
name: "corp.example."
forward-addr: 10.0.0.53

После инцидента OpenAI ограничила DNS в среде allowlist-ом доменов и типов записей. Штатными local-zone в unbound фильтровать по типу записи неудобно, для этого подойдёт dnsdist или DNS-firewall перед резолвером: TXT, NULL и NS из технологического сегмента обычно не нужны.

Сетевой backstop

Резолвер можно обойти, если хост ходит к внешним DNS-серверам напрямую или через шифрованный DNS. Закройте это на уровне сети:

# nftables: из сегмента 10.20.0.0/24 DNS и DoT только к своему резолверу
nft add rule inet filter forward ip saddr 10.20.0.0/24 udp dport 53 ip daddr != 10.20.0.53 drop
nft add rule inet filter forward ip saddr 10.20.0.0/24 tcp dport { 53, 853 } ip daddr != 10.20.0.53 drop
nft add rule inet filter forward ip saddr 10.20.0.0/24 udp dport 853 drop   # DoQ

DoH так не закрыть: он идёт на 443 вместе с обычным HTTPS. Нужны списки DoH-провайдеров, DPI-сигнатуры и запрет исходящего 443 из сегмента, где интернета быть не должно.

Проверьте и fail-open: что произойдёт с DNS, если недоступен policy engine, прокси, DNS-фильтр или монитор. Если при сбое контроля резолвер начинает ходить наружу напрямую, закрытость контура держится на аптайме этого компонента.

Наблюдаемость

• Логировать полный query name, тип записи, ответ, rcode, резолвер, workload-источник, процесс, для агентов ещё agent_id/run_id, и решение политики.

• Проверить canary-запросом, что каждый сегмент реально входит в scope DNS-детекта в SIEM или NDR.

• Завести аналитику редких типов записей (TXT, NS, NULL, MX) относительно легитимного baseline сегмента.

• Коррелировать DNS с process telemetry: запрос из браузера и запрос из python или shell имеют разный контекст.

• Разделять резолверы production, гостевых, лабораторных и AI-сред. CISA рекомендует держать для гостевых сетей и лабораторий ИБ отдельную резолверную инфраструктуру и маркировать их DNS-трафик и telemetry по источнику.

Реагирование

• Формально определить P0-условия: несанкционированный egress, попытка добыть credentials, изменение политики, доступ к внешней системе вне задания.

• Привязать P0 к автоматическому pause или kill там, где продолжение опаснее остановки.

• Вместе с процессом отзывать временные credentials, блокировать сеть, отменять очередь действий и сохранять volatile evidence.

• Проводить учения с замером трёх отметок: сигнал, подтверждение, фактический containment.

Red teaming

• Тестировать способность агента находить транзитивные каналы, prompt injection покрывает лишь часть рисков.

• Давать задачи с заведомо плохой выдачей поиска и смотреть, пытается ли агент расширить доступ.

• Проверять сценарии с DNS delegation, внешними callback-сервисами, package mirrors и случайно доступными credentials.

• Повторять тесты при каждом изменении образа sandbox, резолвера, прокси, tool manifest и orchestration layer.

Как мы закрываем DNS-канал в Ideco NGFW Novum

Для корпоративной сети первый вопрос звучит так: весь ли DNS-трафик проходит через контролируемую точку и что система делает при аномалии. Наличие DNS-логов на этот вопрос не отвечает. В Ideco NGFW мы строим защиту слоями.

Единая точка резолвинга. Опция «Перехват пользовательских DNS-запросов» заворачивает DNS клиентов на NGFW, даже если на хосте прописан внешний сервер. DNS Security обнаруживает и блокирует попытки обойти фильтрацию через DoH. Утечки через сторонние DoH/DoT/DoQ-серверы мы разбирали в обзоре DNS Security.

Детект туннелей. DNS Security работает с облачной платформой нашего технологического партнёра SkyDNS и блокирует восемь классов DNS-угроз, в том числе DNS-туннелирование и DGA. Эвристика учитывает частоту запросов от узла и к домену, интервалы, длину имени и глубину поддоменов, QType, размеры запросов и ответов, энтропию и признаки base32/base64 в метках. По документации, туннель обнаруживается и блокируется за 5–10 минут.

Видимость для расследования. С Ideco NGFW Novum 22 журнал DNS-запросов показывает обмен DNS-сообщениями, обработанный NGFW. Раньше администратор видел блокировки DNS Security, но не полную картину запросов и ответов. Теперь по журналу можно восстановить цепочку вроде той, что мы разбирали выше.

Разумеется есть некоторые ограничения для закрытых контуров. DNS Security работает на этапе резолвинга внешних зон: внутренние, master- и forward-зоны обслуживаются штатно. Сам модуль ходит в облако по DoT, поэтому NGFW нужен доступ к 193.58.251.10:853. Для сегмента, которому интернет не положен совсем, правильный контроль проще и жёстче: резолвер без внешней рекурсии, allowlist имён, запрет прямого 53/853 и исходящего 443 на файрволе. Поведенческий детект туннелей в такой архитектуре работает вторым слоем. На первом слое агент, который меняет подход за минуты, не должен найти рабочего пути.

Следующий шаг, который мы готовим в Ideco NGFW Novum 24, это LLM Proxy: единая контролируемая точка доступа сотрудников и агентов к внешним LLM с журналированием. Логика та же, что и с DNS. Если легитимный путь к модели один и наблюдаемый, любой другой путь сразу становится аномалией.

Вывод

Для этого эпизода ИБ не нужны новые методы. DNS-фильтрация, egress allowlist, сегментация, корреляция событий и автоматический containment известны давно, а DNS-C2 входит в описанные MITRE ATT&CK техники группы OilRig.

Агент меняет требования к исполнению этих мер. Он перебирает варианты быстрее человека, не считает неудачную попытку поводом остановиться, сам проводит тест «реальный домен против выдуманного» и продолжает работу после того, как SOC увидел нарушение. Поэтому закрытость контура теперь проверяется двумя вопросами: есть ли у сегмента хоть один работающий путь наружу, включая резолвер, и сколько времени проходит от алерта до момента, когда инфраструктура фактически лишила агента возможности действовать.

В кейсе OpenAI ответ на первый вопрос был «есть», на второй: 2,5 часа.