Средняя
- Теги: Cisco, LPS, xFSU, Устранение уязвимостей
У сетевого оборудования есть старая эксплуатационная проблема: критическую уязвимость желательно устранить немедленно, а обновлять коммутатор или маршрутизатор немедленно обычно нельзя.
Обновление сетевой ОС — это maintenance window, проверка совместимости, резервирование конфигурации, согласование простоя и риск того, что после перезагрузки что‑нибудь пойдёт не так. В результате между публикацией CVE и установкой исправленной версии может пройти несколько дней или даже недель.
Cisco развивает сразу два механизма, которые пытаются сократить этот разрыв: Live Protect Shield (LPS) позволяет временно блокировать эксплуатацию конкретной уязвимости без обновления сетевой ОС, а Extended Fast Software Upgrade (xFSU) сокращает простой, когда полноценное обновление всё‑таки выполняется.
Это две разные технологии, но вместе они формируют довольно интересную модель работы с уязвимостями:
Обнаружить уязвимость → быстро поставить компенсирующую защиту → спокойно подготовить обновление → установить исправленную версию с минимальным перерывом.
Содержание
- Live Protect: уязвимость остаётся, эксплуатация блокируется
- Что такое Live Protect Shield?
- Почему здесь используется eBPF?
- Но Live Protect — не замена обновлению
- Следующая проблема — само обновление
- Как xFSU уменьшает простой?
- Пять секунд — не для любой сети
- В итоге меняется сама схема устранения уязвимостей
Live Protect: уязвимость остаётся, эксплуатация блокируется
Live Protect принципиально отличается от обычного патча. При стандартном обновлении Cisco исправляет сам уязвимый код:
Уязвимый компонент → новая версия → уязвимого кода больше нет.
Live Protect работает иначе:
Уязвимый компонент → попытка эксплуатации → дополнительный контроль → опасное действие блокируется.
То есть сама CVE на устройстве формально остаётся. Но Cisco устанавливает дополнительный механизм, который не позволяет эксплойту пройти критический участок цепочки. Такой подход обычно называют compensating control или virtual patching.
В NX-OS и новых версиях IOS XE Cisco реализует его на уровне Linux kernel с помощью eBPF и проекта Tetragon. Tetragon встроен в сетевую ОС и может отслеживать действия процессов: запуск программ, системные вызовы, обращения к файлам, сетевую активность и операции с привилегиями.
Допустим, в management-сервисе найден RCE. Для успешной эксплуатации атакующий должен заставить процесс выполнить shell. Условно цепочка выглядит так:
HTTP-запрос → уязвимый сервис → exec(«/bin/bash») → shell
Обычный патч исправляет уязвимость в сервисе. Live Protect может поставить контроль глубже:
HTTP-запрос → уязвимый сервис → exec(«/bin/bash») → eBPF policy → DENY
При этом сервис остаётся старой версии, но необходимый для эксплуатации шаг блокируется внутри операционной системы.
Что такое Live Protect Shield?
Для конкретной уязвимости Cisco может подготовить Shield — отдельную политику защиты.
Это не универсальное правило уровня «запретить RCE». Инженеры должны проанализировать конкретную CVE и понять, какое действие эксплойта можно надёжно отличить от штатной работы устройства.
Например:
- определённый процесс пытается запустить другой бинарный файл;
- сервис обращается к объекту, к которому в нормальном режиме обращаться не должен;
- выполняется опасная операция с привилегиями;
- вызывается определённая функция ядра с характерным набором аргументов.
После этого соответствующая политика загружается в работающую систему.
Для IOS XE Cisco оформляет Shield как отдельный устанавливаемый пакет. В IOS XE 26.2.1 поддержка Live Protect появилась на C9350, C9550 и C9610 Smart Switches.
У Shield есть два важных режима.
Monitoring — потенциально опасное действие обнаруживается и регистрируется, но не блокируется.
Enforcing — то же действие уже запрещается.
Это позволяет сначала проверить правило в реальной сети и посмотреть, не задевает ли оно нормальную работу, а уже потом включить блокировку.
Такой подход особенно важен для сетевого оборудования: ложное срабатывание security-контроля, например внутри routing daemon или management plane, потенциально может оказаться не менее неприятным, чем сама уязвимость.
Почему здесь используется eBPF?
eBPF позволяет загрузить небольшую программу непосредственно в Linux kernel и привязать её к определённому событию.
Например:
Процесс X → вызывает функцию Y → с параметром Z
В этот момент eBPF-код может собрать информацию, записать событие или запретить операцию.
Главное преимущество — для этого не требуется перекомпилировать ядро, менять основной образ сетевой ОС или перезагружать устройство.
Именно поэтому Cisco может поставить дополнительную защиту на уже работающий коммутатор. При этом речь не идёт о фильтрации всего пользовательского трафика через Linux. На современных коммутаторах основной data plane продолжает работать в ASIC. Live Protect защищает прежде всего процессы control и management plane — там, где работают Linux и сервисы сетевой ОС.
Но Live Protect — не замена обновлению
Здесь есть важное ограничение. Устройство с установленным Shield нельзя считать исправленным.
Правильное состояние выглядит так:
software vulnerable + exploitation mitigated
а не:
software fixed
Кроме того, далеко не для каждой CVE можно создать безопасный Shield.
Если проблема находится непосредственно в ядре, firmware, ASIC или путь эксплуатации невозможно надёжно отделить от нормальной работы, такой механизм может оказаться неприменим.
Поэтому Live Protect стоит рассматривать как способ сократить окно риска между обнаружением CVE и полноценным обновлением, а не как замену patch management.
Следующая проблема — само обновление
Даже если исправленная версия уже вышла, остаётся другая причина, по которой сетевики не любят устанавливать её немедленно: перезагрузка.
Для обычного Catalyst 9300 без резервного control plane полноценная перезагрузка может означать несколько минут потери трафика.
Здесь решается уже другая задача — с помощью Extended Fast Software Upgrade, xFSU.
Причём сама технология xFSU не новая: Cisco поддерживает её на Catalyst 9300 начиная ещё с IOS XE 17.3.2a. Но механизм постепенно развивается, и начиная с IOS XE 17.15.2 для поддерживаемых сценариев Cisco заявляет менее пяти секунд потери трафика при переходе на последующие поддерживаемые версии.
Как xFSU уменьшает простой?
Обычная перезагрузка фактически останавливает и control plane, и data plane:
IOS XE остановился → ASIC потерял состояние → устройство загрузилось → протоколы поднялись → таблицы построились заново
xFSU пытается разделить эти процессы. Во время перезапуска control plane существующее forwarding state максимально долго сохраняется в ASIC. То есть маршруты, MAC-таблицы, ACL и другое состояние data plane продолжают использоваться для передачи трафика, пока операционная система перезапускается.
Упрощённо:
Control plane → reload
при этом:
Data plane → продолжает forwarding
Для динамических протоколов используются механизмы Graceful Restart / Nonstop Forwarding, благодаря которым соседи некоторое время сохраняют существующие маршруты вместо того, чтобы немедленно считать устройство недоступным.
После запуска новой версии control plane синхронизируется с существующим состоянием forwarding plane.
Сам ASIC в определённый момент тоже приходится быстро перезапустить и перепрограммировать — именно здесь возникает короткий реальный перерыв передачи трафика.
В актуальных поддерживаемых сценариях Cisco указывает менее пяти секунд traffic downtime.
Для сравнения, обычное обновление Catalyst 9300 может означать порядка трёх-четырёх минут отсутствия forwarding.
Пять секунд — не для любой сети
Как и Live Protect, xFSU нельзя считать универсальной кнопкой.
Есть ограничения:
- по модели устройства;
- текущей и целевой версии IOS XE;
- режиму установки;
- топологии;
- используемым протоколам;
- стеку;
- STP;
- multicast;
- TrustSec и ряду других функций.
Перед обновлением устройство умеет проверить, подходит ли текущая конфигурация для xFSU. Для этого существует команда show xfsu eligibility.
Cisco отдельно предупреждает, что даже наличие поддерживаемого протокола само по себе не гарантирует минимальный downtime: результат зависит от конкретной конфигурации и взаимодействия функций.
Поэтому правильнее говорить не «Cisco научилась обновлять коммутаторы без простоя», а «В определённых конфигурациях время потери трафика при полном обновлении удалось сократить с минут до нескольких секунд».
В итоге меняется сама схема устранения уязвимостей
Если соединить обе технологии, получается интересная эксплуатационная модель.
Раньше процесс чаще выглядел так:
Обнаружена CVE → оценка риска → согласование maintenance window → обновление → проверка.
Проблема очевидна: наиболее опасный период находится как раз между первым и четвёртым шагом.
Новая схема может выглядеть иначе:
Обнаружена CVE → установлен временный Shield → включён Monitoring → проверено отсутствие ложных срабатываний → включён Enforcing → подготовлено полноценное обновление → проверена возможность xFSU → установлена исправленная версия → проверена работа устройства → временный Shield удалён.
То есть борьба с уязвимостями постепенно разделяется на два независимых процесса.
Первый отвечает на вопрос: «Как быстро уменьшить риск прямо сейчас?»
Второй: «Как окончательно устранить уязвимость с минимальным влиянием на сеть?»
И это, пожалуй, наиболее интересное изменение.
Сетевое оборудование традиционно обновлялось значительно осторожнее серверов и рабочих станций именно потому, что цена неудачного патча или перезагрузки здесь существенно выше. Поэтому новые механизмы направлены не столько на то, чтобы выпускать больше исправлений, сколько на устранение главного эксплуатационного противоречия:
Критические уязвимости требуют скорости, а критическая сеть требует осторожности.
Live Protect пытается выиграть время между обнаружением уязвимости и обновлением. xFSU — уменьшить цену самого обновления.
Если подобный подход станет массовым и появится у других производителей, следующим этапом развития vulnerability management для сетевого оборудования, вероятно, станет не просто список CVE и рекомендация «обновите ПО», а полноценное управление состоянием уязвимости:
Обнаружена → экспонирована → временно защищена → подготовлена к обновлению → исправлена → проверена.
Адрес:
121205, г. Москва, муниципальный округ Можайский, территория инновационного центра «Сколково», б-р Большой, д. 42, стр. 1, этаж 2, помещение № 162/№ 4
Телефон:
+7 (495) 255-35-82
Почта:
info@netopia.pro
Деятельность осуществляется компанией ООО «Нетопия» при грантовой поддержке Фонда «Сколково»
© Netopia.pro
