Что DDoS делает с вашим сервером и с вашим провайдером

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

Две атаки под одним словом — и почти ничего общего

У атаки, направленной на отказ в обслуживании, ровно одна цель — исчерпать какой-то ресурс до нуля, чтобы его не осталось никому другому, — и вся суть вопроса упирается в то, какой именно ресурс. Именно этот выбор решает, кто способен остановить атаку, где и какой ценой. Это не спектр. Есть два семейства атак, их останавливают разные стороны разным оборудованием, а провайдер, отвечающий на вопрос одним числом, говорит только об одном из них и умалчивает о другом.

Первое семейство атакует канал и трубы. Потоки UDP, потоки пакетов SYN, отражённый трафик от неверно настроенных серверов где-то ещё в интернете. Ему всё равно, что у вас запущено. Оно не знает, держите вы форум или зеркало git, оно никогда не доходит до вашего приложения, а в большинстве случаев вообще не доходит до вашей машины — оно забивает канал или исчерпывает таблицу в маршрутизаторе где-то выше вас. Поскольку такому трафику всё равно, что внутри, его может распознать и отбросить тот, кто вообще не читает содержимое вашего трафика. Именно поэтому эту атаку можно решить выше по цепочке, и именно поэтому эта половина достаётся бесплатно.

Второе семейство атакует ваше приложение. Запросы, каждый из которых по отдельности безупречен: корректное рукопожатие TLS, валидный HTTP, существующий URL. Ваш сервер рад их принять. Падает база данных за строкой поиска или хеширование пароля за формой входа — и падает она при частоте запросов, которую ваш график трафика едва ли заметит. Здесь нет сигнатуры для сравнения, потому что ни с одним отдельным запросом ничего не так. Единственное, что отличает атаку от обычного дня, — это намерение, а намерение не записано отдельным полем в заголовке пакета.

Шесть форм атаки: что каждая исчерпывает и кто способен её остановить

Что приходит	Фильтруется выше по сети	Ваша забота	Что именно исчерпывается и где это останавливают на самом деле
Отражённый флуд UDP	Да	Нет	Пропускную способность канала. Трафик массовый, поддельный и безразличный к тому, что вы запустили, поэтому его может отбросить тот, кто вообще не видит, что внутри, — но только за счёт мощности, расположенной выше того канала, который атака должна была забить. Когда канал уже забит, не поможет ничего — ни на границе сети провайдера, ни на вашей машине.
SYN-флуд	Да	Частично	Таблицу состояний соединений, а не полосу пропускания. Полуоткрытые соединения дёшево отправлять и дорого помнить. Фильтруется на границе сети, а по большей части обезвреживается уже вашим собственным ядром: SYN cookies включены в Linux по умолчанию уже много лет, и большинству никогда не приходилось об этом узнавать.
Флуд мелких пакетов	Да	Нет	Плоскость пересылки пакетов. Маршрутизаторы и сетевые карты рассчитаны в пакетах в секунду, и поток мелких пакетов бьёт именно по этому показателю, а не по полосе пропускания. Останавливается выше по сети, аппаратно. Именно эта атака выводит из строя файрвол, пока график трафика выглядит совершенно спокойным.
Атаки с медленными заголовками и медленным телом запроса	Нет	Да	Рабочие слоты. Несколько сотен соединений, открытых и подпитываемых затем по одному байту, удерживают сервер с моделью «поток на соединение» открытым, пока у него не кончатся потоки. Решается тайм-аутами и лимитом числа соединений с одного адреса на вашем обратном прокси; событийно-ориентированный фронтенд гасит это почти случайно.
Флуд HTTP-запросов	Нет	Да	Ваш процессор и вашу базу данных. Цель — дорогая по вычислениям конечная точка: поиск, вход, корзина, всё, что пишет в базу, — и достаточно нескольких тысяч запросов в секунду. Останавливается внутри вашего приложения либо внутри прокси, которому вы сознательно доверили расшифровку своего трафика. Третьего места нет.
Скрапинг и подстановка чужих учётных данных	Нет	Да	Всё сразу, но медленно. Формально это вообще не атака на доступность, но выглядит она в точности как атака, и примерно в половине случаев её так и описывают. Останавливается вашими собственными ограничениями скорости — по конечной точке и по учётной записи. Защита, купленная от неверного диагноза, — самая дорогая защита из всех.

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

Мера защиты, которая доделывает работу за атакующего

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

