IBANK2RU MITIGATOR CLOUD LLC продаёт арендуемые мощности, которые по-прежнему зависят от стоек, транзита и ремонтных окон

Кратко

• Публичный след идентификации надёжный. В RIPE объект ORG-IL186-RIPE связан с MITIGATOR CLOUD LLC в Москве, AS51464 называется IBANK2RU, AS43048 — mitigator-cloud, и текущие данные RIPEstat показывают обе ASN анонсированными 12 июля 2026 года.
• Публичный след сервиса указывает на мощности по очистке от DDoS, а не на обычный самостоятельный VPS. Mitigator Cloud описывает российский круглосуточный сервис для корпоративных клиентов, банков, IT-компаний и сервис-провайдеров с перенаправлением трафика через смену A-записи, постоянный или атако-ориентированный BGP-анонс, префиксы провайдера, L2-туннель и обратный прокси.
• Основной риск зависимостей — физический и операционный. Клиенты полагаются на узлы очистки, порты маршрутизаторов, аплинк-мощности, политику префиксов, изменения DNS или BGP, каналы возврата чистого трафика, полномочия поддержки, окна обновлений, процедуры резервного копирования и доступность инженеров во время атак.
• Степень доказательности — средняя. Идентичность и маршрутизация хорошо подтверждены открытыми источниками; данные о площадках, стойках, резервных мощностях, тестах восстановления и переносимости клиентов в открытом доступе ограничены.

Полезный вопрос начинается с iBank2.RU

В заголовке этого профиля используется необычное составное название IBANK2RU MITIGATOR CLOUD LLC, потому что так же поступают открытые источники. Автономная система, назначенная в 2010 году, названа не в честь современного облачного бренда.Запись RIPE aut-num для AS51464называет сетьIBANK2RU, связывает её с ORG-IL186-RIPE и указывает AS-set с именемAS-IBANK2RU. Объект маршрута для109.232.248.0/21описывает префикс какIBANK2.RU, Ltd.по адресу Нижняя Первомайская улица, 46, Москва, с origin-AS51464. Тот же адрес фигурирует в организационной записи RIPE для MITIGATOR CLOUD LLC.

Этот более старый след iBank2.RU важен, потому что сервис, который сейчас продаётся под брендом Mitigator Cloud, позиционирует себя как преемника функции очистки трафика, а не как облачную платформу с чистого листа.Главная страница Mitigator Cloudсообщает, что в 2009 году был создан компетентный центр по защите от DDoS, в 2010 году — центр очистки трафика iBank2.RU, а в 2015 году центр очистки iBank2.RU перевели на внутреннее решение MITIGATOR и переименовали в Mitigator Cloud. Это заявления самой компании, поэтому их не следует считать независимым доказательством каждой детали эксплуатации. Тем не менее они важны для понимания того, чем должны быть арендуемые мощности: местом, куда можно перенаправить клиентский трафик, проверить его, отфильтровать и вернуть чистым.

Иными словами, риск не только в том, загрузится ли виртуальная машина. Риск в том, останется ли защищённый сервис доступным, когда появляется враждебный трафик и управление трафиком меняется под давлением. Клиент может полагаться на Mitigator Cloud, потому что приложение защищено обратным прокси, потому что префикс можно анонсировать в сторону сервиса очистки, потому что можно переключить A-запись, потому что туннель возвращает очищенный трафик клиенту или потому что сервис-провайдер использует мощности Mitigator за своим собственным клиентским договором.

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

Открытые данные позволяют считать IBANK2RU MITIGATOR CLOUD LLC реальной сетевой зависимостью для сервисов. Они не позволяют считать её полностью прозрачным, независимо проверенным мультисайтовым облаком. Это различие — суть статьи. Компания может быть важной, даже когда открытые источники не раскрывают её стойки. Отсутствие доказательств на уровне стоек — это не доказательство их отсутствия; это проблема due diligence покупателя.

Юридическая и сетевая идентичность яснее, чем идентичность стоек

