Защита от DDoS-атак для банков и операторов Центральной Азии

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

Из этого различия вытекает вся дальнейшая логика закупки, и оно же объясняет, почему тендеры на защиту от DDoS так часто заканчиваются неудачно. Тендер, который начинается с вопроса «сколько гигабит вы фильтруете», получает ответ в гигабитах и покупает ёмкость. Ёмкость не отвечает ни за один конкретный сервис, не ограничена по задержке, ничего не доказывает после инцидента и не говорит, что произойдёт, когда одна из сторон отношений исчезнет. Этот материал написан для банков, платёжных организаций, операторов связи и хостинг-провайдеров Центральной Азии и предлагает другой порядок вопросов.

Банк покупает не гигабиты, а выполнение обязательства

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

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

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

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

Что уровень очистки обязан увидеть, чтобы вообще работать

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

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

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

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

Концентрация: очистка, транзит и доказательства в одной юрисдикции

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

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

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

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

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

Два уровня и две зоны ответственности

Работающая конструкция для надзорной организации почти всегда состоит из двух уровней, и спор о том, какой из них «лучше», бессмысленен: они отвечают на разные вопросы.

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

Уровень on-premise в разрыв отвечает за всё остальное. Он присутствует в тракте постоянно, поэтому у него нет шага передачи, которого нужно дожидаться. Он видит атаки, которые слишком малы, чтобы запустить перенаправление, но достаточно точны, чтобы исчерпать таблицы состояний межсетевого экрана или пул соединений балансировщика. Он работает на уровне приложений там, где решение требует знания вашей бизнес-логики: какие URL дорогие, какая последовательность запросов невозможна для настоящего клиента, какой темп нормален для вашей клиентской базы. И он оставляет записи об инциденте у вас.

Что должно быть закреплено	Вышестоящий уровень	Уровень on-premise
Потоки выше полосы канала доступа	Единственный, кто способен помочь	Не поможет: канал переполняется раньше
Атаки ниже линии канала	Обычно не видны, нет причины включаться	В зоне ответственности постоянно
Истощение состояний на периметре	Только после завершения перенаправления	Поглощается до таблиц МЭ и балансировщика
Логика уровня приложений	Общие профили, ограниченное знание сервиса	Правила, привязанные к вашим маршрутам и API
Хранение записей об инциденте	Формат, детализация и срок поставщика	Ваш захват, ваша политика хранения
Кто назначает испытание	Совместное изменение с поставщиком	Вы, в своё окно обслуживания

Связь между уровнями должна быть стандартной, а не проприетарной. Сигнализация об атаке и запрос на вмешательство описаны в DOTS: архитектура — в RFC 8811, сигнальный канал — в RFC 9132. Точечные правила фильтрации распространяются через BGP FlowSpec, RFC 8955 и RFC 8956. Смысл требовать стандартный интерфейс простой: пока стык описан общедоступным документом, замена любого из двух уровней остаётся работой по конфигурации. Как только стык проприетарный, вы купили не два уровня, а один, разделённый на две коробки.

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

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

Что дополнительно нужно оператору, который продаёт защиту вниз

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

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

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

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

Отдельно стоит упомянуть гигиену, которая делает оператора хорошим соседом и заодно уменьшает объём мусора, покидающего его сеть: фильтрация по адресу источника на границе, описанная в RFC 2827. Она не защищает вас саму по себе, но именно её наличие делает осмысленным разговор с другими операторами, когда помощь понадобится вам.

Задержка на платёжных маршрутах измеряется перцентилями

Любая защита что-то добавляет к времени ответа. Вопрос не в том, добавляет ли, а в том, сколько именно и в каком месте распределения.

Средняя задержка для платёжного маршрута — почти бесполезная величина. Транзакция срывается не тогда, когда среднее выросло, а тогда, когда конкретный запрос не уложился в таймаут. Живёт этот запрос в хвосте распределения, и именно хвост чувствителен к перенаправлению трафика: маршрут через удалённый центр очистки добавляет географию в обе стороны, а обратное плечо иногда идёт не тем же путём, что прямое. Поэтому измерять нужно p50, p95, p99 и p99.9, снимать их на настоящем транзакционном маршруте, а не на служебной странице проверки доступности, и делать это в двух состояниях: в спокойном режиме и при активном перенаправлении на вышестоящий уровень.

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

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

Доказательства собираются во время атаки, а не после

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

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

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

Передачу между уровнями нужно репетировать

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

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

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

Что вписать в тендер как измеримые критерии приёмки

Требование, которое нельзя проверить на стенде, в тендере не работает. Ниже — формулировки, которые проверяются.

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

Бюджет задержки. «Для каждого названного сервиса p95 и p99 не превышают указанных значений в спокойном режиме и в режиме перенаправления.» Проверяется под нагрузкой, в обоих состояниях.

Стандартная сигнализация. «Уровень on-premise взаимодействует с вышестоящим уровнем средствами DOTS или BGP FlowSpec с указанием версий и опций.» Проверяется совместным тестом с оператором, а не галочкой в опроснике.

Разделение арендаторов. Для операторов: «Изменение политики одного арендатора не изменяет показатели остальных; отчётность выгружается в разрезе арендатора в машиночитаемом формате.» Проверяется параллельной нагрузкой по двум профилям.

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

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

Честный противовес

Методика, у которой всегда один ответ, — не методика. Четыре оговорки.

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

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

Разнесение по юрисдикциям снижает корреляцию, а не экспозицию. Вы по-прежнему зависите от внешних сторон; вы лишь перестаёте зависеть от них одновременно и по одной причине. Называть это суверенитетом преждевременно.

Соразмерность. У регионального хостинг-провайдера без западных контрагентов и у банка, ведущего расчёты в нескольких валютах, расчёт риска разный. Применяйте эту методику пропорционально тому, во что вам обойдётся простой, и относитесь скептически к любому производителю, включая нас, который предлагает считать её универсальной.

Источники и что запросить

Мы не пересказываем платные отчёты и не приписываем им цифры.

Стандарты, которые стоит назвать в техническом задании. RFC 8811 (архитектура DOTS) и RFC 9132 (сигнальный канал DOTS); RFC 8955 и RFC 8956 (BGP FlowSpec); RFC 2827 (фильтрация по адресу источника на границе сети). Эти документы общедоступны, и ссылка на них в тендере переводит разговор о совместимости из области заверений в область проверяемого.

Управление рисками цепочки поставок. NIST SP 800-161 остаётся ближайшим к нейтральному методическим документом для описанного выше анализа зависимостей. Для процедур непрерывности деятельности и их испытаний практикой закрепился ISO 22301.

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

Аналитическое покрытие категории. Market Guide for DDoS Mitigation Solutions от Gartner, The Forrester Wave: DDoS Mitigation Solutions и IDC MarketScape описывают ландшафт производителей; запрашивайте актуальные редакции напрямую и рассчитывайте, что анализ размещения, задержки и доказательной базы вам придётся проводить самостоятельно. Там, где производитель публично цитирует Gartner, требуются права на перепечатку, и попросить их показать вполне уместно.