Кратко

  • Несанкционированный анонс 162.55.80.0/24 оставил AS24940 компании Hetzner видимым источником и получил статус RPKI Valid благодаря ROA, разрешавшему длину /24, хотя сам путь был подделан.
  • Virtualizor восстановила распространение по 368 пирам RIPE RIS, но ответы злоумышленника не попадали в журналы компании, поэтому окончательный перечень затронутых установок составить невозможно.
  • Нужна локальная квитанция потребления обновления, связывающая запрошенную версию, подписанный манифест, хеш пакета, принятый ключ, результат проверки и исход установки либо отката.

В отчёте об инциденте самая крупная цифра часто начинает изображать масштаб ущерба. Здесь это 368. По данным Virtualizor, каждый из 368 пиров в изученной выборке RIPE Routing Information Service в какой-то момент нёс перехваченный маршрут. Это весомое измерение распространения в топологии. Но оно не считает клиентов, запросы обновления, законченные загрузки или скомпрометированные серверы.

Разделять эти множества необходимо для доказательности. Коллекторы BGP видят объявленные пути. Удостоверяющий центр фиксирует проверку домена и выдачу сертификата. Сервер злоумышленника видит перенаправленные запросы. Каждая установка Virtualizor локально решает, запросить ли пакет, принять ли его и выполнить ли. Атака прошла через четыре поверхности, но ни один журнал не наблюдает ту же совокупность, что остальные.

10 сентября 2026 года LACNIC опубликовал испанскую версию анализа Kentik. Так инцидент стал актуальным материалом для регионального сообщества, однако LACNIC не управлял пострадавшей инфраструктурой. На странице прямо сказано, что взгляды авторов не обязательно выражают позицию реестра. Атрибуция должна остаться точной: LACNIC разместил материал, Kentik разобрал маршрут, Virtualizor описала воздействие на продукт.

Что именно подтвердил статус RPKI Valid

Около 20:57 UTC 28 августа в глобальной таблице появился 162.55.80.0/24 с окончанием AS path 6204 62390 24940. Маршрут /24 был специфичнее обычного объявления Hetzner 162.55.0.0/16. Там, где маршрутизатор принимал оба варианта, правило самого длинного совпадающего префикса направляло трафик к новому пути.

Злоумышленник не заменил видимый источник, а сохранил AS24940 компании Hetzner в правой части пути. Покрывающий ROA разрешал этот источник и длину префикса до /24. Поэтому проверка происхождения могла вынести результат RPKI Valid. Она удостоверяла совпадение префикса, длины и последней автономной системы с опубликованным разрешением. Она не удостоверяла AS62390 как законного апстрима и не подтверждала предыдущие соседства.

RFC 9319 описывает такой класс как перехват подпрефикса с подделанным источником. Если неминимальный ROA покрывает более точные префиксы, которые владелец в действительности не объявляет, противник может дописать разрешённую автономную систему в конец пути и занять свободную часть адресного пространства. Рекомендация использовать минимальные ROA сокращает эту поверхность там, где позволяет эксплуатация. Но она не подписывает криптографически каждый переход AS path.

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

Virtualizor ограничивает событие периодом примерно с 20:57 UTC 28 августа до 06:10 UTC 30 августа. Две активные волны разделяла пауза около одиннадцати часов. В реконструкции насчитывается примерно 10 600 отзывов маршрута. При такой нестабильности срез каждые десять минут нельзя считать непрерывной записью. Компания предупреждает, что точки, совпадающие с восьмичасовыми выгрузками RIB, надёжнее, а между ними сильный флаппинг способен занизить число видимых пиров.

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

Правильный сертификат для неправильного узла

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

Многоракурсное подтверждение выдачи MPIC предназначено для повышения стоимости подобной атаки. Удостоверяющий центр проверяет контроль из нескольких удалённых сетевых мест и требует согласия. Для соответствующих процедур требования CA/Browser Forum с 15 июня 2026 года предусматривают не менее четырёх удалённых перспектив; подтверждающие точки должны охватывать как минимум два региона обслуживания RIR. Let’s Encrypt давно объясняет, что единственную траекторию проверки можно обмануть перехватом или перенаправлением.

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

Законный журнал не записывает ответ чужого сервера

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

Противоречия здесь нет. Журнал origin-сервера фиксирует лишь запросы, пришедшие на этот сервер. Если во время успешного перенаправления строка отсутствует, клиент мог не отправлять запрос или мог получить ответ от другого узла. Центральная запись становится наименее полной именно тогда, когда противник выигрывает трафик. Повторный поиск не найдёт транзакцию, участником которой законный сервер не был.

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

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

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

Квитанция должна появляться в месте решения

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

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

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

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

Содержательная реакция без локального реестра

Перед критикой нужно назвать сильные стороны ответа. Virtualizor раскрыла доставку вредоносного пакета, опубликовала индикатор, попросила сменить и ограничить учётные данные, проверить доступ и сохранить доказательства, сообщила о сертификате для отзыва, восстановила маршруты по публичным данным и пообещала подпись пакетов. Kentik и LACNIC объяснили строгие ROA и мониторинг, не выдавая проверку происхождения за полную истину о пути.

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

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

Источники