Что такое DDoS-атака? Техника, уровни и защита

DDoS-атака — это попытка сделать службу недоступной за счёт искусственно созданной перегрузки, причём выполняется она одновременно с очень большого числа разных адресов отправителей. Аббревиатура расшифровывается как Distributed Denial of Service, то есть распределённый отказ в обслуживании. Атакуют при этом не содержимое сервера и не уязвимость в его программном обеспечении, а ресурс, который конечен: полосу канала, интенсивность пакетов сетевой карты, место в таблице состояний ядра или процессорное время, которое приложение тратит на один единственный запрос. Как только один из этих четырёх ресурсов занят, настоящие пользователи перестают проходить, причём без того, чтобы кто-то взломал систему.

Эта статья — введение в тему. В ней разобраны три уровня, на которых происходят атаки, коэффициенты усиления, превращающие один байт запроса в 51 000 байт ответа, откуда берётся атакующая ёмкость и сколько она стоит на рынке, как распознать атаку по собственным измерениям, что ещё помогает на самом сервере и где именно проходит эта граница. Все числа названы с источником, чтобы вы могли их проверить. Если ваша служба стоит прямо сейчас, прочитайте сначала раздел «Что делать во время атаки» и измеряйте, а не крутите настройки.

Что такое DDoS-атака с технической стороны

Любая DDoS-атака живёт за счёт асимметрии: отправить пакет должно стоить атакующему меньше, чем цели стоит этот пакет обработать. Всё остальное — лишь вопрос о том, в каком месте эта асимметрия наибольшая. Таких мест ровно четыре, и у каждого есть жёсткий верхний предел, который можно посчитать.

Полоса канала. Подключение на 1 Гбит/с переносит 125 мегабайт в секунду, и не более. Тот, кто отправляет больше, создаёт потери, а потери задевают пакеты ваших пользователей точно так же, как пакеты атакующего, потому что заполненный канал не выбирает.

Интенсивность пакетов. Наименьший допустимый Ethernet-пакет имеет длину 64 байта и вместе с преамбулой и межпакетным интервалом занимает на канале 84 байта. В 1 Гбит/с таких помещается около 1,49 миллиона в секунду. Обычное серверное ядро в зависимости от CPU и сетевой карты обрабатывает несколько сотен тысяч, прежде чем начинает отбрасывать. Поэтому интенсивность пакетов почти всегда упирается раньше, чем полоса.

Таблицы состояний. Ядро запоминает полуоткрытые TCP-соединения и потоки пакетов. Эти таблицы ограничены по числу записей, а не в битах в секунду. Заполнить их можно при очень малой полосе, если каждый пакет несёт новый адрес отправителя.

Процессорное время приложения. Поисковый запрос, попытка входа с проверкой пароля или запрос к серверу, который возвращает целый список модов, стоит цели в тысячу раз дороже, чем отправителю. Здесь действующей атаке зачастую не нужно даже 10 Мбит/с.

DoS и DDoS: разница, которую можно измерить

Понятийную основу даёт RFC 4732, «Internet Denial-of-Service Considerations», информационная публикация IETF от ноября 2006 года. Там сказано буквально: «A Denial-of-Service (DoS) attack is an attack in which one or more machines target a victim and attempt to prevent the victim from doing useful work.» То есть DoS-атака определена через результат, а не через число источников. Распределённой, то есть DDoS, она становится тогда, когда эти источники многочисленны и независимы друг от друга.

Практически разница считается ровно в одном месте: в длине вашего списка блокировок. DoS-атаку из одного источника вы прекращаете одним правилом. Cloudflare задокументировала в мае 2025 года атаку, которая пришла с 122 145 разных адресов источника из 161 страны и 5 433 автономных систем, в среднем 26 855 новых адресов в секунду, в пике 45 097. Против такого нет списка блокировок, который растёт достаточно быстро, а каждая запись в нём дополнительно стоит памяти и времени поиска на устройстве, которое и без того перегружено.

Совместное руководство «Understanding and Responding to Distributed Denial-of-Service Attacks» от CISA, FBI и MS-ISAC делит атаки ровно на три техники: объёмные, протокольные и прикладные. Это самое полезное из существующих разделений, потому что оно одновременно описывает, какой из ваших четырёх ресурсов атакуют и где должна стоять защита.

Три уровня DDoS-атаки

Объёмные атаки на уровнях 3 и 4

Объёмная атака не хочет ничего другого, кроме как заполнить канал перед целью. Измеряется она в битах в секунду. Средство, как правило, — UDP-flood, потому что в UDP нет установления соединения, которого можно было бы потребовать, и потому что адреса отправителей легко подделать.

Самый крупный публично задокументированный пример на сегодня: Cloudflare сообщает за период до конца 2025 года об автоматически отражённой атаке на 31,4 Тбит/с, которая длилась 35 секунд. Это ёмкость около 31 400 серверных подключений на 1 Гбит/с, одновременно, в течение хорошей половины минуты. В том же отчёте есть второе значение, которое даёт масштаб лучше, чем пиковое: в 2025 году тот же оператор отразил 47,1 миллиона DDoS-атак, это плюс 121 процент к предыдущему году, в среднем 5 376 атак в час.

