Утро вторника началось не с кофе, а с SMS от банка о попытке списания средств и серии алертов от биллинговой системы. Открыв дашборд провайдера LLM, я увидел график потребления токенов, устремившийся вертикально вверх. За одну ночь ничем не примечательный эндпоинт нашего нового AI-ассистента сжег тысячу долларов.
Первая мысль — мы стали виральными, продукт выстрелил. Вторая мысль, пришедшая после беглого взгляда на логи Nginx — нас просто парсят. Кто-то нашел открытую ручку, генерирующую качественный текст, и подключил к ней свою ферму ботов для генерации дорвеев или спам-статей.
До появления генеративных моделей DDoS-атака или парсинг били исключительно по инфраструктуре: ложились базы данных, забивался сетевой канал, росли счета за трафик от облачного провайдера. Это было неприятно, но предсказуемо и масштабируемо. Сейчас каждый HTTP-запрос к вашему API транслируется в прямой вызов тяжелой языковой модели. Спамеры больше не просто нагружают серверы — они напрямую выкачивают деньги с привязанной корпоративной карты. Каждый сгенерированный токен имеет конкретную, осязаемую цену.
Анатомия атаки на AI-эндпоинт
Механика эксплуатации выглядит тривиально. Разработчики часто оставляют базовые функции доступными без регистрации, чтобы снизить порог входа для новых пользователей и улучшить конверсию. Фронтенд заботливо скрывает кнопку отправки после трех сообщений, предлагая авторизоваться. Но злоумышленники не используют браузер. Они отправляют POST-запросы напрямую в API.
Когда мы начали разбирать инцидент, паттерн оказался классическим. Атакующие использовали пул резидентных прокси, постоянно меняя IP-адреса. Запросы шли с нормальными заголовками User-Agent, имитирующими популярные десктопные и мобильные браузеры. Никаких аномальных всплесков с одного адреса — ровный, размазанный по сотням IP-адресов поток запросов. Каждый такой запрос содержал специфичный промпт, заставлявший модель генерировать максимально длинные ответы.
Проблема усугублялась тем, что биллинг большинства провайдеров LLM работает с задержкой. Вы не видите расходы в реальном времени. К моменту, когда провайдер агрегирует данные и обновляет дашборд, ваш бюджет уже уничтожен. Наш внутренний мониторинг отслеживал только время ответа (latency) и количество 500-х ошибок. Ошибок не было — наш бэкенд работал идеально, послушно генерируя текст для спамеров за наш счет.
Первый рубеж обороны: Архитектура Rate Limiting
Защита AI-продукта требует изменения инженерного мышления. Вы должны относиться к каждому эндпоинту, вызывающему LLM, как к шлюзу для прямого перевода денег.
Первый рубеж обороны — жесткое ограничение частоты запросов (Rate Limiting). Но стандартного ограничения по IP-адресу больше недостаточно. Протокол IPv6 дает атакующим практически бесконечный пул адресов (/64 подсети), а дешевые прокси-сети позволяют менять IPv4 с каждым новым HTTP-запросом.
Правильная архитектура Rate Limiting для AI-приложений строится на нескольких уровнях. На сетевом уровне (L7 балансировщик или WAF) мы отсекаем очевидный мусор: запросы без правильных заголовков, известные пулы дата-центров (если продукт ориентирован на обычных пользователей), аномальные паттерны TLS-отпечатков (JA3).
На уровне приложения необходимо внедрять алгоритмы Token Bucket или Sliding Window Log, используя Redis в качестве быстрого хранилища состояния. Но ключом для лимитирования должен выступать не только IP-адрес. Если эндпоинт публичный, необходимо внедрять обязательный фингерпринтинг устройства (Device Fingerprinting) и связывать лимиты с ним. Для авторизованных пользователей лимиты привязываются к ID аккаунта, но с дополнительной гранулярностью: мы ограничиваем не только количество запросов в минуту (RPM - Requests Per Minute), но и количество потребляемых токенов в минуту (TPM - Tokens Per Minute). Злоумышленник может отправить всего один запрос, но с огромным контекстом, заставив модель выдать максимальный ответ — это сожжет бюджет так же быстро, как и тысяча мелких запросов.
Второй рубеж: Защита эндпоинтов и валидация
Второй рубеж — защита самих эндпоинтов. Практика показала, что оставлять генеративные функции полностью открытыми — непозволительная роскошь. Даже для демонстрационных режимов необходимо внедрять невидимые капчи (например, Cloudflare Turnstile или reCAPTCHA v3), которые анализируют поведение пользователя до отправки запроса на бэкенд.
Более надежный подход — требовать хотя бы минимальной аутентификации (например, через OAuth Google или GitHub) даже для триального использования. Это позволяет привязать расходы к конкретной личности и моментально блокировать аккаунты при подозрительной активности.
Кроме того, необходимо жестко валидировать входящие данные. Ограничение максимальной длины промпта (max_length) на бэкенде — базовое требование. Если ваш сервис предполагает короткие вопросы, нет причин принимать от клиента массивы текста на 100 килобайт. То же самое касается параметров генерации: всегда устанавливайте разумный параметр max_tokens для ответов модели, чтобы предотвратить бесконечную генерацию текста.
Инфраструктурное решение: Интеграция RouterAPI
Строить всю эту защитную инфраструктуру с нуля — дорого и долго. Разработка надежного биллинга, системы лимитов, подсчета токенов и мониторинга отнимает инженерные ресурсы от создания самого продукта. Именно этот болезненный опыт привел нас к использованию специализированных решений.
Интеграция RouterAPI закрыла большинство описанных уязвимостей "из коробки". RouterAPI выступает в роли интеллектуального шлюза между нашим бэкендом и провайдерами моделей (OpenAI, Anthropic и другими).
Главное преимущество такого подхода — перенос контроля над расходами на уровень инфраструктуры. В личном кабинете RouterAPI мы настроили жесткие лимиты как на уровне всего проекта, так и на уровне отдельных ключей доступа. Теперь мы задаем строгий дневной бюджет. Если трафик внезапно возрастает и бюджет исчерпывается, шлюз автоматически блокирует дальнейшие запросы, возвращая клиенту HTTP статус 429 Too Many Requests. Никаких сюрпризов в конце месяца или пустых банковских счетов утром.
Кроме того, RouterAPI предоставляет прозрачный мониторинг расходов в реальном времени. Мы видим не просто количество запросов, а точную стоимость каждого вызова, разбитую по моделям и эндпоинтам. Механизмы защиты клиента встроены в саму платформу: система автоматически нормализует запросы, отслеживает аномалии потребления и позволяет моментально отключить скомпрометированный маршрут без необходимости деплоить новый код на бэкенде или менять конфигурацию балансировщиков.
Заключение
Инцидент с потерей тысячи долларов за ночь стал для нас отличным, хотя и дорогим, уроком. В индустрии генеративного ИИ безопасность неразрывно связана с юнит-экономикой. Токсичный трафик — это не просто паразитная нагрузка на сервер, это прямая угроза финансовой стабильности всего проекта.
Защита бюджета требует многоуровневого подхода: от правильной архитектуры приложения и жестких лимитов до использования специализированных шлюзов вроде RouterAPI. Относитесь к своим AI-эндпоинтам как к открытым банковским счетам — и выстраивайте их защиту соответственно.