Юридически-сетевая идентичность — самая сильная часть досье.Объект организации ORG-IL186-RIPEидентифицирует MITIGATOR CLOUD LLC, страна RU, московский адрес: Нижняя Первомайская ул., 46, почтовый индекс 105203, телефон +7 495 965 15 64. Объект указываетEXH1-RIPEкак контакт по злоупотреблениям иMNT-IBANK2RUкак одного из мейнтейнеров. Запись создана в ноябре 2009 года и последний раз изменена в мае 2026 года.

Объект мейнтейнера MNT-IBANK2RUтоже полезен, так как показывает преемственность. Он создан в ноябре 2009 года и последний раз изменён в мае 2026 года.Ролевой объект EXH1-RIPEназываетсяiBank2RU Admin, содержит тот же московский адрес и указывает почтовый ящик [email protected]. Это не маркетинговые детали. Это данные реестра, которые связывают старое имя iBank2.RU, текущее юридическое название Mitigator Cloud и публичный след интернет-номеров.

AS51464 — более узкая сеть iBank2.RU. RIPE показывает её назначенной, созданной 31 августа 2010 года и последний раз изменённой в июне 2022 года. В политике импорта и экспорта упоминаются московский route server AS8631, AS42861, AS29226, AS43048 и AS207104.Запись RIPE RDAP для AS51464подтверждает имя AS IBANK2RU, диапазон единичного выделения AS, дату регистрации 2010 года и ссылки на регистранта ORG-IL186-RIPE и MNT-IBANK2RU.

AS43048 — более широкая сеть Mitigator.Запись RIPE aut-num для AS43048использует имя ASmitigator-cloud, связывает его с ORG-IL186-RIPE и перечисляет политику с RETN AS9002, SpaceWeb AS202984, COMCOR AS8732, московским route server AS8631, AS51464 и несколькими ASN, похожими на клиентские или пиринговые. Дата последнего изменения — 18 июня 2026 года, что достаточно свежо для актуальности объекта при анализе маршрутизации, хотя текущее состояние всё равно требует телеметрии BGP.

Структура из двух AS важна. AS51464 несёт старую идентичность iBank2.RU и небольшой, но живой IPv4-след. AS43048, судя по всему, несёт более широкую маршрутную позицию mitigation-cloud с бо́льшим числом наблюдаемых соседей и IPv6.AS-set AS-MITIGATOR-CLOUDвключает AS43048, AS51464 и несколько других ASN. Это подтверждает более широкую поверхность маршрутной политики, но не должно восприниматься как схема собственности. Членство в AS-set может отражать клиентов, пиров, нижестоящие сети или потребности маршрутной политики. Клиенту защищённого сервиса важно знать, какая именно AS и какой именно префикс несут его трафик, а не только имя бренда на странице сервиса.

Что Mitigator Cloud публично заявляет, что продаёт

Самое ясное клиентоориентированное свидетельство —страница Mitigator Cloud. Она описывает сервис на русском языке как комплексную круглосуточную защиту от DDoS для корпоративных клиентов, банков, IT-компаний и сервис-провайдеров с мониторингом 24/7. Заявлена защита от атак L3–L7, индивидуальный подход, автоматическое обнаружение атак со временем реакции до пяти секунд и уведомления об атаке по электронной почте, Telegram, push-каналу Vestochka и SMS. На странице также сказано, что сервис основан на ПО MITIGATOR, которое описывается как российское ПО, включённое в реестр отечественного ПО под номером 4063 и сертифицированное ФСТЭК по сертификату № 5059.

Это не нейтральный аудит. Это маркетинговый текст самой компании. Его ценность в том, что он определяет поверхность сервиса, который клиенту предлагают купить. Mitigator Cloud не просто заявляет об «облаке» абстрактно. Он описывает конкретные способы управления трафиком: замену A-записи, постоянный BGP-анонс, BGP-анонс во время атаки и использование префиксов Mitigator Cloud. Также описаны способы доставки очищенного трафика: L2-туннель, TCP-обратный прокси и HTTP/HTTPS-обратный прокси. Эти детали меняют риск-анализ с обычного хостингового профиля на профиль маршрутизации и очистки.