Лучше задокументированный случай мая 2025 года показывает, как такая атака выглядит, если её разобрать: 7,3 Тбит/с в пике, 37,4 терабайта данных за 45 секунд, то есть в среднем около 830 гигабайт в секунду. Каналу на 1 Гбит/с на тот же объём данных понадобилось бы добрых три дня. 99,996 процента трафика были чистыми UDP-flood, распределёнными в среднем по 21 925 портам назначения одновременно, в пике по 34 517. Такое распределение по всем портам типично: атакующий не знает, какой порт важен, поэтому берёт все.

Протокольные атаки: таблицы, а не канал

Протокольная атака использует то, что ядро обязано запоминать состояния. Стандартный пример — SYN-flood: атакующий отправляет TCP-пакеты с выставленным битом SYN и поддельным адресом отправителя, сервер заводит для каждого запись в своей очереди полуоткрытых соединений, отвечает SYN-ACK на адрес, который никогда не обращался, и ждёт. Измеряется это в пакетах в секунду, а не в гигабитах.

Длина этой очереди задаётся в net.ipv4.tcp_max_syn_backlog и на обычном сервере лежит в четырёхзначном диапазоне. Очередь на 1 024 места при 1,49 миллиона SYN-пакетов в секунду заполняется меньше чем за одну миллисекунду. Для этого чисто арифметически достаточно 1 Гбит/с, а если целью является только таблица, хватит и малой доли.

К этому же семейству относится способ, описанный лишь в 2021 году: отражение TCP через промежуточные устройства с состоянием. Работа «Weaponizing Middleboxes for TCP Reflected Amplification» показывает, что файрволы и инфраструктура цензуры, отслеживающие состояние TCP лишь частично, отвечают на один поддельный пакет целыми страницами данных. Тем самым для усиления впервые пригоден и TCP, что до этого считалось практически невозможным.

Прикладные атаки на уровне 7

Прикладная атака выглядит как обычный трафик, потому что она и есть обычный трафик, только в неправильном количестве. Измеряется она в запросах в секунду. Она приходит по полностью установленному соединению, то есть переживает любую проверку, которая оценивает только установление соединения, и требует мало полосы: 10 000 HTTP-запросов в секунду — это в зависимости от размера запроса меньше 50 Мбит/с и тем не менее достаточно, чтобы поставить базу данных на колени.

Эталон здесь называется HTTP/2 Rapid Reset, раскрытый 10 октября 2023 года как CVE-2023-44487. Уязвимость лежит в способности HTTP/2 к мультиплексированию: атакующий открывает поток данных, отправляет запрос и тут же его обрывает. Сервер работу уже начал, а у атакующего сразу снова свободное место в окне. Достигнутые таким образом значения составили 201 миллион запросов в секунду (Cloudflare), 398 миллионов (Google) и 155 миллионов (Amazon). Для сравнения: до этого самая крупная измеренная Cloudflare атака на уровне 7 составляла 71 миллион запросов в секунду.

У игровых серверов уровнем 7 является само установление соединения. Nullping, QuietException и флуд поддельных рукопожатий против Minecraft-сетей почти не требуют полосы и валят целые связки прокси, потому что каждый пакет заставляет прокси принимать дорогое решение о состоянии. Как именно выглядят эти схемы, описано в статье Защита Minecraft от DDoS и защита от nullping.

Сравнение трёх уровней

Настоящие атаки этого деления не придерживаются. Самый неприятный на практике случай — многоуровневая атака: объёмная часть, которая занимает канал, плюс часть на уровне 7, которая проходит именно в тот момент, когда внимание сосредоточено на полосе. Одна из показанных ниже атак, отфильтрованных в KernelHost, состояла более чем из двенадцати разных основных схем одновременно.

Атаки с усилением: как из одного байта получается 51 000

Атака с усилением — это атака, при которой атакующий стреляет по цели не сам, а заставляет делать это за него посторонние, публично доступные службы. Он отправляет маленький запрос на открытую службу и указывает в качестве отправителя IP-адрес жертвы. Служба послушно отвечает, только жертве, и ответ в разы больше запроса.

Отношение размера ответа к размеру запроса называется Bandwidth Amplification Factor, сокращённо BAF. BAF равный 50 означает, что атакующий с собственным подключением на 1 Гбит/с направляет на цель 50 Гбит/с. Чтобы это работало, нужны две вещи вместе: протокол поверх UDP, отвечающий больше, чем его спрашивают, и возможность подделать адрес отправителя. Поэтому IP-спуфинг — это предпосылка любой атаки с усилением, а не просто тактика сокрытия.

Для защищающегося из этого следует неприятное свойство: трафик приходит с настоящих, легитимных серверов. Это реальные DNS-резолверы, реальные серверы времени, реальные игровые серверы. Значит, список блокировок по адресу источника либо закрывает доступ половине страны, либо не действует.

Коэффициенты усиления злоупотребляемых протоколов

Следующие коэффициенты взяты из предупреждения TA14-017A от US-CERT, то есть CISA, «UDP-Based Amplification Attacks», которое пополняется с 2014 года. Это тот источник, на который ссылается вся отрасль.

