
Опасность DDoS заключается не только в объёме трафика. Современная атака может состоять из относительно небольшого числа запросов, каждый из которых запускает ресурсоёмкую операцию: сложный поиск, формирование отчёта, обращение к базе данных, создание PDF, обработку изображения или авторизацию. В этом случае атакующий перегружает не интернет-канал, а внутренние компоненты приложения.
Поэтому защита от DDoS не сводится к блокировке нескольких IP-адресов. Необходимо анализировать сетевой и HTTP-трафик, поведение клиентов, частоту запросов, репутацию адресов, ASN, географию, отпечатки соединений и нагрузку на отдельные функции сайта.
Что такое DoS-атака
DoS — Denial of Service, то есть отказ в обслуживании. Цель такой атаки — лишить обычных пользователей возможности пользоваться сайтом или отдельной функцией.
DoS не обязательно означает огромный поток трафика. Отказ можно вызвать разными способами:
- занять все доступные соединения веб-сервера;
- исчерпать память или процессорное время;
- заполнить очередь заданий;
- занять весь пул соединений с базой данных;
- отправить специально сформированный запрос, вызывающий сбой;
- создать большое количество пользовательских сессий;
- многократно запускать ресурсоёмкую операцию;
- заблокировать учётные записи пользователей серией неудачных авторизаций;
- заполнить диск логами, временными файлами или результатами обработки.
OWASP определяет DoS как воздействие, направленное на то, чтобы сделать сайт, приложение или сервер недоступным по назначению. Причиной может стать не только большой поток запросов, но и ошибка управления ресурсами: утечка памяти, незакрытые соединения с базой данных или отсутствие ограничений на объём обрабатываемых данных.
Чем DoS отличается от DDoS
Главное отличие заключается в количестве источников атаки.
| Параметр | DoS | DDoS |
|---|---|---|
| Количество источников | Один или небольшое число | Сотни, тысячи или миллионы устройств |
| Блокировка по IP | Часто помогает | Обычно недостаточна |
| Масштаб | Ограничен ресурсами одного источника | Суммирует ресурсы распределённой сети |
| Схожесть с обычным трафиком | Часто легко заметить | Может имитировать реальных посетителей |
| География | Обычно ограниченная | Запросы могут приходить из десятков стран |
| Сложность фильтрации | Относительно невысокая | Требуется анализ множества сигналов |
Представим, что интернет-магазин выдерживает 500 запросов в секунду. Один компьютер отправляет 700 запросов в секунду и перегружает сервер — это DoS. Если 10 000 заражённых устройств отправляют всего по одному запросу в секунду, сайт получает уже 10 000 запросов в секунду. Каждое устройство ведёт себя умеренно, но их совокупная активность вызывает отказ — это DDoS.
Именно распределённость делает DDoS сложным для фильтрации. Среди источников могут находиться домашние роутеры, камеры, серверы, смартфоны и компьютеры реальных пользователей. Без анализа поведения простая блокировка адресов способна затронуть легитимный трафик.
Как работает DDoS-атака
Типичная атака проходит в несколько этапов.
- Выбор цели. Атакующий определяет домен, IP-адрес, API или конкретную функцию сайта.
- Разведка. Проверяются DNS-записи, настоящий IP origin-сервера, поддерживаемые протоколы, открытые порты и поведение защиты.
- Подготовка источников. Используется ботнет, арендованная инфраструктура, сеть прокси или неправильно настроенные сторонние серверы.
- Запуск трафика. На цель направляются пакеты, соединения или HTTP-запросы.
- Поиск слабого места. Если канал выдерживает нагрузку, атакующий переключается на приложение, базу данных, авторизацию или тяжёлые страницы.
- Изменение тактики. После блокировки одного вектора может меняться протокол, URL, User-Agent, география или частота запросов.
- Поддержание давления. Атака идёт постоянно либо короткими волнами, мешая восстановлению сайта.
Цель атакующего — найти асимметрию между стоимостью запроса и стоимостью его обработки. Если отправка запроса требует от клиента минимальных ресурсов, а сервер выполняет несколько обращений к базе, формирует сложный ответ и вызывает сторонний API, такой endpoint становится удобной целью.
Пример асимметрии ресурсов
Обычная статическая страница может обрабатываться за 5 миллисекунд и отдаваться из кэша. Запрос поиска с несколькими фильтрами занимает 300 миллисекунд, обращается к базе данных и создаёт крупный JSON-ответ.
Если сервер располагает десятью рабочими процессами, приблизительная пропускная способность без учёта других ограничений будет различаться:
- статический ответ: около 2 000 операций в секунду;
- тяжёлый поиск: около 33 операций в секунду.
Следовательно, для перегрузки поиска атакующему потребуется намного меньше запросов. В журналах может не быть огромного трафика, но время ответа базы и количество занятых рабочих процессов резко увеличатся.
Подключите домен и посмотрите живую ленту: кто пришёл, с какой сети, что запрашивал и по какому правилу был пропущен или заблокирован.
Что такое DDoS-ботнет
Ботнет — это сеть устройств, которыми оператор может управлять удалённо. В неё могут входить заражённые компьютеры, виртуальные серверы, домашние маршрутизаторы, камеры, регистраторы и другие устройства, подключённые к интернету.
Во время атаки управляющая инфраструктура передаёт участникам ботнета команду обращаться к определённой цели. Каждый отдельный узел может создавать небольшой поток, но суммарная нагрузка становится огромной.
Пример: 50 000 устройств отправляют по два запроса в секунду. Для одного IP такая активность выглядит неопасно, однако сайт получает 100 000 запросов в секунду. Ограничение «не более 10 запросов в секунду с одного IP» эту атаку не остановит.
Помимо классических ботнетов, для атак могут применяться:
- арендованные виртуальные серверы;
- скомпрометированные сайты;
- открытые прокси;
- резидентские прокси-сети;
- браузеры посетителей заражённых страниц;
- неправильно настроенные UDP-сервисы, используемые для отражения трафика.
Основные виды DDoS-атак
Единой идеальной классификации не существует, поскольку одна техника может воздействовать сразу на несколько уровней. На практике удобно выделять объёмные, протокольные и прикладные атаки.
| Класс | Основная цель | Типичные примеры | Главная метрика |
|---|---|---|---|
| Объёмные | Пропускная способность канала | UDP Flood, ICMP Flood, DNS Amplification | бит/с |
| Протокольные | Таблицы соединений и сетевой стек | SYN Flood, TCP Connection Flood | пакеты/с, соединения |
| Прикладные | Веб-сервер, приложение, API, база | HTTP Flood, Login Flood, Search Flood | запросы/с, время обработки |
| Медленные | Пулы соединений и рабочие процессы | Slowloris, Slow POST, Slow Read | длительность и число соединений |
| Ресурсные | CPU, RAM, диск, очереди и внешние сервисы | генерация отчётов, OTP Flood, Log Flood | стоимость одной операции |
Объёмные атаки
Объёмная атака пытается заполнить интернет-канал большим количеством данных. Даже если сервер способен обработать запросы, полезный трафик не доходит до него из-за перегруженного соединения.
К этому классу относятся UDP Flood, ICMP Flood и атаки с усилением. Их интенсивность обычно измеряется в битах в секунду, но дополнительно необходимо учитывать число пакетов: поток небольших пакетов способен сильнее нагружать сетевое оборудование, чем такой же объём крупных.
Атаки с отражением и усилением
При отражённой атаке злоумышленник отправляет запрос стороннему серверу, подставляя IP-адрес жертвы в качестве адреса отправителя. Ответ направляется не атакующему, а цели.
Если короткий запрос вызывает значительно более крупный ответ, возникает усиление. Для этого могут использоваться открытые DNS-, NTP-, SSDP-, CLDAP- и другие UDP-сервисы.
Условный пример: запрос размером 60 байт вызывает ответ размером 3 000 байт. Коэффициент усиления составляет 50. Для создания потока в 5 Гбит/с атакующему в упрощённой модели достаточно отправлять около 100 Мбит/с исходящих запросов, а остальной объём создадут серверы-отражатели.
SYN Flood
SYN Flood воздействует на установление TCP-соединений. Клиент отправляет начальный SYN-пакет, сервер выделяет ресурсы и отвечает SYN-ACK, но завершение рукопожатия не происходит. Большое количество незавершённых соединений заполняет очередь и мешает подключаться обычным клиентам.
Признаки SYN Flood:
- резкий рост полуоткрытых TCP-соединений;
- большое число SYN без последующего ACK;
- переполнение очереди соединений;
- рост сетевой нагрузки без соответствующего числа HTTP-запросов;
- недоступность сайта при сравнительно нормальной загрузке приложения.
HTTP Flood
HTTP Flood направлен на веб-сервер или приложение. Запросы могут выглядеть корректно: использовать обычные методы GET или POST, передавать правдоподобные заголовки, поддерживать cookies и выполнять JavaScript.
Наиболее опасны запросы к динамическим функциям:
- поиск и фильтрация;
- авторизация;
- восстановление пароля;
- корзина и оформление заказа;
- API с обращением к базе данных;
- генерация файлов и отчётов;
- загрузка или преобразование изображений;
- страницы, не попадающие в кэш.
Например, 2 000 запросов к главной странице могут обслуживаться из кэша без заметной нагрузки. Но 100 одновременных запросов на создание сложного отчёта способны занять все рабочие процессы и соединения с базой.
Cache-Busting DDoS
Кэш снижает нагрузку, когда разные пользователи запрашивают один и тот же ресурс. Атакующий может добавлять к URL случайные параметры:
/catalog/?filter=phone&x=48291
/catalog/?filter=phone&x=73504
Если каждый вариант воспринимается как новый ключ кэша, reverse proxy обращается к origin-серверу снова. В результате внешне похожие запросы лишают инфраструктуру преимущества кэширования.
Защита должна учитывать, какие параметры действительно меняют содержимое страницы. Ненужные параметры можно исключать из ключа кэша, нормализовать или отбрасывать.
Медленные DDoS-атаки
Медленные атаки удерживают соединения открытыми, передавая данные небольшими частями. Их задача — занять лимит соединений, потоков или рабочих процессов без большого объёма трафика.
Основные разновидности:
- Slowloris — заголовки HTTP-запроса передаются настолько медленно, что сервер продолжает ожидать завершения;
- Slow POST — тело POST-запроса отправляется маленькими частями;
- Slow Read — клиент крайне медленно принимает ответ, заставляя сервер сохранять соединение и данные;
- Low-and-Slow — небольшая, но продолжительная активность распределяется между множеством источников.
Такие атаки плохо заметны по объёму трафика. Важнее отслеживать длительность соединений, скорость передачи, количество незавершённых запросов и долю клиентов с аномально медленным поведением.
HTTP/2 Rapid Reset
HTTP/2 позволяет передавать множество параллельных потоков внутри одного соединения. В атаке Rapid Reset клиент создаёт поток с запросом и почти сразу отменяет его через RST_STREAM. Сервер уже начал разбирать заголовки, выделять память и маршрутизировать запрос, тогда как клиент почти не тратит ресурсов.
За счёт немедленной отмены клиент может быстро создавать новые потоки, не упираясь в обычное ограничение на количество одновременно открытых запросов. Google сообщал, что наблюдаемая атака этого типа превышала 398 миллионов запросов в секунду. Техника получила идентификатор CVE-2023-44487. Механика и рекомендации по защите подробно разобраны в [материале Google Cloud](https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack).
Для защиты недостаточно блокировать отдельные запросы. Необходимо отслеживать поведение всего соединения: число созданных и отменённых потоков, долю сбросов, скорость открытия потоков и превышение лимитов. При подтверждённом злоупотреблении соединение закрывается целиком.
Что такое многовекторная DDoS-атака
Многовекторная атака сочетает несколько техник одновременно или последовательно. Например:
- UDP Flood заполняет канал;
- SYN Flood нагружает таблицу соединений;
- HTTP Flood атакует динамические страницы;
- медленные соединения занимают оставшиеся рабочие процессы;
- боты обращаются напрямую к origin IP, обходя reverse proxy.
Назначение такой тактики — заставить защиту постоянно перестраиваться. Правило, эффективное против одного вектора, не обязательно остановит другой. Блокировка UDP не влияет на корректные HTTPS-запросы, а Rate Limiting по IP может быть бесполезен против большого распределённого ботнета.
Как понять, что сайт находится под DDoS-атакой
Один признак не доказывает атаку. Медленная работа может быть вызвана обновлением, ошибкой кода, отказом базы данных или рекламной кампанией. Решение принимается по совокупности сетевых, серверных и поведенческих сигналов.
Основные признаки
- резкий рост количества запросов или соединений;
- увеличение входящего трафика;
- рост времени ответа;
- ошибки 429, 502, 503 и 504;
- высокая загрузка CPU или памяти;
- исчерпание пула соединений с базой;
- увеличение количества полуоткрытых TCP-соединений;
- множество запросов к одному URL или функции;
- случайные параметры в URL;
- резкое изменение географии посетителей;
- рост трафика от дата-центров, прокси или подозрительных ASN;
- большое число новых IP без обычной пользовательской активности;
- повторяющиеся User-Agent или поддельные браузерные заголовки;
- запросы без загрузки CSS, JavaScript и изображений;
- отсутствие нормальных переходов между страницами;
- аномально высокая доля отменённых или незавершённых запросов.
Какие метрики проверять
| Метрика | Что может означать изменение |
|---|---|
| Requests per second | HTTP Flood или всплеск аудитории |
| Packets per second | Сетевая или протокольная атака |
| Bits per second | Перегрузка канала |
| Concurrent connections | Connection Flood или медленная атака |
| Время ответа p95/p99 | Деградация для наиболее медленных запросов |
| Ошибки 5xx | Перегрузка origin-сервера или приложения |
| Ошибки 429 | Срабатывание ограничений частоты |
| Cache hit ratio | Возможная атака с обходом кэша |
| DB connections | Истощение пула базы данных |
| Уникальные IP и ASN | Масштаб и распределённость источников |
| Стоимость endpoint | Поиск ресурсоёмких целей атаки |
Среднее время ответа может скрывать проблему. Если большинство статических запросов обрабатывается быстро, а 5% динамических запросов зависают на несколько секунд, среднее значение выглядит приемлемо. Поэтому следует смотреть не только среднее, но и перцентили p95 и p99.
Как отличить DDoS от обычного всплеска посетителей
Реальные посетители тоже могут создать большую нагрузку после рекламы, публикации новости, рассылки или сезонной акции. Однако структура их поведения обычно отличается от поведения атакующих ботов.
| Признак | Обычный всплеск | DDoS-атака |
|---|---|---|
| Источники переходов | Реклама, поиск, социальные сети, рассылка | Прямые или необъяснимые обращения |
| Навигация | Последовательные переходы между страницами | Повторение одного endpoint или случайных URL |
| Статические файлы | Загружаются CSS, JS, изображения | Могут запрашиваться только HTML или API |
| Cookies и сессии | Сохраняются и используются | Часто отсутствуют или постоянно меняются |
| География | Соответствует аудитории | Резко меняется без бизнес-причины |
| Конверсии | Растут вместе с посещаемостью | Не растут или падают |
| Длительность | Обычно связана с событием | Может идти волнами и менять форму |
| Отпечатки клиентов | Разнообразные и правдоподобные | Повторяются или содержат аномалии |
Пример: после рекламной кампании посещаемость увеличилась в пять раз, но пользователи открывают товары, используют фильтры, добавляют позиции в корзину и оформляют заказы. Это, вероятнее всего, настоящий рост.
Если запросы выросли в пять раз, 90% обращений направлено к поиску, параметры состоят из случайных значений, cookies не сохраняются, а конверсий нет — вероятна автоматизированная атака.
Какие последствия вызывает DDoS
Очевидное последствие — недоступность сайта, но реальный ущерб обычно шире.
- Потеря продаж. Пользователи не могут оформить или оплатить заказ.
- Потеря клиентов. Посетитель уходит к конкуренту и может не вернуться.
- Рост расходов. Увеличиваются счета за трафик, облачные ресурсы, серверные функции, SMS и сторонние API.
- Нарушение SLA. Компания не выполняет обязательства по доступности сервиса.
- Проблемы с индексацией. Поисковые роботы получают ошибки или не могут загрузить страницы.
- Повреждение операций. Зависают фоновые задачи, очереди, обмен с CRM и платёжными сервисами.
- Ложные блокировки. Срочные грубые правила могут ограничить настоящих клиентов.
- Сокрытие взлома. DDoS используется как отвлекающий манёвр во время другой атаки.
- Репутационный ущерб. Пользователи перестают считать сервис надёжным.
Пример расчёта потерь
Интернет-магазин получает 120 заказов в час со средней прибылью 900 ₽ с заказа. Два часа полной недоступности означают потенциальную прямую потерю:
120 × 900 × 2 = 216 000 ₽.
В расчёт не входят рекламный бюджет, расходы на восстановление, обращения в поддержку, повторная настройка инфраструктуры и клиенты, которые больше не вернутся.
Сколько может длиться DDoS-атака
Фиксированной продолжительности нет. Атака может длиться несколько минут, часов, дней или повторяться волнами в течение недель.
На продолжительность влияют:
- цель и мотивация атакующего;
- доступные ресурсы ботнета;
- эффективность фильтрации;
- возможность прямой атаки на origin IP;
- скорость изменения защитных правил;
- стоимость продолжения атаки;
- реакция владельца сайта;
- использование вымогательства или конкурентного давления.
Короткая атака может быть проверкой защиты. Злоумышленник фиксирует порог, при котором начинаются ошибки, определяет слабые endpoint и возвращается с другим вектором. Поэтому прекращение потока не означает, что инцидент завершён: после стабилизации необходимо сохранить данные и проверить, не было ли сопутствующего взлома.
Что делать во время DDoS-атаки
Шаг 1. Подтвердить, что проблема действительно связана с трафиком
Проверьте мониторинг, доступность origin-сервера, базу данных, DNS, сертификат и последние изменения приложения. Ошибка после обновления может выглядеть как DDoS, а DDoS — как неисправность базы.
Шаг 2. Определить перегруженный ресурс
Необходимо понять, что именно стало узким местом:
- интернет-канал;
- сетевой стек;
- таблица соединений;
- TLS-обработка;
- веб-сервер;
- приложение;
- база данных;
- очередь задач;
- внешний API.
Если канал уже заполнен, правила на самом сервере не помогут: вредоносный трафик должен фильтроваться раньше. Если канал свободен, но база данных перегружена запросами к поиску, требуется защита конкретного endpoint.
Шаг 3. Сохранить данные
До изменения правил сохраните:
- время начала инцидента;
- графики трафика и нагрузки;
- HTTP- и системные логи;
- список целевых URL;
- распределение IP, стран и ASN;
- User-Agent и отпечатки клиентов;
- коды ответов;
- показатели CPU, RAM, базы и соединений;
- примеры вредоносных запросов;
- внесённые изменения и время их применения.
Шаг 4. Закрыть прямой доступ к origin
Если сайт работает через reverse proxy, origin-сервер должен принимать веб-трафик только от доверенных адресов прокси. Иначе атакующий найдёт настоящий IP и направит поток напрямую, минуя WAF, кэш и Anti-DDoS.
Шаг 5. Ограничить наиболее дорогие функции
Временно можно усилить ограничения для:
- авторизации и восстановления пароля;
- поиска и сложных фильтров;
- API без авторизации;
- загрузки файлов;
- генерации документов;
- отправки SMS и email;
- ресурсоёмких POST-запросов.
Ограничение должно учитывать не только IP, но и аккаунт, сессию, endpoint, ASN, отпечаток клиента и общую стоимость операций.
Шаг 6. Ввести адаптивную фильтрацию
Полная блокировка страны или всех неизвестных клиентов может быстро снизить нагрузку, но создаёт побочный ущерб. Предпочтительна ступенчатая реакция:
- пропуск проверенных клиентов;
- ограничение частоты подозрительных запросов;
- проверка браузера или CAPTCHA при достаточных основаниях;
- временная блокировка явно автоматизированных источников;
- блокировка сетей с высокой концентрацией атаки;
- ужесточение правил только для атакуемых URL.
Шаг 7. Проверить сопутствующую активность
Во время DDoS необходимо проверить входы администраторов, изменения файлов, создание пользователей, обращения к служебным URL и необычные операции в базе. Шум может использоваться для сокрытия попытки взлома.
Как защитить сайт от DDoS
Надёжная защита строится слоями. Один механизм не перекрывает все векторы.
Reverse proxy и сокрытие origin IP
Reverse proxy принимает внешние запросы, анализирует их и только затем передаёт разрешённый трафик на сервер сайта. Это позволяет фильтровать атаки до origin, применять кэширование, Rate Limiting, WAF и антибот-анализ.
Однако схема работает только в том случае, если настоящий IP сервера не раскрыт и firewall запрещает прямые подключения из интернета.
Rate Limiting
Rate Limiting ограничивает количество операций за определённое время. Единый лимит для всего сайта малоэффективен: главная страница, авторизация и генерация отчёта имеют разную стоимость.
Правила целесообразно задавать отдельно:
- по IP и подсети;
- по аккаунту;
- по сессии;
- по API-ключу;
- по endpoint;
- по стране или ASN;
- по типу клиента;
- по числу неуспешных операций.
Например, 60 запросов в минуту могут быть нормой для каталога, но чрезмерным значением для восстановления пароля. Для дорогих операций допустимый предел должен быть ниже.
Кэширование
Кэш снижает число обращений к origin и базе данных. Для эффективности необходимо:
- кэшировать публичные страницы и статические ресурсы;
- нормализовать ненужные query-параметры;
- не включать случайные параметры в ключ без необходимости;
- защищать механизм очистки кэша;
- не кэшировать персональные данные как общедоступные;
- использовать устаревшую копию страницы при временной недоступности origin, если это допустимо.
WAF
WAF помогает блокировать вредоносные HTTP-запросы, известные сигнатуры, подозрительные методы, обходы путей и обращения к служебным файлам. Но классический набор сигнатур не остановит корректный HTTP Flood, если запросы внешне не содержат вредоносной нагрузки.
Для L7 DDoS WAF должен дополняться Rate Limiting, поведенческим анализом, репутацией IP, проверкой отпечатков и контролем ресурсов приложения.
Антибот-анализ
Современные боты умеют менять IP и User-Agent, поддерживать cookies и запускать браузер. Поэтому защита должна сопоставлять несколько сигналов:
- TLS-отпечаток;
- HTTP-заголовки и их порядок;
- браузерный отпечаток;
- скорость и последовательность действий;
- поддержку cookies и JavaScript;
- историю IP и ASN;
- тип сети: дата-центр, домашняя, мобильная, VPN или прокси;
- переходы между страницами;
- частоту создания новых сессий.
Защита приложения
Часть DoS-рисков устраняется только в коде:
- ограничение размера тела запроса;
- лимит числа элементов, фильтров и вложенных объектов;
- ограничение сложности GraphQL-запросов;
- тайм-ауты обращения к базе и внешним API;
- пагинация больших выборок;
- закрытие соединений при исключениях;
- очереди для тяжёлых операций;
- идемпотентность повторных запросов;
- отмена вычислений после отключения клиента;
- ограничение параллельных операций одного пользователя;
- контроль размеров загружаемых и распаковываемых файлов.
Мониторинг и базовый профиль трафика
Чтобы заметить аномалию, нужно знать нормальное состояние сайта. Минимальный профиль включает обычное число запросов, соединений, посетителей, стран, ASN, кодов ответа, время p95/p99, долю кэша и нагрузку на основные endpoint.
TrafficVeil как reverse proxy может использовать комбинацию WAF, Rate Limiting, анализа ботов, GeoIP/ASN-фильтрации и контроля HTTP-трафика. Но на стороне владельца сайта всё равно необходимо закрыть прямой доступ к origin, обновлять серверное ПО и устранять ресурсоёмкие операции без ограничений.
Типичные ошибки при защите от DDoS
- Блокировать только IP. Распределённая атака легко обходит единичные блокировки.
- Ориентироваться только на User-Agent. Его можно подделать одной строкой.
- Подключать защиту после перегрузки. Если сайт уже недоступен, изменение DNS может потребовать времени.
- Оставлять origin открытым. Атака обойдёт reverse proxy напрямую.
- Использовать один лимит для всех страниц. Это не учитывает разную стоимость операций.
- Блокировать всех новых посетителей. Такой подход сам создаёт отказ в обслуживании.
- Считать любой всплеск атакой. Можно заблокировать настоящую рекламную аудиторию.
- Не сохранять логи. После завершения потока невозможно восстановить картину атаки.
- Полагаться только на масштабирование. Автоматическое добавление серверов может превратить DDoS в атаку на облачный бюджет.
- Не проверять приложение. Небольшой поток к тяжёлому endpoint способен обойти мощную сетевую защиту.
Краткий чек-лист защиты
- сайт подключён через reverse proxy;
- origin IP не опубликован в актуальных и старых DNS-записях;
- firewall принимает веб-трафик только от reverse proxy;
- для дорогих endpoint настроены отдельные лимиты;
- включено кэширование публичных страниц;
- контролируются случайные query-параметры;
- ограничены размеры заголовков, тела и загрузок;
- настроены тайм-ауты соединений;
- обновлены HTTP/2-серверы и прокси;
- собираются HTTP-, системные и сетевые метрики;
- измеряются p95 и p99 времени ответа;
- фиксируются IP, ASN, страна, тип сети и отпечаток клиента;
- подготовлен порядок действий при атаке;
- ответственные сотрудники знают, где находятся логи и мониторинг;
- после атаки проводится проверка на сопутствующий взлом.
Частые вопросы
Можно ли полностью защитить сайт от любой DDoS-атаки?
Поможет ли блокировка IP-адресов?
Может ли небольшой поток запросов вызвать отказ?
Защищает ли CDN от DDoS?
Почему нельзя просто увеличить мощность сервера?
Как быстро можно обнаружить DDoS?
Может ли DDoS использоваться для сокрытия взлома?
Нужно ли менять DNS во время атаки?
Что важнее: WAF или Anti-DDoS?
Что делать после завершения DDoS-атаки?
Команда TrafficVeil разрабатывает инструменты защиты сайтов от ботов, DDoS и веб-атак. Разборы ботов пишем по логам подключённых доменов и открытым данным операторов.