Уязвимости безопасности LLM‑платформ и риски инфраструктурных ошибок: простые дыры ломают быстрее сложных атак
Один открытый Docker Remote API на порту 2375 — и платформа под контролем за минуты. Это результат аудита, а не теория. Такой кейс ломает ожидание, что главные угрозы — «умные» атаки на модели. На практике решают базовые ошибки: открытые сервисы, дефолтные секреты, ключи в открытом виде и отсутствие сегментации.
Когда админ‑панель, прокси и аналитика живут в одной сети, одна настройка рушит весь стек — от LangChain до GPU‑нод на RunPods. Сложные техники вроде SSRF‑цепочек или prompt injection могут не сработать, а открытый порт даёт ключи сразу. Вывод практический: сначала проверяйте сеть и секреты, потом — защиту моделей. Далее — где именно возникают такие дыры и как их находить.
Почему фокус на «умных» атаках сбивает с курса
Принято считать, что главный риск — атаки на сами модели: prompt injection, сложные SSRF и уязвимости пайплайна. Поэтому команды усиливают фильтры промптов и детекторы атак.
Аудит показал обратное. За 14 дней найдено 27 уязвимостей. Критическая — открытый Docker Remote API на порту 2375 без аутентификации. Один HTTP‑запрос дал доступ ко всем API‑ключам, причём за 5 минут. Попытки добыть ключи через сложные техники результата не дали. Дефолтный JWT‑секрет позволял подделать admin‑токен.
Проблема в приоритетах. Простые конфигурации дают прямой путь ключам и данным. Если секреты лежат в базе в открытом виде, а сервисы делят одну сеть, защита на уровне LLM теряет смысл. Значит, сначала ищем базовые дыры, затем — усиливаем модели.
Как возникают быстрые компрометации
Как устроена платформа
LLM‑платформа — это сеть сервисов и секретов. Модель — по сути HTTP‑клиент с дорогими ключами. В продакшене рядом: LangChain, Flask‑сервисы, фронтенд на Next.js, контейнеры в Docker Swarm. Часто админ‑панель, прокси и аналитика в одной зоне. Одна ошибка даёт прямой канал ключам.
Причина и механизм
Открытый Docker API на 2375 без аутентификации — прямой вход. Один запрос — и видны контейнеры и смонтированные секреты. Доступ ключам получен за 5 минут. Дефолтный JWT даёт подделку admin‑токена и доступ к данным. При этом prompt injection, SSRF‑цепочки и HTTP smuggling не помогли. Цепочка проста: неверная конфигурация → доступ к секретам → контроль над LLM.
Практики, которые закрывают вектор
Закрыть Docker API: отключить 2375, включить TLS и сокет unix (/var/run/docker.sock), доступ только через bastion/VPN и списки разрешённых IP.
Секреты вне кода и БД: использовать хранилища секретов (например, HashiCorp Vault, AWS Secrets Manager), включить ротацию и короткий TTL.
Сегментация сети: разнести админ‑панель, прокси и аналитику по разным подсетям и политикам, минимальные права по принципу least privilege.
Egress‑фильтрация: разрешать исходящие соединения только к нужным адресам; блокировать произвольные хосты, чтобы SSRF не работал.
К чему это приводит
Если ключи лежат в базе в открытом виде, а DMARC стоит p=none, риски складываются: фишинг снаружи + дыра внутри = полный компромисс. В системе было >10 LLM‑нод и GPU‑нод на RunPods, значит масштаб утечки велик. Защита промптов здесь не помогает — атака идёт ключам.
Вывод
Без дисциплины в инфраструктуре защита LLM — косметика. Закрываете простые дыры — резко сокращаете реальный риск.
Типовые сценарии и как их закрыть
Открытый Docker «для удобства»
Контейнеры настроили быстро и дали доступ по внутреннему IP. Порт 2375 оказался доступен. Один HTTP‑запрос — и видны контейнеры и секреты. Итог: ключи получены за минуты, дальше — компрометация нод и платежей. Как предотвратить:
закрыть 2375, включить TLS и доступ только через VPN;
ограничить доступ списками IP и ролями.
Дефолтный секрет в продакшене
JWT‑секрет не сменили после теста. Токен подделали и получили админ‑доступ. Итог: контроль над кластером и данными, возможна подмена ответов. Как предотвратить:
хранить секреты в Vault/Secrets Manager и ротировать;
запретить дефолтные значения в CI, проверка на деплое.
Всё на одном хосте
Фронт, прокси и аналитика на одном сервере. Утечка в одном сервисе дала доступ к другим. Итог: доступ к >10 LLM‑нодам и GPU‑ресурсам, быстрый рост ущерба. Как предотвратить:
сегментировать сеть и разнести сервисы по зонам;
включить egress‑политики и минимальные права доступа.
Metric | Value | Source |
|---|---|---|
Audit duration | 14 days | За 14 дней аудита обнаружено 27 уязвимостей |
Number of vulnerabilities found | 27 | За 14 дней аудита обнаружено 27 уязвимостей |
Time to obtain API keys | 5 minutes | Доступ ключам был получен за 5 минут после обращения к открытому порту |
Open Docker Remote API port | 2375 | Критическая уязвимость — открытый Docker Remote API на порту 2375 без аутентификации |
LLM and GPU nodes in cluster | >10 LLM‑нод / GPU‑ноды на RunPods | Система включала более 10 LLM-нод и GPU-ноды на RunPods |
API keys storage | Plain text in database | API-ключи хранились в открытом виде в базе данных |
DMARC policy | p=none | DMARC настроен как p=none, что не защищает от email-спуфинга |
Бизнес‑эффект: где теряются деньги и время
Инфраструктурные дыры сокращают атаку до прямого доступа ключам. Это значит быстрые и дорогие инциденты.
Что это даёт на практике:
простой сервисов и простой команды из‑за компрометации;
прямые расходы: утекшие API‑ключи оплачивают чужие запросы;
утечка данных пользователей и репутационные потери;
масштабирование ущерба на все ноды (>10 LLM и GPU).
Инвестиции в фильтры промптов не покрывают эти риски. Пока сеть не разделена и секреты не управляются централизованно, точка входа остаётся короткой.
Вывод: перенос фокуса на сеть и секреты снижает вероятность крупных инцидентов быстрее, чем усложнение защиты моделей.
Что делать в первую очередь
Проблема не в «магических» атаках. За 14 дней нашли 27 уязвимостей, и одна настройка — открытый Docker API на 2375 — дала ключи за 5 минут. Дефолтный JWT и ключи в открытом виде обнуляют защиту на уровне моделей.
Приоритеты действий:
закрыть 2375, включить TLS и доступ через VPN/списки IP;
убрать хранение секретов в открытом виде, перейти на Vault/Secrets Manager и ротацию;
сегментировать сеть: разнести админ‑панель, прокси и аналитику, ввести least privilege;
включить egress‑фильтрацию и DMARC с режимом enforcement.
Почему это работает: закрываете короткие пути ключам — атака становится сложнее и заметнее. Риск падает.
Финальный вывод: защищать LLM нужно снизу вверх. Без инфраструктурной дисциплины остальные меры мало что меняют.