Таблица объясняет, почему список заблокированных портов в любом аккуратно настроенном файрволе выглядит похоже. То, что вы можете сделать сами, невелико, но важно: проверьте командой ss -lnup, не стоит ли на вашем сервере открытой в сеть служба из этой таблицы. memcached, не привязанный к 127.0.0.1, превращает ваш сервер в оружие против третьих лиц, стоит вам собственной исходящей полосы и заводит ваш IP-адрес в списки блокировок, из которых он выбирается с трудом.

Почему игровые протоколы запросов относятся сюда же

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

Коэффициент усиления протокола Steam с 5,5 низок, у более старого протокола Quake с 63,9 высок. Но действие зависит не от коэффициента как такового, а от размера ответа в конкретном случае: сервер с 200 модами отдаёт заметно больший ответ, чем сервер без них. Bohemia Interactive документирует для Arma 3 в тикете T83469 с 2015 года, что уже 4 Мбит/с поддельных запросов на Steam-query-порт хватало, чтобы подвесить сервер. Четыре мегабита в секунду — это меньше, чем выдаёт один домашний интернет-канал.

Отсюда следует правило, действующее для любой игры: порт запросов ограничивать, а не блокировать. Тот, кто его блокирует, исчезает из браузера серверов, и новые игроки его больше не находят. Какой это порт в каждой игре и насколько узко его можно вести, написано в статьях по конкретным играм ниже, например для Arma 3, CS2 и титулов на Source или Rust.

Случай memcached: 1,35 Тбит/с против GitHub

28 февраля 2018 года GitHub был недоступен с 17:21 до 17:26 UTC и до 17:30 UTC доступен лишь частично. Атака достигла 1,35 Тбит/с при 126,9 миллиона пакетов в секунду и пришла из более чем 1 000 разных автономных систем и десятков тысяч отдельных конечных точек. Усилена она была через memcached, с коэффициентом до 51 000: один байт атакующего порождал до 51 килобайта в сторону цели.

Этот случай до сих пор лучший учебный материал, потому что он показывает три вещи сразу. Первое: усиление сильнее размера ботнета. Атакующему не понадобилось сто тысяч устройств, ему понадобились открытые экземпляры memcached, которых тогда в сети по всему миру стояло более 90 000. Второе: 126,9 миллиона пакетов в секунду — это примерно в 85 раз больше, чем вообще способен перенести канал на 1 Гбит/с. Никакая настройка на сервере этого не меняет. Третье: защита сработала, потому что трафик был перенаправлен в фильтрующую сеть, и время простоя закончилось на девяти минутах, а не на девяти часах.

Откуда берётся ёмкость для DDoS-атаки

Ботнеты из захваченных устройств

Ботнет — это объединение посторонних устройств, захваченных вредоносным ПО, которыми атакующий управляет централизованно. Владельцы, как правило, ничего не замечают, потому что устройство продолжает делать то, для чего его купили. Атакуют прежде всего устройства, которые постоянно висят в сети, редко обновляются и несут стандартные пароли: маршрутизаторы, камеры наблюдения, сетевые видеорегистраторы, телевизионные приставки.

Эталон — Mirai, исходный код которого был опубликован в конце сентября 2016 года. Работа «Understanding the Mirai Botnet» (USENIX Security 2017) отслеживает эту сеть в течение семи месяцев и оценивает максимум в более 600 000 заражённых устройств. Атака на сайт Брайана Кребса в сентябре 2016 года достигла 620 Гбит/с и шла с более чем 175 000 устройств. При атаке на DNS-оператора Dyn 21 октября 2016 года, которая одновременно сделала недоступными Twitter, Spotify и Reddit, было насчитано около 107 000 атакующих IP-адресов.

Девять лет спустя порядок величин другой. Cloudflare связывает рекордную атаку на 31,4 Тбит/с с ботнетом, размер которого оценивается в от одного до четырёх миллионов заражённых устройств, преимущественно телевизионных приставок на Android. В волне атак декабря 2025 года было насчитано 902 гиперобъёмные атаки, в среднем 53 в день, с пиковыми значениями 9 миллиардов пакетов в секунду, 24 Тбит/с и 205 миллионов запросов в секунду. То есть за десятилетие размер ботнета вырос в 5 раз, а достигаемая полоса в 50 раз.

Службы booter и stresser и сколько стоит атака

Между ботнетом и заказчиком сидит служба, которая продаёт атакующую ёмкость по подписке. Такие службы выступают под названиями «booter», «stresser» или «IP-stresser» и утверждают в своих условиях использования, что служат для нагрузочного тестирования собственных систем. При этом они никогда не проверяют, принадлежит ли указанная цель пользователю, и именно в этом разница между инструментом и предложением.

Управление — это веб-интерфейс с тремя полями: цель, порт, длительность. Есть приём платежей, поддержка клиентов и партнёрские программы для перепродажи. Начальные пакеты стоят около 10 до 20 евро в месяц, более крупные пакеты с большей полосой и большей длительностью атаки несколько сотен евро в месяц. Тем самым дан ответ на вопрос, почему задевает и маленькие проекты: атака, которая стоит игровому серверу субботнего вечера, стоит её заказчику меньше двух билетов в кино и никаких технических знаний.