Сайт продуктаmitigator.ru/mainengописывает MITIGATOR как ПО для защиты от DDoS для корпоративных клиентов, государственных компаний и поставщиков сервисов безопасности. Там сказано, что продукт обнаруживает и подавляет DDoS-атаки L3–L7 и содержит более 50 контрмер на основе challenge-response, репутации, rate-based логики, регулярных выражений, валидации, ограничений, IP-списков и логики поведения приложений.Страница «О продукте»добавляет заявления о контроле доступа, защите на уровне политик, управлении API, дашбордах, поставке в Docker-контейнерах, поддержке процессоров x86-64 и сетевых карт, GRE-туннелировании и аппаратном bypass.Страница услугописывает внедрение, поддержку, экспертизу, обучение и живую помощь во время атак.

Здесь важна граница. В метаданных сайта продукта АО «БИФИТ» указано как организация-разработчик ПО MITIGATOR, тогда как страница облачного сервиса в футере называет ООО «Mitigator Cloud» и указывает [email protected] и тот же московский телефон, что и в RIPE. Эта статья не делает выводов о корпоративных отношениях собственности помимо того, что говорят публичные страницы и записи реестра. Страницы продукта рассматриваются как свидетельство того, как описана технология сервиса, а записи RIPE и облачная страница — как свидетельство сетевой идентичности сервиса Mitigator Cloud.

Для клиентов заявления о сервисе порождают несколько вопросов о зависимостях. Если защита выполняется заменой A-записи, как быстро можно изменить DNS и какие TTL действуют? Если защита выполняется постоянным BGP-анонсом, какие задержки и изменения маршрутизации нормальны даже без атаки? Если защита выполняется только во время атак, кто санкционирует анонс и как это влияет на существующие сессии? Если чистый трафик доставляется через туннель или прокси, где завершается шифрование, кто хранит секреты, какие логи сохраняются и что происходит при отказе конечной точки туннеля? Это не академические вопросы.

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

AS51464 в текущем срезе — живая, небольшая и только IPv4

RIPEstat даёт более сильный сигнал, чем сайт, потому что показывает наблюдаемое состояние маршрутизации.Обзор AS для AS51464показал держателяIBANK2RU MITIGATOR CLOUD LLCи отметил AS как анонсированную 12 июля 2026 года.Представление routing-statusпоказало первое наблюдение в августе 2010 года, текущую видимость 12 июля 2026 года, полную видимость IPv4 среди выбранных пиров RIPE RIS, отсутствие видимости IPv6, шесть анонсированных IPv4-префиксов, 2304 IPv4-адреса и тринадцать наблюдаемых соседей.

Представление announced-prefixes для AS51464перечислило текущие анонсы, включая 109.232.248.0/21, 109.232.252.0/24, 109.232.253.0/24, 109.232.254.0/24, 109.232.255.0/24 и 185.6.47.0/24. Точный список может меняться, и этот срез не следует считать постоянной инвентаризацией. Его достаточно, чтобы доказать, что AS51464 — не спящая метка. На момент проверки она была видна в BGP.

Представление as-routing-consistency для AS51464добавляет полезные нюансы. Оно показало несколько префиксов, присутствующих и в BGP, и в данных реестра маршрутов RIPE, включая 109.232.248.0/21, 109.232.252.0/24 и 109.232.253.0/24. Оно также показало отношения политики, где часть пиров присутствовала и в BGP, и в whois, а другие были видны только в одном из представлений. Например, AS43048 появлялась и в BGP, и в whois для импорта и экспорта, тогда как несколько наблюдаемых пиров были в BGP без соответствующей whois-политики в этом выводе. Это не означает, что маршрутизация некорректна. Это значит, что клиентам следует проверять точные объекты маршрутов, фильтры и приём у аплинков для тех префиксов, которые они будут использовать.

