Что такое DDoS и как защищаться

Виды DDoS-атак, уровни защиты iEXExchanger и порядок действий при перегрузке

DDoS — Distributed Denial of Service, то есть распределённая атака на доступность. Большое число устройств или источников одновременно создаёт трафик либо тяжёлые запросы, чтобы исчерпать канал, соединения или ресурсы приложения и сделать сайт недоступным для обычных клиентов.

DoS-атака идёт из одного или небольшого числа источников. DDoS распределена между множеством источников, поэтому блокировка одного IP не останавливает распределённый поток.

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

Основные виды атак

Вид	Что перегружается	Признаки
Объёмная атака	Интернет-канал и пропускная способность	Резкий рост входящего трафика, потеря пакетов, недоступность всех сайтов на адресе
Сетевая или протокольная атака	Таблицы соединений и обработка TCP/UDP	Много незавершённых соединений, SYN/ACK-флуды, исчерпание состояний сетевого экрана
Прикладная атака	Nginx, SSR, PHP, база или дорогой маршрут	Большое число правдоподобных HTTP-запросов к поиску, входу, расчёту или API
Атака с отражением и усилением	Канал жертвы через открытые сторонние службы	Большой объём ответов DNS, NTP или других UDP-служб на подменённый адрес
Многовекторная атака	Несколько уровней одновременно	Одновременные сетевые флуды и дорогие HTTP-запросы

Сетевой уровень обозначают как L3/L4, а прикладной HTTP-уровень — как L7. Для владельца обменного пункта важнее не название атаки, а точка перегрузки: сеть провайдера, Cloudflare, Nginx, Node.js SSR, PHP, Redis или база данных.

Как устроена защита iEXExchanger

Cloudflare должен принимать публичный веб-трафик первым и фильтровать его сетевыми правилами, DDoS-защитой, WAF и ограничениями частоты. Nginx на origin-сервере получает пропущенные запросы и направляет их клиентскому SSR, панели, API или WebSocket. Внутренние порты SSR, базы данных, Redis и WebSocket не должны быть доступны напрямую из интернета.

Если фактический IP origin-сервера известен и принимает соединения от любого источника, злоумышленник может обойти Cloudflare и атаковать сервер напрямую. Поэтому защита включает не только включение оранжевого облака в DNS, но и ограничение origin по адресам Cloudflare либо другой согласованной схеме.

Cloudflare разделяет защиту сетевого и прикладного уровней, автоматически анализирует сетевые пакеты, HTTP-запросы и ошибки origin. Практические рекомендации включают управляемые DDoS-правила, WAF, rate limiting, кеширование и закрытие прямого доступа к origin. См. обзор DDoS Protection и проактивную защиту.

Что настроить заранее

1. Проксируйте через Cloudflare все публичные веб-записи, для которых это допустимо.
2. Проверьте DNS-only записи и старые домены, чтобы они не раскрывали origin IP.
3. Разрешите на origin веб-доступ только по утверждённой схеме Cloudflare и сохраните аварийный административный вход.
4. Держите базу данных, Redis, SSR и Reverb на loopback или в закрытой приватной сети.
5. Включите управляемую DDoS-защиту и не снижайте чувствительность без подтверждённого ложного срабатывания.
6. Настройте WAF и ограничения частоты для действительно дорогих и чувствительных маршрутов.
7. Кешируйте только безопасные публичные ответы; страницы заявок, вход и персональные данные не должны становиться общим кешем.
8. Зафиксируйте нормальный уровень запросов, ошибок, CPU, памяти, соединений и времени ответа.
9. Настройте уведомления Cloudflare, провайдера и мониторинга приложения.
10. Подготовьте контакты хостинга и понятный план технического инцидента.

Не задавайте случайный низкий лимит для всего домена. Один общий IP может принадлежать офису, мобильному оператору, VPN или корпоративной сети и представлять многих реальных клиентов. Ограничения должны учитывать маршрут, метод, стоимость операции и обычный профиль трафика.

Как отличить DDoS от обычного сбоя

Наблюдение	Возможная причина	Где проверять
Cloudflare показывает резкий рост заблокированного трафика	Сетевая или HTTP-атака	DDoS Analytics, Security Events и правила
Cloudflare доступен, origin возвращает много 5xx	Перегрузка или ошибка приложения	Nginx, PM2, PHP, база и последние изменения
Один маршрут создаёт основную нагрузку	Прикладная атака или ошибочный клиент	WAF, rate limiting и журнал приложения
Недоступен прямой IP и все сайты сервера	Атака на origin или проблема провайдера	Сеть хостинга и консоль сервера
Трафик обычный, но один процесс постоянно перезапускается	Ошибка процесса, память или конфигурация	Supervisor, PM2 и системные журналы

Код 502 или высокая загрузка не являются достаточным доказательством DDoS. Сначала сопоставьте время, источник трафика, маршруты, ошибки и состояние каждого процесса.

Действия во время атаки

1. Зафиксируйте время начала, затронутые домены и внешнее проявление.
2. Проверьте состояние Cloudflare, провайдера и мониторинга без отключения защиты.
3. Определите уровень атаки: сеть, HTTP-маршрут или внутренний компонент.
4. Сохраните ограниченный временной диапазон аналитики и журналов.
5. Если атакуется конкретный маршрут, примените точечное управляемое правило, challenge или rate limiting.
6. Если виден прямой трафик к origin, ограничьте его по заранее проверенному плану и свяжитесь с провайдером.
7. Контролируйте реальные клиентские операции, callback и административный доступ после каждого изменения.
8. Не перезагружайте весь сервер без подтверждённой системной причины.
9. После стабилизации проверьте ложные срабатывания и восстановите только осознанно временно ограниченные сценарии.
10. Оформите причины, действия и улучшения по инструкции «Технический инцидент».

Если атака превышает возможности канала самого провайдера, локальное правило Nginx не успеет помочь: трафик должен быть отфильтрован выше по сети. Официальный обзор подготовки и реагирования также опубликован в руководстве CISA по DDoS.

Чего не следует делать

• Не переводите проксируемую запись в DNS only во время атаки: это может раскрыть origin и убрать пограничную защиту.
• Не блокируйте все страны и сети без анализа реальных клиентов и внешних сервисов.
• Не отключайте WAF целиком ради одного ложного срабатывания.
• Не публикуйте origin IP в переписке, TXT-записях и снимках экрана.
• Не считайте перезапуск Nginx, PM2 или PHP устранением причины атаки.
• Не удаляйте журналы до разбора инцидента.
• Не меняйте одновременно DNS, сетевой экран, Nginx и приложение: станет невозможно определить результат каждого действия.

Подключение DNS, HTTPS, WebSocket и доверенных прокси описано в статье «Подключение Cloudflare».