С другой стороны стоит постоянное давление правоохранителей. За неделю действий международной операции PowerOFF в апреле 2026 года органы из 21 страны перехватили 53 домена таких служб, арестовали четырёх человек и провели 25 обысков. При этом следователи получили доступ к данным более трёх миллионов учётных записей пользователей, а более 75 000 опознанных пользователей получили письма. В декабре 2024 года в рамках той же операции было закрыто 27 платформ. То есть тот, кто оплачивает такую службу, оставляет платёжный след в базе данных, которую рано или поздно изымут.

Как распознать DDoS-атаку

Что сообщают пользователи и о чём это уже говорит

Первая информация почти всегда приходит от пользователей, и она полезнее, чем кажется. Четыре сообщения имеют ясный смысл:

• «Всех выкинуло одновременно.» Одновременный обрыв у всех пользователей говорит о канале или о процессе службы, а не об отдельных соединениях. Проблема с нагрузкой задевает пользователей по очереди.
• «Пинг прыгает с 20 на 400 и обратно.» Скачущая задержка при сохраняющемся соединении — это картина переполненной очереди перед целью, а не перегруженного процесса.
• «Список серверов показывает нас офлайн, но подключиться я могу.» Это указание на флуд запросов: порт запросов больше не отвечает, а игровой порт ещё отвечает.
• «Через мобильный интернет я захожу, а со своего домашнего подключения нет.» Разное поведение в зависимости от сети доступа намекает, что насыщен не ваш сервер, а один из путей к нему.

Четыре показателя на сервере

Затем идёт измерение, и именно в таком порядке: интенсивность пакетов, полоса, состояния соединений, счётчики отброшенных пакетов. Показатель загрузки CPU идёт последним, потому что при сетевой атаке он часто остаётся ничем не примечательным.

sar -n DEV 1 10
ip -s link show eth0
ss -s
ss -tn state syn-recv | wc -l
nstat -az TcpExtListenDrops TcpExtListenOverflows TcpExtTCPReqQFullDrop UdpRcvbufErrors UdpInErrors UdpNoPorts
cat /proc/sys/net/netfilter/nf_conntrack_count /proc/sys/net/netfilter/nf_conntrack_max

sar -n DEV 1 10 выдаёт пакеты и байты в секунду по каждому интерфейсу за десять секунд. Решает соотношение: много пакетов при малом числе байт означает маленькие пакеты, то есть протокольную атаку. Мало пакетов при очень большом числе байт означает большие пакеты, то есть атаку с усилением. ip -s link show показывает в колонках dropped и overrun, отбрасывает ли ядро уже сейчас. ss -tn state syn-recv считает полуоткрытые соединения: трёхзначное значение нормально, пятизначное — это SYN-flood. А nstat выдаёт счётчики, которые остаются и после того, как атака закончилась.

Самый важный шаг — тот, который почти никто не делает заранее: собрать базу для сравнения, пока всё работает нормально. Без нормального значения вы не скажете, много ли это, 40 000 пакетов в секунду, или это просто вечер субботы. С apt-get install -y vnstat sysstat измерение идёт постоянно в фоне. Подробная инструкция по разбору полученных значений есть в статье Как определить DDoS-атаку.

Строки в журналах, которые однозначны

Четыре сообщения в журнале ядра и в журнале веб-сервера практически доказательны. dmesg -T | tail -50 показывает первые три:

kernel: TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies.  Check SNMP counters.
kernel: nf_conntrack: nf_conntrack: table full, dropping packet
kernel: net_ratelimit: 2247 callbacks suppressed
nginx: [alert] 1123#1123: 768 worker_connections are not enough

Первая строка означает, что очередь полуоткрытых соединений переполнилась и ядро переключилось на SYN-cookies. Если вместо этого там стоит Dropping request, значит net.ipv4.tcp_syncookies выставлен в 0, и сервер отбрасывает запросы, включая настоящие. Вторая строка означает, что отслеживание соединений заполнено, и с этого момента сервер отбрасывает и легитимный трафик. Третья строка — побочный эффект: ядро подавляет сообщения, потому что иначе было бы занято протоколированием. Четвёртая строка переносит проблему в приложение.

В журнале доступа веб-сервера показательны две вещи. Внезапная доля кода состояния 499 означает, что клиент закрывает соединение, не дождавшись готового ответа, а именно это и делает атака на уровне 7, которая хочет лишь вызвать работу, а не читать результат. И пустое поле Referer почти у всех запросов отличает атаку от настоящего наплыва посетителей, который приносит Referer от поисковых систем и социальных сетей.

Проверка от противного: атака, наплыв или собственная ошибка

Что помогает на самом сервере

На сервере можно добиться большего, чем часто утверждают, и притом против всего, что остаётся небольшим: неаккуратных ботов, одиночных источников, флуда запросов и прикладных атак. Инструменты для этого — nftables, отслеживание соединений, SYN-cookies и ограничение интенсивности по адресу источника. Все дальнейшие указания относятся к Debian 12, Debian 13, Ubuntu 22.04 LTS и Ubuntu 24.04 LTS и написаны для root.

nftables: отбрасывать рано, считать мало