RPKI не выглядит сильной стороной в выбранных данных по AS51464.Запрос валидации RPKI для AS51464 и 109.232.248.0/21вернулunknown, без валидирующих ROA. Аналогичная проверка для 185.6.44.0/22 тоже вернула unknown. Unknown — не invalid. Это просто означает, что авторизация origin маршрута не была видна для этих выбранных комбинаций в выводе валидатора. Клиент, чей аптайм зависит от фильтрации у аплинков, должен спросить, есть ли у конкретного сервисного префикса валидный ROA, какие объекты маршрутов существуют, какие аплинки их принимают и что произойдёт, если политика origin маршрута изменится во время атаки.

Операционное значение AS51464 ограничено. В текущей телеметрии она живая, небольшая, только IPv4 и прочно связана с именем iBank2.RU. Она может поддерживать зависимости защищённых сервисов, но сама по себе не доказывает масштаб, планировку помещений или резервные мощности за сервисом.

AS43048 — более широкая поверхность mitigation

AS43048 больше похожа на текущую маршрутную поверхность mitigation-cloud.Обзор AS в RIPEstat для AS43048показал держателяmitigator-cloud MITIGATOR CLOUD LLCи отметил AS как анонсированную 12 июля 2026 года.Представление routing-statusпоказало первое наблюдение в июле 2007 года, текущую видимость в июле 2026 года, семь IPv4-префиксов, 2304 IPv4-адреса, один IPv6-префикс, 65 536 IPv6-/48 и сорок три наблюдаемых соседа. IPv6-значение большое, потому что наблюдаемый префикс — /32, а не потому, что все /48 обязательно используются клиентами.

Представление announced-prefixes для AS43048показало анонсы, включая 185.6.44.0/22, 91.209.119.0/24, 109.232.248.0/22, несколько маршрутов 109.232.248.0/24–109.232.251.0/24 и 2a02:4f40::/32. Объект route6 для2a02:4f40::/32описывает префикс как IBANK2.RU с origin AS43048.Запрос валидации RPKI для AS43048 и 2a02:4f40::/32также вернул unknown без валидирующих ROA.

У AS43048 более насыщенный объект политики, чем у AS51464. Её aut-num в RIPE перечисляет отношения транзита или политики с AS9002, AS202984, AS8732 и AS8631, а также несколько ASN, для которых AS43048 принимает указанную AS и анонсирует маршруты обратно. Представление as-routing-consistency в RIPEstat показывает AS9002, AS202984, AS8732, AS207104, AS52016, AS206955 и AS51464 в строках импорта/экспорта и в BGP, и в whois, а также наблюдаемых BGP-соседей, отсутствующих в whois-выводе политики. Опять же, это не автоматически проблема.

Это повод спросить, какие отношения являются производственным транзитом, какие — клиентами, какие частными и какие переносят трафик очистки во время атаки.

PeeringDB гораздо беднее.Сетевой запрос PeeringDB для AS43048возвращает сеть с именем MITIGATOR CLOUD LLC, созданную в июне 2025 года и вскоре обновлённую, но без раскрытых уровней трафика, общей политики пиринга, публичного сайта, IX или количества площадок в возвращаемых полях.Организационная запись PeeringDBтак же скудна.Представления netixlanиnetfacдля этой сети PeeringDB возвращают пустые списки.

Этот пробел в PeeringDB нужно читать осторожно. Многие реальные сети не поддерживают полные данные о площадках в PeeringDB. Пустые строки IX или площадок не доказывают, что у Mitigator Cloud нет портов на биржах, стоек или площадок операторов связи. Они означают, что публичный читатель не может с помощью PeeringDB проверить, где находится сервис, есть ли независимые площадки, какие объекты размещают маршрутизаторы и сколько мест могут одновременно очищать трафик. Для покупателя открытые данные смещают бремя проверки на договорные условия, схемы, тесты маршрутов и процедуры реагирования на инциденты.

