NetScaler пропатчен. Почему я всё равно завершаю сессии и проверяю каждый HA-узел

Прошивка обновилась, шлюз отвечает, пользователи работают — хочется закрыть заявку. Я её не закрываю, пока не проверены оба HA-узла и не завершены нужные сессии. Я — Семёнов Евгений Сергеевич, директор ООО «АйТи-Фреш». Разберу, что исправляет патч CVE-2025-5777, где заканчиваются его возможности и как провести обслуживание без неприятного сюрприза при следующем переключении.

1. Исправленный код не возвращает украденную сессию

Сначала уточню термин. Здесь «утечка памяти» означает раскрытие её содержимого из-за memory overread, а не постепенное расходование RAM процессом. Речь о CVE-2025-5777: недостаточная проверка входных данных позволяет читать память за допустимыми границами. Условие из бюллетеня — NetScaler работает как Gateway, включая VPN, ICA Proxy, CVPN или RDP Proxy, либо как AAA virtual server. Это важно для инвентаризации: один только факт установки ADC ещё не подтверждает выполнение условия этой CVE. [Бюллетень CTX693420](https://support.citrix.com/external/article/CTX693420/netscaler-adc-and-netscaler-gateway-secu.html).

Практическая проблема начинается, если в раскрытые данные попал пригодный материал действующей сессии. Установка исправленного build прекращает чтение через конкретную уязвимость, но сама по себе не аннулирует всё, что атакующий получил раньше. Он может сохранять доступ через уже открытые сессии. Именно поэтому обновление и завершение сессий идут отдельными пунктами плана. Смена пользовательского пароля тоже не должна автоматически считаться отзывом каждого ранее выданного сеансового идентификатора. [Рекомендации NCSC](https://advisories.ncsc.nl/2025/ncsc-2025-0196-4.html).

Мой приоритет — быстро закрыть уязвимый вход, затем убрать оставшийся доступ и проверить последствия. Я не жду доказанной кражи конкретного токена, чтобы выполнить рекомендованный сброс. При этом пугать администратора неизбежным захватом всей сети неправильно: NetScaler прямо пишет, что кража сессии возможна, но не гарантирована и зависит от конфигурации и трафика. Наличие старой прошивки — основание действовать, а не готовое заключение о масштабе инцидента. [Пояснение производителя](https://www.netscaler.com/blog/news/evaluating-netscaler-logs-for-indicators-of-attempted-exploitation-of-cve-2025-5777/).

2. Какие версии исправлены и почему старые минимумы уже не годятся

В CTX693420 перечислены следующие первые исправленные сборки. Я сохраняю эти номера в статье для проверки истории обслуживания: они позволяют понять, был ли установлен фикс именно CVE-2025-5777. Их нельзя воспринимать как список рекомендуемых прошивок на 2026 год. [Перечень исправлений](https://support.citrix.com/external/article/CTX693420/netscaler-adc-and-netscaler-gateway-secu.html).

Обычные ветки 12.1 и 13.0 достигли EOL, уязвимы и не имеют поддерживаемого исправления внутри этих веток по данному бюллетеню. Здесь я планирую переход на поддерживаемый релиз. Строка 12.1-FIPS ниже — отдельный специальный продукт, а не спасительный пакет для обычного 12.1. Смешивать образы и рекомендации стандартной, FIPS- и NDcPP-веток нельзя. [Оговорка производителя об EOL](https://support.citrix.com/external/article/CTX693420/netscaler-adc-and-netscaler-gateway-secu.html).

На дату проверки, 5 сентября 2026 года, для учебного примера дальше беру обычный NetScaler 14.1-73.33. Он опубликован 19 августа и заменяет 14.1-73.30/73.32; последний уже фигурировал в новом бюллетене CTX696939. Это конкретная исходная точка для плана, а не обещание отсутствия любых уязвимостей и регрессий. Перед своим окном вы заново сверяете security advisories, release notes и совместимость. [История сборок](https://docs.netscaler.com/en-us/citrix-adc/current-release/document-history.html), [бюллетень CTX696939](https://support.citrix.com/external/article/CTX696939/netscaler-adc-and-netscaler-gateway-secu.html).

Для перехода с обычного 12.1 на 14.1 производитель рекомендует промежуточную 13.1. Такой маршрут сначала проверяю на копии конфигурации, включая удалённые classic policies: при необходимости использую NSPEPI для преобразования и проверяю результат. Ошибки предварительной проверки не обхожу ради красивого времени завершения заявки. Аварийное обновление старого шлюза легко превращается в миграцию политик, и это нужно обнаружить до переключения пользователей. [Подготовка перехода](https://docs.netscaler.com/en-us/citrix-adc/current-release/upgrade-downgrade-citrix-adc-appliance/upgrade-downgrade-before-you-begin.html), [ограничения classic policies](https://docs.netscaler.com/en-us/citrix-adc/current-release/faqs/faq-upgrade-downgrade.html).

• Обычные ADC/Gateway 14.1: исправление CVE-2025-5777 начиная с 14.1-43.56.
• Обычные ADC/Gateway 13.1: начиная с 13.1-58.32.
• ADC 13.1-FIPS и 13.1-NDcPP: начиная с 13.1-37.235.
• ADC 12.1-FIPS: начиная с 12.1-55.328.

3. До окна я проверяю доступ, резервную копию и лицензии

Начинаю с подключения к собственному NSIP каждого устройства. Выполняю `show ns version` и `show ha node`, записываю версию, адрес и текущую роль. Имя VM вроде ADC-PRIMARY ничего не гарантирует: после предыдущей аварии роли могли поменяться. Затем проверяю консоль гипервизора или аппаратный аварийный доступ. Если единственный административный маршрут проходит через обновляемый Gateway, сначала организую другой. Иначе первый же разрыв пользовательских соединений отрежет меня от продолжения работ.

Сохраняю конфигурацию и делаю штатный backup, после чего забираю архив с устройства во внешнее защищённое хранилище. Один файл ns.conf не считаю полноценной подготовкой восстановления: мне нужны сертификаты, необходимые ключи и нестандартные файлы. Полный backup также проверяю на состав применительно к своей установке. До чистки диска сохраняю доступные журналы; разбирать их несколько часов перед закрытием уязвимости не собираюсь. [Штатное резервное копирование NetScaler](https://docs.netscaler.com/en-us/citrix-adc/current-release/system/basic-operations.html).

Проверка ресурсов — на обоих узлах. Актуальная инструкция требует 7 GB свободного места в /var и рекомендует минимум 250 MB в /flash; общий размер виртуального диска этого не доказывает. В 2026 году столь же внимательно проверяю право на обновление и лицензию после перехода на License Activation Service, LAS. Для рассматриваемой пары самостоятельных VPX лицензирование выполняется отдельно на каждом узле. Не обещаю российской площадке, что старый файл лицензии автоматически переживёт обновление: доступность выбранной процедуры активации выясняю до окна. [Подготовка обновления](https://docs.netscaler.com/en-us/citrix-adc/current-release/upgrade-downgrade-citrix-adc-appliance/upgrade-downgrade-before-you-begin.html), [LAS](https://docs.netscaler.com/en-us/citrix-adc/current-release/licensing/ns-license-activation-service.html).

• В NetScaler CLI перед резервным копированием: `save ns config`.
• Создание и проверка архива: `create system backup -level full`, затем `show system backup`.
• В shell проверка файловых систем: `df -h /var /flash`.

4. Обновляю Secondary, переключаю роли, обновляю второй узел

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

Ниже — порядок для обычной двухузловой HA-пары. Сначала обновляется текущий Secondary, затем он принимает трафик, после чего обновляется бывший Primary. Между шагами я явно проверяю роли. При разных релизах отключаются, в частности, синхронизация конфигурации, распространение команд и зеркалирование соединений. При разных builds одной ветки это зависит от внутренней HA-версии. Поэтому временный AUTO DISABLED оцениваю по документации, но бессрочно жить в таком состоянии не предлагаю. [Порядок обновления HA](https://docs.netscaler.com/en-us/citrix-adc/current-release/upgrade-downgrade-citrix-adc-appliance/upgrade-downgrade-ha-pair.html).

Сам пакет устанавливаю локально на нужном узле. Для обычного 14.1 загружаю официальный архив в отдельный каталог внутри /var/nsinstall, распаковываю его и запускаю проверку из распакованного дистрибутива. Это shell-команды, не NetScaler CLI: `tar -xvzf build-14.1-73.33_nc_64.tgz`, затем `./installns --pre_check`, после устранения ошибок — `./installns`. Имя сверяю с реально скачанным файлом. Перезагрузку выполняю по запросу установщика; этот пример не относится к специальным FIPS-образам. [Установка прошивки](https://docs.netscaler.com/en-us/citrix-adc/current-release/upgrade-downgrade-citrix-adc-appliance/upgrade-standalone-appliance.html).

До переключения проверяю загрузку обновлённого узла, лицензию, интерфейсы и готовность HA. Сразу после failover проверяю вход через Gateway, всю цепочку аутентификации и запуск приложения. Пока эти тесты не пройдены, бывший Primary не обновляю. Команда `force failover` может выдать предупреждение или отказать, например при STAYSECONDARY; я выясняю причину, а не механически меняю HA-флаги. [Поведение force failover](https://docs.netscaler.com/en-us/citrix-adc/current-release/system/high-availability-introduction/forcing-a-node-to-failover.html).

• 1. На Secondary установить выбранный build, перезагрузить его; проверить `show ns version` и `show ha node`.
• 2. Когда узел готов, в NetScaler CLI выполнить `force failover`; убедиться, что он стал Primary.
• 3. Проверить пользовательский вход и приложение через Gateway, который теперь обслуживает обновлённый узел.
• 4. Обновить бывший Primary, ставший Secondary, тем же пакетом; проверить версию и восстановление HA.
• 5. Выполнить контролируемое обратное переключение и повторить пользовательский тест. Зафиксировать обе версии, роли и состояние синхронизации.

5. После всех узлов завершаю ICA/PCoIP — на правильном устройстве

Только после обновления всей пары выполняю две команды из бюллетеня. Для обычной HA достаточно текущего активного Primary. В кластере производитель рекомендует выполнить их на каждом узле после обновления всех участников. Это различие стоит написать прямо в заявке: «обновить каждый узел» и «выполнить kill на Primary» не противоречат друг другу. Перезагрузку вместо этих команд NetScaler не рекомендует. [Разъяснение производителя](https://www.netscaler.com/blog/news/critical-security-updates-for-netscaler-netscaler-gateway-and-netscaler-console/).

Команды выполняются в NetScaler CLI, с обычным ASCII-дефисом перед all. Я предупреждаю пользователей заранее, прошу сохранить документы и назначаю время разрыва. Отключение ICA/PCoIP-соединения не равно гарантированному logoff Windows на VDA. Приложение может продолжить работу, а клиент — переподключиться. Поэтому обещать обязательный повторный MFA после этих двух команд нельзя: результат зависит ещё и от аутентификации и других живых сессий. [Описание ICA](https://developer-docs.netscaler.com/en-us/adc-command-reference-int/current-release/vpn/vpn-icaConnection.html), [описание PCoIP](https://developer-docs.netscaler.com/en-us/adc-command-reference-int/current-release/vpn/vpn-pcoipConnection.html).

Проверяю соединения через `show vpn icaConnection` и `show vpn pcoipConnection`. Цель — убедиться, что прежние соединения завершены; постоянно нулевой счётчик на открытом шлюзе не является разумным критерием, поскольку пользователи возвращаются. Для чистой проверки на время приёмки ограничиваю пользовательский доступ внешним правилом, оставляя тестовый источник. Потом снимаю ограничение. Такой короткий контролируемый перерыв я предпочитаю бесконечному спору о том, почему после kill снова появились подключения.

Если используются AAA/VPN, RDP Proxy или балансировка приложений, двух команд недостаточно для утверждения «все сессии отозваны». NCSC дополнительно рекомендует `kill aaa session -all`, `kill rdp connection -all` и `clear lb persistentSessions`. Я включаю применимые действия в план с оценкой влияния; очистку LB persistence не выдаю за выход из самого приложения. Сессии внешнего IdP и приложений рассматриваю отдельно. Это расширенный объём реагирования NCSC, а не дополнительные строки CTX693420. [Рекомендация NCSC](https://advisories.ncsc.nl/2025/ncsc-2025-0196-4.html).

• Завершить все активные ICA-соединения: `kill icaconnection -all`.
• Завершить все активные PCoIP-соединения: `kill pcoipConnection -all`.

6. Практический разбор: учебный стенд «Вектор» на 120 рабочих мест

Покажу решение на смоделированном стенде ООО «Вектор». Название, нагрузка и результат сценария условные: это воспроизводимый учебный разбор, не отчёт о выполненном клиентском проекте. В модели 120 рабочих мест, 52 активных ICA-подключения, два VPX на разных хостах, каждому выделены 2 vCPU и 8 GB RAM. Это выбранные ресурсы стенда, не универсальный расчёт производительности. Оба узла работают на обычном 14.1-43.50; целевой build — 14.1-73.33.

NSIP узла A — 10.20.0.11, узла B — 10.20.0.12, тестовый Gateway VIP — 192.0.2.10:443. A начинает как Primary, B — Secondary. За Gateway стоят StoreFront и два VDA; аутентификация использует LDAP и RADIUS, PCoIP не настроен. У существующего виртуального сервера задано `set vpn vserver GW_VECTOR -icaOnly ON`. Это фрагмент настройки, а не полный конфиг: привязки сертификата, STA и политик здесь опущены. ICA-only не исключает условие CVE-2025-5777. [Параметр icaOnly](https://developer-docs.netscaler.com/en-us/adc-command-reference-int/current-release/vpn/vpn-vserver.html).

В сценарий специально закладываю две ошибки. Первая: на B осталось 3,2 GB в /var — по актуальным требованиям этого недостаточно. Освобождаю место после сохранения журналов и backup, добиваюсь успешной предварительной проверки. Вторая: заявка содержит обновление только A. Исправляю последовательность на B → переключение → A → проверка обоих узлов. На окно закладываю 90 минут, включая восстановление; это плановый резерв, не измеренная длительность установки. Лицензирование новой сборки на обоих узлах включаю в предварительные условия.

Финал успешного сценария выглядит так: оба устройства показывают 14.1-73.33, HA синхронизирована, тестовый вход и запуск приложения проходят после переключения в каждую сторону. При временно ограниченном доступе прежние ICA-соединения завершены, PCoIP-соединений нет; после открытия входа пользователи подключаются заново. Отдельно выполнен запланированный сброс AAA-сессий. Я не приписываю модели измеренный простой или доказанное отсутствие кражи: её результат — проверяемый порядок приёмки, который не позволяет закрыть заявку с непрошитым резервом.

7. Заявку на обновление закрываю, проверку инцидента продолжаю

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

Для проверки возможной эксплуатации сопоставляю внешние syslog, события аутентификации и активность на доступных через шлюз системах. Производитель предлагает искать сочетание `AAA Message`, `Authentication is rejected for ` и не-ASCII-байтов. Смена клиентского IP внутри сессии заслуживает проверки, но сама по себе не доказывает кражу: человек мог сменить сеть. Отсутствие признаков тоже не оправдательный сертификат, особенно если старые локальные журналы уже ротированы. [Рекомендации по анализу журналов](https://www.netscaler.com/blog/news/evaluating-netscaler-logs-for-indicators-of-attempted-exploitation-of-cve-2025-5777/).

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

Частые вопросы