Принцип такой: пакет, который будет отброшен, должен быть отброшен как можно раньше и как можно дешевле. Каждое правило, стоящее перед этим, стоит процессорного времени, помноженного на интенсивность пакетов. Следующий набор правил для /etc/nftables.conf пропускает веб-сервер и игровую службу, а остальное отбрасывает, с ограничением интенсивности для новых TCP-соединений по адресу источника:

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    set adminips {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.10 }
    }

    set newconn {
        type ipv4_addr
        size 131072
        flags dynamic,timeout
        timeout 1m
    }

    chain input {
        type filter hook input priority filter; policy drop;

        iif lo accept
        ct state established,related accept
        ct state invalid counter drop

        ip saddr @adminips tcp dport 22 accept

        tcp dport { 80, 443 } ct state new add @newconn { ip saddr limit rate over 30/second burst 60 packets } counter drop
        tcp dport { 80, 443 } accept

        udp dport 25565 accept

        icmp type echo-request limit rate 5/second accept
        icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert } accept

        counter drop
    }

    chain forward { type filter hook forward priority filter; policy drop; }
    chain output  { type filter hook output  priority filter; policy accept; }
}

Впишите в adminips свой собственный фиксированный адрес, прежде чем загружать набор, иначе закроете себе доступ по SSH. Проверка и включение выполняются так:

nft -c -f /etc/nftables.conf
systemctl enable --now nftables
nft list ruleset
nft list set inet filter newconn

Действие определяют три момента. ct state established,related accept стоит вторым правилом сознательно, чтобы существующие соединения не проходили через весь набор правил. ct state invalid counter drop убирает ошибочные комбинации флагов и запоздавшие фрагменты, и вам не нужно описывать их по отдельности. А counter перед каждым drop — это причина, по которой вы потом знаете, какое правило сработало: если счётчики остаются на нуле, правило не достигается, и это совсем другой диагноз, чем бесполезный набор правил.

SYN-cookies и граница backlog

SYN-cookies — это способ, при котором сервер не запоминает полуоткрытое соединение, а записывает нужные данные в зашифрованном виде в собственный номер ответа. Когда приходит третий пакет установления соединения, он вычисляет состояние обратно. Тем самым очередь больше не переполняется, потому что для таких соединений очереди просто нет.

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192
net.core.netdev_max_backlog = 16384
net.core.rmem_max = 16777216

Эти значения относятся в файл под /etc/sysctl.d/ и применяются командой sysctl --system, иначе после следующей перезагрузки их не будет. В Debian и Ubuntu tcp_syncookies стоит в 1 с завода, и это правильно. Значение 1 означает не «всегда cookies», а «cookies, как только очередь переполняется».

Цена за это реальна и упоминается редко. В cookie нет места для TCP-опций другой стороны. Linux спасает масштабирование окна и выборочное подтверждение только тогда, когда net.ipv4.tcp_timestamps стоит в 1, потому что тогда эти данные едут внутри временной метки. Без временных меток они отпадают, и соединение до конца своей жизни работает медленнее. Кроме того, для максимального размера пакета остаётся лишь три бита, то есть восемь грубых ступеней вместо точного значения. SYN-cookies — это аварийный режим, который спасает соединения, а не настройка для обычной работы.

conntrack: таблица, которая заполняется первой

Отслеживание соединений в ядре заводит запись для каждого потока пакетов, в том числе для UDP, хотя в UDP соединений нет. Именно эта таблица при распределённой атаке становится первым исчерпанным ресурсом, и исчерпывается она очень быстро: при 1,49 миллиона пакетов в секунду, каждый с новым адресом отправителя, таблица на 262 144 места заполняется меньше чем за пятую долю секунды.

net.netfilter.nf_conntrack_max = 524288
net.netfilter.nf_conntrack_udp_timeout = 10
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20

Одна запись занимает около 300 байт, то есть 524 288 записей примерно 150 мегабайт памяти ядра. Размер хеш-таблицы задаётся не через sysctl, а параметром модуля, обычно как четверть верхнего предела, в /etc/modprobe.d/nf_conntrack.conf:

options nf_conntrack hashsize=131072

Для чисто игрового или голосового сервера более элегантное решение — вообще не отслеживать игровой трафик. Это экономит таблицу целиком:

nft add table ip raw
nft add chain ip raw prerouting '{ type filter hook prerouting priority raw; }'
nft add rule ip raw prerouting udp dport 25565 notrack

Внимание: notrack и правила с состоянием исключают друг друга. Тот, кто исключает порт из отслеживания, не вправе больше использовать для этого порта правило с ct state, иначе разрешение перестаёт действовать и служба закрыта.

Ограничение интенсивности по адресу источника

Ограничение интенсивности по адресу источника — самая действенная отдельная мера на сервере, потому что она попадает именно в то, что делает атакующий, и пропускает именно то, что делает пользователь. Разница велика: настоящий браузер серверов опрашивает несколько раз в минуту, атакующий сотни раз в секунду. В nftables для этого работают с динамическими множествами, как в наборе правил выше, а в классическом iptables с hashlimit:

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 27015 -m length --length 0:27 -j DROP