Арендуемые мощности здесь — это мощности очистки

Задание называет это профилем арендуемых мощностей, но открытые данные указывают на особый вид арендуемых мощностей: мощности очистки от DDoS и доставки защищённых сервисов. Эти мощности остаются физическими. Пакеты должны войти в сетевой порт. Устройства или серверы очистки должны их проверить. Легитимный трафик должен выйти через другой порт, туннель или прокси. DNS и BGP должны в нужный момент направить трафик в нужное место. Инженеры должны отличать атакующий трафик от клиентского, не создавая второй сбой.

Документация по развёртыванию Mitigatorобъясняет, почему это не простой продукт-веб-прокси. Она описывает симметричные и асимметричные развёртывания, постоянную и по требованию защиту, inline-, on-a-stick- и common-LAN-модели физического подключения, режимы L2-transparent и L3-router, горизонтальное масштабирование через LACP или ECMP, VRRP, GRE-туннелирование и примеры BGP-анонсов. Также указано, что постоянная защита фильтрует атаки сразу после их появления, но может влиять на оптимальность маршрута и нагрузку, а защита по требованию снижает фоновую нагрузку, но увеличивает интервал до попадания трафика под защиту и может сбрасывать установленные сессии.

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

Документация по BGP-сигнализациистоль же важна. Она описывает, что MITIGATOR использует BGP для сигнализации вышестоящим операторам связи или управляемым провайдерам безопасности, при этом префиксы добавляются в список сигнализации при превышении порогов автоматического обнаружения. Там предупреждается, что если внешний сервис очистки не настроен продолжать очистку при наблюдаемом высоком трафике, снижение скорости после начала очистки может привести к удалению префиксов и остановке очистки, создавая риск флапа. Для клиента это означает, что сервис очистки — это не просто «вкл/выкл». Это конечный автомат, включающий пороги, анонсы, конфигурацию соседей, сообщества, next-hop, поведение аплинков и время.

Страница ценобъясняет ещё одно скрытое ограничение мощности: лицензии MITIGATOR ограничивают скорость входящего в систему трафика, учитывая и атакующий, и легитимный трафик. На странице сказано, что минимальная лицензируемая полоса пропускания, доступная для покупки, — 100 Мбит/с, минимальный шаг назначения на устройство — 50 Мбит/с, а стоимость рассчитывается по запросу. Клиент, покупающий облачный сервис защиты, может никогда не увидеть эти лицензионные параметры, но экономика всё равно действует. Атакующий трафик потребляет мощность. Легитимный трафик потребляет мощность. Избыточное резервирование стоит денег. Недостаточное резервирование превращает атаку в отбрасывание легитимного трафика.

Именно поэтому публичный маршрутный след нельзя напрямую пересчитать в клиентские мощности. AS51464 и AS43048 показывают живые сети. Они не показывают, сколько пропускной способности очистки установлено, сколько лицензировано, сколько зарезервировано, сколько уже продано, сколько доступно в конкретном городе и как быстро мощность можно увеличить. Для банка, IT-компании или сервис-провайдера ключевой коммерческий вопрос не просто «анонсирует ли AS маршруты?». Это «какой размер атаки и нормальный уровень трафика покрыты договором, где и через какой путь возврата?»

История со стойками и площадками остаётся в основном за кадром

Непрозрачность площадок — самое большое слабое место публичных данных. RIPE даёт московский юридический и контактный адрес. Объект маршрута даёт тот же московский адрес. Облачный сервис даёт российский телефон и почтовый адрес. Эти детали закрепляют субъект в России, но не указывают машинные залы, операторов colocation, площадь стоек, топологию электропитания, meet-me-румы операторов, процедуры remote hands или склад запчастей, используемые сервисом очистки.

