> For the complete documentation index, see [llms.txt](https://docs.iexexchanger.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.iexexchanger.com/knowledge-base/komanda-dostup-i-bezopasnost/security-settings/ddos-protection.md).

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

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

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

{% hint style="info" %}
DDoS означает нарушение доступности, но сам по себе не доказывает кражу данных или взлом аккаунта. Одновременно с атакой могут происходить другие действия, поэтому журналы безопасности всё равно проверяют отдельно.
{% endhint %}

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

| Вид                            | Что перегружается                            | Примеры признаков                                                                   |
| ------------------------------ | -------------------------------------------- | ----------------------------------------------------------------------------------- |
| Объёмная атака                 | Интернет-канал и пропускная способность      | Резкий рост входящего трафика, потеря пакетов, недоступность всех сайтов на адресе  |
| Сетевая или протокольная атака | Таблицы соединений и обработка 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

```mermaid
flowchart LR
    A["Клиенты и внешний трафик"] --> B["Cloudflare: сеть, DDoS, WAF и ограничения"]
    B --> C["Nginx на origin-сервере"]
    C --> D["Клиентский SSR через PM2"]
    C --> E["Панель и API"]
    E --> F["PostgreSQL, Redis и фоновые процессы"]
```

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

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

Cloudflare разделяет защиту сетевого и прикладного уровней, автоматически анализирует сетевые пакеты, HTTP-запросы и ошибки origin. Практические рекомендации включают управляемые DDoS-правила, WAF, rate limiting, кеширование и закрытие прямого доступа к origin. См. [обзор DDoS Protection](https://developers.cloudflare.com/ddos-protection/) и [проактивную защиту](https://developers.cloudflare.com/ddos-protection/best-practices/proactive-defense/).

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

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. Оформите причины, действия и улучшения по инструкции [«Технический инцидент»](/knowledge-base/servery-domeny-i-infrastruktura/overview/acceptance-checklist/incident-runbook.md).

Если атака превышает возможности канала самого провайдера, локальное правило Nginx не успеет помочь: трафик должен быть отфильтрован выше по сети. Официальный обзор подготовки и реагирования также опубликован в [руководстве CISA по DDoS](https://www.cisa.gov/sites/default/files/publications/understanding-and-responding-to-ddos-attacks_508c.pdf).

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

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

Подключение DNS, HTTPS, WebSocket и доверенных прокси описано в статье [«Подключение Cloudflare»](/knowledge-base/komanda-dostup-i-bezopasnost/security-settings/cloudflare.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.iexexchanger.com/knowledge-base/komanda-dostup-i-bezopasnost/security-settings/ddos-protection.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.