Все цифры в таких правилах — стартовые значения, а не истина в последней инстанции. Сначала померьте неделю в обычном режиме, иначе выбросите собственных пользователей, причём в самый неудачный момент. Учтите также, что просто добавленные правила iptables после перезагрузки исчезают (apt-get install -y iptables-persistent, затем netfilter-persistent save) и что при работе с UFW они относятся в /etc/ufw/before.rules, иначе они пропадут при следующем ufw reload. Полный набор правил для повседневной работы есть в статье Как защитить сервер от DDoS-атак.

Где любая фильтрация на сервере заканчивается

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

Эта таблица отвечает на вопрос, достаточно ли самостоятельной защиты, для каждого отдельного случая. Атака на GitHub с 126,9 миллиона пакетов в секунду по интенсивности пакетов едва укладывается в подключение на 100 Гбит/с, а при объёме 1,35 Тбит/с таких понадобилось бы четырнадцать одновременно. Рекордная атака на 31,4 Тбит/с соответствует 314 полностью насыщенным подключениям на 100 Гбит/с. Игровой сервер обычно висит на 1 Гбит/с или на двух раз по 1 Гбит/с: граница самостоятельной защиты лежит тем самым около 1,5 до 3 миллионов пакетов в секунду, а практически заметно ниже, потому что ядро сдаётся раньше.

Есть и вторая, более неприятная граница. Как только канал насыщен, до вас может не дойти даже та SSH-сессия, из которой вы собирались снимать измерения. Тот, у кого тогда нет доступа независимо от сети, например VNC-консоли в личном кабинете, не сможет даже посмотреть, что происходит.

Что помогает только перед сервером: фильтрация в сети и scrubbing

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

Фильтрация в сети в реальном времени. Весь трафик постоянно идёт через фильтрующую ступень, которая оценивает каждый пакет, прежде чем передать его серверу. Преимущество в том, что нет переключения: защите не нужно сначала распознать атаку, чтобы подействовать. Именно это решает в играх, ведь время переключения в две минуты — это проигранный раунд, а время переключения в две минуты при атаке, которая длится 35 секунд, — это вообще не защита.

Scrubbing. Если сеть распознаёт крупную объёмную атаку, затронутый трафик перенаправляется в фильтрующие центры, там освобождается от вредоносных частей и затем доставляется в сторону цели. Смысл такого перенаправления в близости: атакующий трафик заканчивается там, где он входит, а не только у дата-центра. Правила фильтрации распределяются для этого по сети, технически это описано в RFC 8955 как Flow Specification.

Структурная контрмера против поддельных адресов отправителя, кстати, известна с 2000 года и стоит в RFC 2827, то есть в BCP 38: тот, кто подключает клиента, отбрасывает на этой границе все пакеты, чей адрес отправителя этому клиенту не принадлежит. RFC 3704 расширяет это на сети с несколькими подключениями. Если бы все сетевые операторы это применяли, весь класс атак с усилением был бы закрыт. Он не закрыт, потому что достаточно того, что некоторые этого не делают.

И есть третий метод, который надо знать, потому что его часто продают как защиту: null-routing, технически Remote Triggered Black Hole Filtering по RFC 5635. При нём атакуемый IP-адрес объявляется в сети недостижимым, и весь трафик к нему отбрасывается, атакующий наравне с трафиком ваших пользователей. Это защищает сеть провайдера, а для вас результат ничем не отличается от успешной атаки, обычно ещё на несколько часов после неё. Если сомневаетесь, спросите напрямую: трафик фильтруют или адрес уводят в null-routing. Ответ определяет вашу доступность сильнее, чем любые характеристики железа.

Что KernelHost этому противопоставляет

Постоянная защита, которая входит в каждый серверный тариф

Защита от DDoS в KernelHost построена в два уровня и активна постоянно, вам не нужно ничего включать, заказывать или настраивать:

• Уровень 1: 17 Тбит/с ёмкости mitigation в глобальной scrubbing-сети. Объёмные атаки вычищаются близко к источнику, ещё до того как они дойдут до дата-центра.
• Уровень 2: фильтрация Arbor в реальном времени на 3,2 Тбит/с во Франкфурте-на-Майне. Непосредственно перед сервером распознаются и отбрасываются схемы, характерные для конкретных протоколов, пакет за пакетом.

Решают два свойства. Защита работает постоянно и активна с момента развёртывания сервера, поэтому нет тех первых минут атаки, когда служба недоступна. И null-routing не применяется: ваш IP-адрес остаётся в сети, отбрасываются только вредоносные пакеты. Какие игры и протоколы имеют собственные профили фильтрации, перечисляет статья Защита игровых серверов от DDoS в реальном времени.

Advanced DDoS Protection для проектов под постоянным обстрелом

Некоторые проекты атакуют не время от времени, а прицельно и неделями, каждый вечер в одно и то же время и с меняющимися схемами. Для них есть Advanced DDoS Protection от 50,00 € в месяц, по модели PrePaid, без минимального срока и без платы за подключение. Разница не в большей ёмкости, а в контроле:

• Выделенный защищённый IP-адрес из франкфуртского ядра сети, на который ваш сервер переводится внутри нашей сети. С вашей стороны ничего перестраивать не нужно.
• Самостоятельно управляемые правила защиты по портам и протоколам в личном кабинете: вы отдельно задаёте, что разрешено на игровом порту и что на порту запросов, и можете тем самым использовать ровно ту асимметрию, о которой шла речь в разделе про протоколы запросов.
• Изменения вступают в силу в реальном времени, поэтому подстраивать их можно прямо во время идущей атаки, а не ждать окна обслуживания.
• Профиль защиты под конкретную службу, равно как и для модифицированных и собственных приложений на любых портах TCP или UDP.