PeeringDB пробел не закрывает. У AS43048 есть запись, но публичные списки IX и площадок пусты. Для AS51464 в использованном запросе не нашлось пригодной сетевой записи PeeringDB. Опять же, это не доказательство отсутствия инфраструктуры. Это доказательство того, что публичный каталог, который большинство операторов используют для раскрытия площадок и бирж, сейчас не отвечает на практические вопросы покупателя.

Для провайдера DDoS-защиты вопрос площадок серьёзнее, чем для обычного хостинга. Обычный хостинг иногда может пережить короткое окно обслуживания, если есть резервное копирование и связь с клиентами. Сервис очистки часто нужен именно в тот момент, когда мощности и персонал максимально напряжены. Если трафик перенаправлен через BGP или DNS, узлы очистки, пограничные маршрутизаторы и каналы возврата чистого трафика становятся частью производственного пути клиента.

Если эти узлы теряют питание, коммутатор top-of-rack выходит из строя, линейная карта маршрутизатора насыщается, конечная точка туннеля падает или доступ на площадку задерживает замену, защищённый клиент может оказаться в худшем положении, чем до перенаправления.

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

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

Транзит и маршрутная политика — клиентские зависимости

Публичная маршрутная политика предполагает полезное разнообразие, но сама по себе не доказывает устойчивость. AS43048 перечисляет несколько аплинк- и пиринговых отношений в RIPE, а RIPEstat наблюдает сорок три соседа. AS51464 наблюдает тринадцать соседей. Выводы as-routing-consistency показывают и задокументированные, и незадокументированные живые отношения. AS-set включает более широкую группу ASN. Всё это говорит о том, что у Mitigator Cloud есть значимая маршрутная поверхность.

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

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

Статус RPKI unknown для выборочных префиксов — тоже реальный пункт due diligence. Unknown — это не ошибка, и многие сети продолжают работать со статусом unknown. Но валидация origin маршрута всё чаще влияет на решения о фильтрации, устранение неполадок и уверенность при инцидентах. Клиент, который хочет защитить префикс через Mitigator Cloud, должен проверить точную AS origin, объект маршрута, статус ROA и план фильтрации у аплинков до первой атаки. Также следует протестировать отзыв и восстановление маршрута в спокойный период. Тестировать во время атаки — плохой способ узнать, как ведёт себя путь.

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

Один практический тест для покупателя — прослеживаемость на уровне префикса. Попросите Mitigator Cloud указать ожидаемый AS-путь до, во время и после атаки. Спросите, какие сообщества или next-hop используются. Спросите, возвращается ли чистый трафик через L2-туннель, GRE, TCP-обратный прокси или HTTP/HTTPS-обратный прокси. Спросите, симметричен ли исходящий трафик клиента. Спросите, какие логи доказывают, что событие маршрута произошло. Если ответ остаётся на уровне бренда, клиент ещё не составил карту операционной зависимости.

Поддержка — часть продукта, а не аксессуар

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

Во время реального инцидента действовать могут многие команды: команда приложения клиента, DNS-оператор клиента, сетевая команда клиента, команда поддержки Mitigator Cloud, вышестоящие провайдеры, remote hands на площадке и, возможно, вендор ПО. Если клиент использует обратный прокси, поддержка может также касаться TLS, заголовков, восстановления исходного IP-адреса, поведения, похожего на WAF, и обмена логами. Если клиент использует BGP, поддержка может касаться анонсов префиксов, сообществ, фильтров маршрутов и конечных точек туннелей.

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

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

Человек, отвечающий на телефон поддержки, должен иметь путь к тому, у кого есть полномочия.

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

Обновления, резервные копии и кластерная архитектура создают ремонтные окна

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

Страница внутреннего отказоустойчивого хранилищаописывает более сильную модель, в которой синхронизированные копии базы данных физически хранятся на разных серверах. Также описывается потоковая репликация, pgfailover, повышение standby при недоступности primary, необходимость надёжной связи между узлами и поведение split-brain при разделении кластера на части. Страница прямо предупреждает не использовать доменные имена, потому что при отказе DNS связь нарушится. Для клиентов эта деталь — золото: документация вендора сама признаёт, что имена, доступность узлов и состояние хранилища могут стать частью сценария отказа.

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

