Защита GPU-серверов от DDoS: включена на каждом публичном IP

Защита GPU-сервера от DDoS входит в каждый сервер FullGPU. Она всегда включена для публичных IP-адресов вашего сервера и не требует доплаты, арендуете ли вы один GPU или восемь. Её задача — отфильтровать сетевые флуд-атаки до того, как они достигнут вашей машины. Сама по себе она не делает открытый эндпоинт инференса безопасным, и на этой странице объясняется, в чём разница.

Как работает защита GPU-сервера от DDoS

Распределённая атака типа «отказ в обслуживании» пытается исчерпать сетевой канал сервера или его ресурсы для обработки соединений трафиком из множества источников. Защита стоит перед вашими публичными IP-адресами на сетевом уровне: атакующий трафик отфильтровывается до того, как достигнет сервера, а легитимный продолжает проходить. Поскольку она всегда включена, не нужно ничего переключать или создавать тикет, чтобы она заработала.

Она действует на всех серверах, которые мы сдаём в аренду, — как на серверах с одним GPU, так и на 8-GPU-серверах. Если между своими серверами вы используете частную сеть, эта часть сети вообще недоступна из интернета.

Что защита покрывает, а что нет

Покрывается

• Флуд атакующего трафика на сетевом уровне, направленный на ваши публичные IP-адреса, — такой, который иначе перегрузил бы канал.
• Каждый сервер, в любое время и без доплаты.

Не покрывается

• Атаки, превышающие возможности включённой защиты. Согласно нашему соглашению об уровне обслуживания (SLA), они не считаются простоем, поэтому не учитываются при расчёте компенсации на баланс (service credits).
• Злоупотребления на уровне приложений. Запросы, которые на сетевом уровне выглядят легитимными, например множество длинных промптов, отправленных на открытый API, проходят через защиту. С ними должно справляться ваше приложение.
• Ваше ПО и конфигурация. Открытый в интернет сервер блокнотов, база данных без пароля или утёкший API-ключ — такие проблемы защита на сетевом уровне не устранит. Кроме того, SLA не распространяется на проблемы, вызванные вашим программным обеспечением, конфигурацией или использованием сервиса.
• Учётные данные. За сохранность SSH-ключей и API-ключей отвечаете вы, как и за всё, что происходит на ваших серверах.

Почему эндпоинтам инференса мало одной защиты от DDoS

Каждый запрос к эндпоинту на GPU обходится дорого. Отдача статической веб-страницы почти ничего не стоит, а языковая модель может потратить секунды работы GPU на один длинный промпт и длинный ответ. Чтобы исчерпать её ресурсы, никакой флуд не нужен. Умеренного числа одновременных запросов с длинными контекстами достаточно, чтобы заполнить KV-кэш и поставить всех реальных пользователей в очередь за ними, а для сети такой трафик выглядит обычным.

Поэтому защита инференса строится в вашем собственном стеке: файрвол, обратный прокси, аутентификация и лимиты перед сервером модели. Об организации самого инференса рассказывает наше руководство по самостоятельному развёртыванию инференса LLM (большой языковой модели) на vLLM.

Чек-лист защиты открытых эндпоинтов

1. Настройте файрвол на хосте

Разрешите SSH и HTTPS, а всё остальное запретите:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Docker публикует порты через собственные правила iptables, которые могут обходить ufw. Публикуйте серверы моделей только на localhost, например -p 127.0.0.1:8000:8000. Подробнее — в руководстве по сети и файрволу.

2. Поставьте перед сервером обратный прокси

Оставьте сервер модели на 127.0.0.1 и открывайте наружу только обратный прокси, например nginx или Caddy. Он терминирует TLS, ограничивает размер запроса и частоту запросов от каждого клиента:

limit_req_zone $binary_remote_addr zone=api:10m rate=5r/s;
server {
    listen 443 ssl;
    server_name api.example.com;
    # ssl_certificate and ssl_certificate_key go here
    client_max_body_size 1m;
    location /v1/ {
        limit_req zone=api burst=20 nodelay;
        proxy_pass http://127.0.0.1:8000;
        proxy_read_timeout 300s;
    }
}

3. Сделайте API-ключи обязательными

Не оставляйте эндпоинт открытым по недосмотру. OpenAI-совместимый сервер vLLM принимает параметр --api-key и после этого отклоняет запросы без соответствующего bearer-токена:

vllm serve <model> --host 127.0.0.1 --port 8000 --api-key "$VLLM_API_KEY"

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

4. Ограничьте стоимость одного запроса

Ограничение частоты учитывает число запросов, а затраты GPU зависят от числа токенов. Ограничьте длину контекста и число одновременных запросов на сервере, например параметрами vLLM --max-model-len и --max-num-seqs, и задайте потолок для max_tokens на уровне своего API. Следите за загрузкой GPU, длиной очереди и долей ошибок, чтобы вовремя заметить злоупотребления; что именно отслеживать, перечислено в руководстве по мониторингу GPU.

Если ваш сервер атакуют

Создайте тикет в разделе поддержки личного кабинета и укажите затронутый IP-адрес, время начала проблемы и то, что вы наблюдаете: графики трафика, долю ошибок, логи. Поддержка работает круглосуточно. Если это злоупотребление на уровне приложения, одновременно ужесточите лимиты и смените ключи. Если из-за простоя по вине электропитания, сети или оборудования на нашей стороне ваша месячная доступность опустится ниже 99,9%, запросите компенсацию на баланс через поддержку не позднее 30 дней после окончания месяца; компенсация зачисляется на баланс вашего аккаунта.