Advanced DDoS Protection рассчитана на клиентов KernelHost и предполагает сервер в KernelHost. Если ваш проект сейчас работает в другом месте и там регулярно оказывается под атакой, путь — это переезд сюда, а не дистанционное обслуживание вашего прежнего адреса.

Сравнение двух уровней

Шесть реально отфильтрованных атак из эксплуатации

Следующие шесть атак пришли на серверы клиентов KernelHost и были полностью отфильтрованы в реальном времени, каждая без простоя. Изображения взяты из живого мониторинга защиты.

Голосовой сервер TeamSpeak 3, порт 9987 UDP. Комплексная атака с несколькими одновременными схемами, более 473,4 Гбит/с и более 41,5 миллиона пакетов в секунду. Это примерно 28-кратная интенсивность пакетов подключения на 1 Гбит/с.

Игровой сервер ARK, порт 7777 UDP. Простой UDP-flood без сложной структуры, зато более 112,2 Гбит/с и более 8,7 миллиона пакетов в секунду. Как при этом защищается сам ARK-кластер, описано в статье Защита ARK-сервера от DDoS-атак.

Атака по всем портам, порты 0-65535 TCP и UDP. Более двенадцати разных основных схем атаки против всех портов одновременно, в сумме более 21,3 Гбит/с и более 3,9 миллиона пакетов в секунду. Этот случай показывает то же распределение по всем портам, которое есть и в случае Cloudflare от мая 2025 года со в среднем 21 925 портами назначения.

Minecraft и OpenVPN, порты 25565 TCP и 1194 UDP. Комбинированная атака с более чем шестнадцатью разными основными схемами, более 4 миллионов пакетов в секунду и более 8,6 Гбит/с. Обе службы оставались доступными постоянно, хотя говорят на разных протоколах.

UDP-flood на отдельный порт службы, восемь минут. Самый тяжёлый из шести случаев: 745,5 Гбит/с и 73,1 миллиона пакетов в секунду, примерно 49-кратная интенсивность пакетов подключения на 1 Гбит/с. 99,93 процента трафика приходилось на один единственный порт назначения, источники были полностью распределены. Через восемь минут атака закончилась, служба оставалась доступной постоянно.

Непрерывная атака на протяжении трёх часов и 31 минуты. 501,2 Гбит/с и 43,9 миллиона пакетов в секунду, причём не как одиночный пик, а как череда волн без паузы. Семь схем атаки одновременно, среди них усиление через SSDP, MS SQL RS, L2TP и RIPv1. Порты назначения были рассеяны по всему диапазону от 1024 до 65535, то есть смена порта ничего бы не дала. Подробнее об обоих случаях в статье Сколько длится DDoS-атака.

Что делать во время атаки, и именно в таком порядке

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

1. Измерять, а не крутить настройки. Сначала сохраните в файл значения из sar -n DEV 1 10, ip -s link show, ss -s и dmesg -T. После атаки их уже не будет, а без них вам никто не поможет.
2. Не перезагружать. Перезагрузка стирает все счётчики, все состояния соединений и любое доказательство, а нагрузка возвращается через считанные секунды.
3. Установить, какой это уровень. Байты, поделённые на пакеты, дают средний размер пакета. Меньше 100 байт указывает на протокольную атаку, больше 1 000 байт на атаку с усилением, обычные размеры при высокой загрузке CPU на уровень 7.
4. Закрыть административные порты. Панель, база данных, RCON и всё, что не обязано быть публичным, относится к ограничению по вашему собственному адресу. Это сразу и без риска для пользователей уменьшает площадь атаки.
5. Выставить ограничение интенсивности: узко на порт запросов, широко на рабочий порт. Не блокируйте порт запросов, иначе исчезнете из любого списка серверов.
6. Не менять собственный адрес поспешно. Смена адреса действует лишь до тех пор, пока новый адрес снова не стоит публично, а забытая старая DNS-запись обесценивает смену.
7. Подключить провайдера с числами на руках. Откройте тикет с указанием времени, порта назначения, интенсивности пакетов, полосы и среднего размера пакета. Эти пять данных определяют, насколько быстро правила фильтрации для вашего адреса будут подстроены.
8. После этого задокументировать. Зафиксируйте, когда всё началось, сколько длилось и какая это была схема. Повторяющиеся атаки в одно и то же время — это и есть критерий того, нужен ли проекту выделенный защищённый IP-адрес.

Подробный порядок действий для мощной, длительной атаки есть в статье Мощная DDoS-атака: что делать.

Правовая сторона: DDoS-атака — это уголовное преступление

В Австрии DDoS-атака подпадает под § 126b Уголовного кодекса (StGB), «Нарушение работоспособности компьютерной системы». Основной состав предусматривает лишение свободы до шести месяцев или денежный штраф до 360 дневных ставок. Если нарушение длится продолжительное время, то до двух лет. Если множество систем атакуют программой, явно созданной для этого, то до трёх лет. А при ущербе свыше 300 000 евро, при атаке на критическую инфраструктуру или в составе преступной организации рамки составляют от шести месяцев до пяти лет. Дополнительно § 126c StGB объявляет уголовно наказуемыми уже изготовление, распространение и предоставление доступа к предназначенным для этого программам.