Страница версийперечисляет текущие, поддерживаемые и неподдерживаемые статусы версий.Страница обновления v26.04говорит, что обновления до v26.04 требуют ядра Linux 5.0 или выше для полной функциональности MITIGATOR, должны выполняться с минорной версии v25.12.5 или новее и требуют полной резервной копии, потому что меняется версия PostgreSQL и базу данных нужно восстанавливать. Это реальность ремонтных окон за сервисом защиты. Даже если клиент никогда не видит экран администрирования продукта, способность провайдера обслуживать, резервировать и восстанавливать платформу защиты влияет на аптайм клиента.

Клиентам следует спрашивать, как Mitigator Cloud обрабатывает эти окна в своём хостинг-сервисе. Хранятся ли клиентские политики в отказоустойчивой многоузловой конфигурации? Сохраняются ли метрики и логи инцидентов после восстановления? Выполняются ли обновления по площадкам? Выводится ли доставка чистого трафика из эксплуатации перед обслуживанием? Отзываются ли анонсы маршрутов или сохраняются? Уведомляются ли клиенты, когда обновляется сама платформа защиты? Публичная документация объясняет эксплуатационные ограничения технологии. Она не доказывает, как облачный сервис их применяет.

Локализация данных российская, но обращение с данными — отдельный вопрос

Регион задания — RU, и открытые данные подтверждают Россию как операционный контекст. RIPE указывает MITIGATOR CLOUD LLC в Москве. Облачная страница описывает российский сервис и называет российские регуляторные сертификаты. Телефон российский. Сервис позиционируется для российских корпоративных клиентов, банков, IT-компаний и сервис-провайдеров. AS51464 и AS43048 — номерные ресурсы региона RIPE, привязанные к российской организации.

Это подтверждает тезис о российской локализации, но не отвечает на все вопросы об обращении с данными. DDoS-защита может раскрывать чувствительные операционные материалы, даже если не хостит базу данных приложения клиента. Защита через обратный прокси может видеть HTTP-метаданные и, в зависимости от модели, расшифрованный трафик. HTTPS-защита, согласно странице Mitigator Cloud, может не включать расшифровку, но может включать передачу сертификатов/ключей или потоковое ведение логов. Защита на основе BGP может раскрывать списки префиксов, телеметрию трафика, сигнатуры атак и сетевую архитектуру клиента.

Туннели могут возвращать очищенный производственный трафик клиенту.

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

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

Кто страдает при отказе этих мощностей

Затронутая аудитория следует из списка клиентов на странице Mitigator Cloud: корпоративные клиенты, банки, IT-компании и сервис-провайдеры. Для банка отказ может означать, что страница входа для клиента, интерфейс онлайн-банкинга, платёжный сервис или публичный сайт становится медленным или недоступным во время атаки. Для IT-компании отказ может означать потерю доступности SaaS-конечных точек, клиентских порталов, API или дашбордов. Для сервис-провайдера отказ может каскадно затронуть нижестоящих клиентов, которые считают, что купили защиту у своего провайдера, а не напрямую у Mitigator Cloud.

Механизм воздействия зависит от модели сервиса. Если используется переключение A-записи, задержка DNS и кэши резолверов могут оставить часть пользователей на незащищённом пути, пока другие идут через Mitigator Cloud. Если используется постоянный BGP-анонс, Mitigator Cloud всегда в пути данных, поэтому сбои на стороне провайдера могут влиять на обычный трафик. Если BGP используется только во время атаки, время схождения маршрута, приём фильтров и стабильность анонсов становятся частью инцидента.

Если чистый трафик возвращается через L2-туннель, TCP-обратный прокси или HTTP/HTTPS-обратный прокси, путь возврата может отказать независимо от входящего пути очистки.

