Перейти к содержанию

ADR-001: Стратегия защиты от DDoS-атак
Статус Принято — Фаза 1 активна, Фаза 2 не активирована
Дата 2026-08-07
Обновлено 2026-08-14
Пересматривать При достижении 10 000 активных туннелей или первой реальной volumetric-атаке

Текущее состояние (2026-08-14)

Активно: - Фаза 1 — встроенная защита dixu_proxy (rate-limit, diversity-ban, anti-enumeration) - Cloudflare Free — DNS-резолвер для dix.su (NS переехали с Reg.ru на CF) - Cloudflare API используется для: wildcard-сертификата *.dix.su (DNS-01 via certbot) и E2E-сертификатов пользователей приватного режима (CloudflareDnsService)

Не активировано: - Cloudflare proxy-режим (*.dix.su, dix.su) — требует тарифа Pro ($20/мес); реальный IP VPS публично виден - DDoS-защита L3/L4 через Cloudflare

Причина перехода с Reg.ru на Cloudflare (2026-08): необходимость Cloudflare API для wildcard DNS-01 challenge; Reg.ru NS больше не используются.

Контекст

Платформа dix.su работает на одном VPS. Трафик входит через nginx (*.dix.su, dix.su), прокси-сервис написан на Elixir (dixu_proxy), бэкенд — на Java (modulauth).

Возможные типы атак:

  • Volumetric (L3/L4) — флуд пакетами, цель — забить входной канал VPS (10+ Gbps). Против этого прикладной код бессилен: канал кончается до nginx.
  • Protocol/Application (L7) — перебор slug'ов, HTTP-флуд, сканирование аккаунтов. Это прикладной уровень, защита реализуема в коде прокси.
  • Абьюз-атаки — использование платформы как плацдарма для атак на третьи стороны (C2-серверы, DDoS через туннель, фишинг).

На текущем этапе (ранняя аудитория, один VPS) серьёзный volumetric DDoS маловероятен экономически — стоимость атаки несопоставима с масштабом цели.

Решение

Фаза 1 — Встроенная защита (текущее состояние, уже реализовано)

Реализована в dixu_proxy без внешних зависимостей:

Механизм Параметры Цель
Rate limit по IP (HTTP) 20 req/min → тихий отказ; 100 req/min → бан 30 мин Анти-флуд на уровне приложения
Rate limit по IP (TCP) Soft + hard лимит хендшейков Защита TCP-туннелей
Diversity-ban 8+ разных slug'ов с одного IP за 5 мин → бан 2 часа Анти-сканирование/энумерация slug'ов
Лимит соединений 100 одновременных TCP на IP по всем портам Защита от истощения FD/процессов
Anti-enumeration Одинаковое сообщение «no tunnel connected» для офлайн и несуществующих slug'ов Скрытие информации о существующих аккаунтах
nginx Входная точка, базовый HTTP rate limit Первый барьер для L7

Ограничения Фазы 1: не защищает от volumetric L3/L4 атак — при флуде от ~1 Gbps канал VPS исчерпывается раньше, чем прикладной код успевает среагировать.

Фаза 2 — Внешняя защита (при росте или первой реальной атаке)

Выбранный вариант: Cloudflare Pro ($20/мес)

Обоснование: - Wildcard-проксирование *.dix.su требует тарифа Pro — на бесплатном недоступно - Cloudflare закрывает L3/L4/L7 без архитектурных изменений на стороне VPS - Смена: NS-записи домена → Cloudflare, включить proxy-режим для *.dix.su и dix.su - Magic Transit или аналог не нужен на этом этапе

Резервный вариант: Яндекс Cloud SmartWeb Security

Используется если: - Появятся корпоративные клиенты с требованием «трафик не выходит из РФ» (152-ФЗ / ФСТЭК) - Cloudflare станет недоступен для РФ-аудитории инфраструктурно

Минус: требует перестройки входной точки (либо NS на YC, либо upstream через YC Load Balancer), цена при росте трафика выше чем у Cloudflare.

Не выбрано: собственный scrubbing (fail2ban + iptables + BGP Blackhole)

  • Эффективен только до ~1 Gbps
  • Операционная нагрузка несоразмерна пользе на текущем масштабе
  • VPS-провайдер сам заблокирует IP при серьёзном флуде (нулевой routing)

Последствия

Принятые риски (Фаза 1): - Volumetric атака объёмом > 1 Gbps приведёт к недоступности сервиса. Приемлемо: вероятность низкая, экономика атаки нецелесообразна для текущего масштаба.

Триггеры перехода на Фазу 2: - Первая реальная volumetric атака (даже одна) - ≥ 10 000 активных туннелей - Появление корпоративных клиентов с SLA-требованиями

Архитектурное ограничение Фазы 2: - Cloudflare в proxy-режиме меняет IP посетителя в заголовках; dixu_proxy должен читать CF-Connecting-IP вместо remote_ip. Потребуется небольшое изменение в коде прокси. - При включении Cloudflare TCP-туннели (порты 2222, 4432, 4306, 4379, 4017) останутся вне Cloudflare-проксирования — они работают напрямую на IP VPS. Это ожидаемое поведение, Cloudflare не проксирует произвольные TCP-порты.

Смотрите также