В Германии действует § 303b StGB, «Компьютерный саботаж»: до трёх лет лишения свободы или денежный штраф, до пяти лет, если обработка данных служит предприятию, организации или органу власти, и в особо тяжких случаях от шести месяцев до десяти лет, например при совершении в виде промысла или при затрагивании критической инфраструктуры. Покушение наказуемо, а в отношении подготовительных действий § 303b абз. 5 StGB отсылает к § 202c StGB.

Поэтому службы booter и stresser — это не серая зона, а оплаченная часть уголовного преступления. Три момента при этом регулярно понимают неверно. Во-первых, оговорка «только для нагрузочного тестирования собственных систем» ничего не делает законным, потому что эти службы не проверяют, кому принадлежит указанная цель. Во-вторых, наказуем и заказчик, а не только оператор: Европол после недели действий в апреле 2026 года целенаправленно написал более 75 000 опознанным пользователям, чтобы прояснить именно это. В-третьих, нагрузочное тестирование собственного сервера через такую службу тоже не выход, потому что атакующий трафик идёт через сеть провайдера, а значит и по каналам других клиентов, что запрещает любой договор хостинга. Тот, кто действительно хочет измерить устойчивость своей службы, делает это с предварительным уведомлением и по согласованию с провайдером. Этот раздел передаёт состояние законодательства и не является юридической консультацией.

Подходящее руководство для вашей службы

Эта статья объясняет принцип. Какой порт должен быть открыт, какая директива конфигурации ограничивает какой запрос и где лежит граница в конкретной игре: это написано в статьях по отдельным службам, каждая с таблицей фактов по портам.

• Основы и порядок действий: Как определить DDoS-атаку, Как защитить сервер от DDoS-атак, Мощная DDoS-атака: что делать, Защита игровых серверов от DDoS с фильтрацией в реальном времени
• Minecraft и голос: Minecraft и nullping, Minecraft Bedrock, TeamSpeak 3, Hytale
• Ролевые проекты на базе GTA: FiveM, RedM, RAGE MP и alt:V, SA-MP и open.mp, MTA:SA
• Выживание и строительство: Rust, ARK, DayZ, Palworld, Conan Exiles, Project Zomboid, Terraria, Unturned
• Тактика и шутеры: CS2 и Source, Arma 3, Call of Duty, Team Fortress 2, Left 4 Dead 2, Garry's Mod, Mordhau, Lineage 2

Коротко о главном

• DDoS-атака занимает один из четырёх конечных ресурсов: полосу, интенсивность пакетов, таблицу состояний ядра или процессорное время приложения. Уязвимость она не использует, поэтому одни обновления не защищают.
• RFC 4732 определяет DoS-атаку через результат, а не через число источников. Распределённой она называется, когда источников много: в случае Cloudflare от мая 2025 года их было 122 145 адресов из 161 страны.
• CISA, FBI и MS-ISAC различают три техники: объёмную в Гбит/с, протокольную в пакетах в секунду, прикладную в запросах в секунду. Каждой нужна своя защита.
• Атаки с усилением злоупотребляют открытыми UDP-службами. Коэффициенты доходят от 5,5 у протокола Steam через 30,8 у SSDP и 556,9 у NTP до 51 000 у memcached, это можно прочесть в US-CERT TA14-017A.
• Ёмкость берётся из ботнетов захваченных устройств, от 600 000 у Mirai в 2016 году до оцениваемых от одного до четырёх миллионов за рекордной атакой на 31,4 Тбит/с, и перепродаётся начиная примерно от 10 евро в месяц.
• На сервере действуют nftables, SYN-cookies, подстроенные пределы conntrack и ограничение интенсивности по адресу источника. Они заканчиваются около 1,5 миллиона пакетов в секунду, потому что подключение на 1 Гбит/с большего не переносит.
• Выше этой границы решает исключительно фильтрация в сети перед сервером. Null-routing — это не защита, а тот результат, которого хотел атакующий.
• В KernelHost двухуровневая постоянная защита входит в каждый серверный тариф без доплаты и активна с момента развёртывания, без null-routing: 17 Тбит/с ёмкости mitigation в глобальной scrubbing-сети плюс фильтрация Arbor в реальном времени на 3,2 Тбит/с во Франкфурте-на-Майне. Advanced DDoS Protection дополняет её от 50,00 € в месяц выделенным защищённым IP-адресом и самостоятельно управляемыми правилами по портам.
• DDoS-атака наказуема в Австрии по § 126b StGB и в Германии по § 303b StGB, причём как для заказчика, так и для оператора таких служб.

Если ваш проект уже работает в KernelHost, фильтрация активна, и делать для этого ничего не нужно. Если вы всё же замечаете странности, откройте тикет в поддержку с пятью данными из шага 7, чтобы правила фильтрации подстроили под ваш IP-адрес. Во время идущей атаки с нами дополнительно можно связаться через экстренный чат WhatsApp по номеру +43 650 8209883.