Ложные срабатывания могут быть так же вредны, как и пропущенные атаки. Контрмера, которая блокирует враждебных клиентов, но также блокирует легитимные мобильные сети, корпоративные NAT, платёжные обратные вызовы или API-клиентов, может превратить защиту в самонанесённый простой. Страницы продукта подчёркивают множество типов контрмер и управление на уровне политик. Эта гибкость ценна только в том случае, если провайдер и клиент могут достаточно быстро её настраивать и проверять легитимный трафик во время инцидента.

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

Что клиенту следует проверить, прежде чем полагаться на сервис

Первая проверка — идентичность и объём. Клиент должен подтвердить, будет ли его сервис переноситься через AS51464, AS43048, клиентскую AS или префиксы Mitigator Cloud. Нужно подтвердить точные префиксы, объекты маршрутов, статус ROA, аплинки, сообщества и обычные AS-пути. Не следует принимать имя AS-set как достаточное доказательство производственного пути.

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

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

Четвёртая проверка — возврат чистого трафика. Для туннелей спросите, как защищены и мониторятся конечные точки, как ротируются ключи, какая полоса пропускания гарантирована и что происходит при повреждении туннеля. Для обратного прокси спросите, как сохраняются исходные IP-адреса, как обрабатывается TLS, какие логи собираются и какие изменения требуются от клиента. Для HTTP/HTTPS-защиты без расшифровки спросите, какие методы обнаружения остаются эффективными и какие классы атак требуют логов или ключевого материала.

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

Шестая проверка — полномочия поддержки. Подтвердите круглосуточный путь от сигнала клиента до действия инженера. Спросите, кто может добавить контрмеру, изменить BGP-анонс, обновить туннель, просмотреть логи, поговорить с аплинками, откатить изменение ПО и согласовать экстренное увеличение мощности. DDoS-защита — это не только продукт обработки пакетов. Это сервис принятия решений под давлением времени.

Степень доказательности и итог

Степень доказательности — средняя. Данные об идентичности сильные: записи RIPE организации, мейнтейнера, роли, aut-num, route, route6 и RDAP последовательно связывают iBank2.RU, MITIGATOR CLOUD LLC, AS51464 и AS43048. Сетевые данные достаточно сильны, чтобы показать текущую маршрутизацию: RIPEstat отмечает обе ASN анонсированными 12 июля 2026 года, при этом AS51464 видна как меньшая сеть только с IPv4, а AS43048 — как более широкая сеть mitigation с IPv4, IPv6 и значительно большим числом наблюдаемых соседей.

Свидетельства о сервисе тоже значимы. Mitigator Cloud публично описывает круглосуточную российскую DDoS-защиту для корпоративных клиентов, банков, IT-компаний и сервис-провайдеров с конкретными вариантами управления трафиком и доставки чистого трафика. Документация продукта MITIGATOR объясняет механику за этими заявлениями: BGP-сигнализацию, постоянный режим и режим по требованию, туннели, кластеры, отказоустойчивое хранилище, резервные копии, поддержку версий и требования к обновлениям.

Слабая часть — физическая и операционная проверка. Открытые источники не называют площадки, стойки, резервные мощности, установленную пропускную способность очистки, распределение лицензий, тесты восстановления, историю инцидентов, схему эскалации поддержки или условия переносимости клиентов. PeeringDB скудна, а не обнадёживает. Статус RPKI для выборочных префиксов — unknown. Открытые данные подтверждают реальную зависимость, но не полностью проверенное заявление об устойчивости.

Для клиентов практический вывод прост. Относитесь к IBANK2RU MITIGATOR CLOUD LLC как к действующему российскому провайдеру мощностей защищённых сервисов, чьё облачное обещание зависит от маршрутизаторов, узлов очистки, транзита, поддержки и ремонтных окон. Покупайте сервис только после проверки точных обязательств по маршруту, площадке, туннелю, резервному копированию, поддержке и мощности для той нагрузки, которая будет от него зависеть.