Механизм стандартизирован и полностью публичен. RFC 7999, опубликованный IETF в октябре 2016 года, описывает известное транзитивное сообщество BGP с именем BLACKHOLE, зарегистрированное в IANA под кодом 0xFFFF029A — документ сухо отмечает, что младшие два октета в десятичной записи равны 666. Его семантика умещается в одно предложение: наличие этого сообщества — «рекомендательное указание отбрасывать любой трафик, направленный на этот префикс». Оно может служить триггером в конфигурации удалённо инициируемой чёрной дыры, технике, описанной в RFC 5635 ещё в 2009 году. Любая мало-мальски компетентная сеть делает это за секунды, с одного маршрутизатора, бесплатно.

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

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

Второй признак — продаётся ли защита отдельным тарифом. «Защищённый IP» за дополнительную ежемесячную плату — это прямое признание, что обычный адрес не защищён, а с незащищённым адресом под нагрузкой сеть делает ровно одну вещь. Фильтрация, которая действительно происходит выше по сети, стоит одинаково независимо от того, защищает она одного клиента или всех сразу, и именно поэтому плата за адрес — решение о ценообразовании, а не инженерное решение. Наша собственная позиция по этому вопросу в том, что фильтрация включена по умолчанию на каждом порту и ничего не нужно активировать, и что мы скорее позвоним вам, чем отправим в чёрную дыру, — и это обещание чего-то стоит именно потому, что его можно проверить, а ещё потому, что на той же странице опубликованы цифры мощности, на которые оно опирается.

Арифметика выше по сети и почему пакеты важнее битов

Объёмные атаки не требуют изобретательности и не требуют ботнета. Им нужны серверы, которые отвечают на маленький вопрос большим ответом, а таких серверов в интернете полно. CISA публикует таблицу коэффициентов усиления по протоколам: DNS отвечает в 28–54 раза больше, чем у него спросили, NTP — в 556,9 раза, SSDP — в 30,8, CharGEN — в 358,8, CLDAP — в 56–70 раз. Открытые наружу серверы memcached отвечают в диапазоне от 10 000 до 51 000 раз больше запрошенного. Поскольку UDP не проверяет, кто на самом деле задал вопрос, ответ уходит на тот адрес, который атакующий указал в запросе, — то есть на ваш.

Стоит один раз перемножить числа, и маркетинг перестаёт иметь смысл. Одна-единственная машина на обычном гигабитном аплинке, направленная на достаточное число открытых серверов memcached, способна обрушить на цель терабиты трафика. Атакующий при этом ничего не арендует и ничего не взламывает. Именно поэтому единственная цифра мощности, которая хоть что-то значит, — это мощность выше транзита вашего провайдера, а не на его границе. Если у хостинга 20 Гбит/с транзита и 20 Гбит/с оборудования для очистки трафика в собственной стойке, то поток в 21 Гбит/с забивает транзитный канал, и страдают все, кто за ним стоит, — фильтрация при этом настоящая, настроена правильно, но находится не по ту сторону узкого места. Фильтрация должна происходить там, где для неё ещё есть запас, а значит, её должны выполнять операторы верхнего уровня, а значит, ваш провайдер должен был заранее договориться об этом с людьми, которых вы никогда не встретите.

Второй арифметический момент — тот, на котором спотыкаются даже опытные люди. Сетевое оборудование рассчитывается в пакетах в секунду, а не в битах. Один гигабит из пакетов по 1500 байт — это около 81 000 пакетов в секунду, то есть ничто. Тот же гигабит, набранный из пакетов по 64 байта, — это уже около 1,5 миллиона пакетов в секунду: в восемнадцать раз больше работы при той же полосе пропускания. Поток, рассчитанный именно на это число, положит файрвол, виртуальный коммутатор или небольшой маршрутизатор, пока график трафика, на который вы смотрите, показывает лишь небольшой всплеск и никаких причин для тревоги. Поэтому «у нас десять гигабит» — не ответ ни на один вопрос, который стоило бы задавать.

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

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

Седьмой уровень и цена его фильтрации

Всё, о чём шла речь выше, останавливается на транспортном уровне — и ровно там же заканчивается всё, что ваш провайдер способен сделать для вас без вашего разрешения. Флуд HTTP-запросов идёт внутри вашей сессии TLS. Никто выше по сети не видит ни URL, ни метод, ни заголовки, ни тело запроса — именно для этого и нужно шифрование, и оно работает. Чтобы фильтровать такой трафик, провайдеру пришлось бы его расшифровывать, а провайдер, способный расшифровать ваш трафик, обладает возможностью, которую не переживёт ни один довод о юрисдикции, ни одна схема шифрования диска и ни одна политика конфиденциальности.

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

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

Непарадная половина седьмого уровня дешевле и работает без всякого стороннего поставщика. Кешированный ответ, отданный анонимному посетителю, стоит вам почти ничего, поэтому агрессивное кеширование превращает большую часть флуда в незаметное событие. Ограничения скорости имеет смысл ставить на дорогие конечные точки, а не на весь сайт целиком, потому что главная страница никогда не была целью. Всё, что достаточно медленно, чтобы его имело смысл атаковать, обычно стоит и оптимизировать в любом случае. А статичная резервная страница — на другом адресе, прямо сообщающая, что сервис атакован и когда стоит попробовать снова, — приносит вашим пользователям во время инцидента больше пользы, чем любое количество инфраструктуры, которая молча отказывает.

Что решить заранее, в порядке ценности

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

1. Прочитайте пункт о злоупотреблениях до покупки (10 мин). Найдите абзац о трафике, направленном на ваш сервис, и прочитайте, что провайдер оставляет за собой право сделать. Если там написано, что он может обнулить маршрут по своему усмотрению без обязательства вас уведомлять, — это и есть реальный продукт, что бы ни писала страница с тарифами, и теперь вы знаете это бесплатно.
2. Выясните, входит ли фильтрация в тариф или продаётся отдельно (5 мин). Если это платное дополнение, то по умолчанию вас ждёт чёрная дыра; спросите, что происходит с адресом на обычном тарифе, пока атака продолжается, и насколько быстро можно подключить платную защиту. «В момент атаки» — не ответ, потому что BGP не сходится по вашему расписанию.
3. Разделите то, что обязано работать всегда, и то, что может упасть (один вечер). Статичный сайт и страница статуса на одном адресе, приложение — на другом. Когда приложение под флудом запросов, ваши пользователи всё равно получают что-то настоящее вместо тайм-аута, а у вас остаётся канал, чтобы сообщить им, что происходит.
4. Поставьте кеш перед всем, что доступно анонимно (один вечер). Это самая ценная из всех доступных мер защиты на уровне приложения, она ничего не стоит ежемесячно и делает ваш сервис быстрее во все дни, когда его никто не атакует, — а таких дней у вас все, кроме одного.
5. Ограничивайте скорость по конечной точке, а не по сайту целиком (один час). Вход, поиск, регистрация, сброс пароля — всё, что пишет в базу данных или отправляет почту. Общий лимит, достаточно щедрый для загруженной главной страницы, окажется слишком щедрым для формы входа.
6. Узнайте порядок эскалации и хоть раз им воспользуйтесь (20 мин). Выясните, кто доступен в три часа ночи, по какому каналу связи и как вас там идентифицируют. Очередь тикетов с ответом на следующий рабочий день — это не порядок эскалации; узнать это уже посреди инцидента — верный способ превратить один плохой час в плохую неделю.

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

Шесть вопросов для тех, кто продаёт «защиту от DDoS»

На все шесть вопросов может письменно ответить, ещё до того как деньги перейдут из рук в руки, любой, кто на самом деле управляет собственной сетью. Сама готовность отвечать уже говорит о многом.

• Фильтрация происходит выше вашего транзита или на границе вашей сети? Любая мощность на уровне транзита или ниже защищает оборудование провайдера, а не доступность клиента. Эти два числа что-то значат только вместе.
• При каких условиях вы обнуляете маршрут клиента и звоните ли вы сначала? Единственный вопрос из этого списка, ответ на который нельзя угадать заранее, и именно он определяет, как будет выглядеть ваш худший день.
• Это входит в тариф или продаётся отдельно? Если отдельно — спросите, что в это время защищает адреса без такой опции. Ответ ровно один, и это предыдущий вопрос.
• Защита постоянная или включается по срабатыванию — и сколько времени проходит до первого чистого пакета? Всё, что измеряется в минутах, защищает только от продолжительных кампаний, а таких — меньшинство.
• Что вы делаете с седьмым уровнем, если не можете прочитать мой TLS? Правильный ответ — это вариация на тему «ничего, а вот кто может, и вот как закрыть ваш исходный сервер так, чтобы это имело значение». Любой ответ, который обходит это ограничение стороной, стоит перечитать дважды.
• Как выглядела последняя атака, которую вы отражали? Объём, длительность, вектор, что именно вы сделали. У сети, которая пропускает через себя настоящий трафик, всегда есть истории; у той, что никогда не сталкивалась с атакой, нет и процедуры на этот случай.

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

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

Написано инженерами, которые управляют платформой, и перечитано 1 месяц назад. Если здесь что-то неверно или устарело, сообщите об этом из панели — именно оттуда пришла примерно половина этих материалов.