Не ограничивайтесь установкой исправления: защитите шлюз NetScaler от будущих уязвимостей19.10.2026 16:00

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

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

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

Citrix выпустила обновления программного обеспечения для устранения уязвимости, а 1 октября Cloudflare выпустила экстренное правило для межсетевого экрана веб-приложений (WAF). Но наличие обновления ещё не гарантирует безопасность: необходимо выявить, обновить и протестировать каждый экземпляр. Установка обновлений в рабочей среде — непростая задача: она может привести к простоям или помешать сотрудникам, которым в это время нужен доступ к рабочим столам. Клиентов, пациентов и других людей, зависящих от пользователей удалённого рабочего стола, совершенно не волнует, что вы устанавливаете обновление безопасности.

Межсетевой экран веб-приложений (WAF) может дать дополнительное время, пока обновление не будет полностью развёрнуто, но это реактивная мера, не учитывающая следующую обнаруженную уязвимость. Cloudflare и другие поставщики средств безопасности делают всё возможное, чтобы противостоять вариациям и похожим атакам. Однако ИИ ускоряет поиск злоумышленниками новых и ранее неизвестных вариантов атак. Поэтому крайне важно выстраивать многоуровневую защиту, чтобы отказ или уязвимость какого-либо программного обеспечения не приводили к серьёзному инциденту безопасности.

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

Эксплуатация уязвимости NetScaler

В  бюллетене Citrix от 27 сентября 2026 года сообщалось об обнаруженных случаях эксплуатации CVE-2026–88771 и CVE-2026–88772. Первая уязвимость позволяет выполнять команды на уязвимых устройствах без аутентификации, в том числе при конфигурации по умолчанию. Вторая затрагивает конфигурации, использующие протокол защиты транспортного уровня на основе дейтаграмм (DTLS). В дополнительных рекомендациях от 3 октября и 8 октября рассматривались другие уязвимости в конфигурациях SAML. Эти атаки позволяли злоумышленникам запускать произвольные скрипты на целевых устройствах, а также проводить атаки типа «отказ в обслуживании».

Предупреждение CISA и техническое расследование Mandiant подробнее описывают уязвимости, зафиксированные случаи их эксплуатации и рекомендации по реагированию. Подробнее о доступной защите веб-приложений читайте в описании экстренного правила Cloudflare WAF для CVE-2026–88771.

В типичной конфигурации Citrix пользователь проходит аутентификацию через NetScaler Gateway, который затем использует службу авторизации защищённых билетов для передачи запроса в StoreFront. Там отображаются приложения и рабочие столы, доступные этому пользователю. Установленное на устройстве приложение Citrix использует эти сведения для установления отдельного соединения по протоколу Independent Computing Architecture (ICA) компании Citrix. Прежде чем проксировать соединение с рабочим столом, шлюз проверяет билет. Citrix описывает эти этапы как отдельные стадии процесса подключения. Вся атака стала возможной из-за того, что Gateway должен быть общедоступен через Интернет, иначе пользователи не смогли бы инициировать подключение к рабочему столу.

Разместите решение о предоставлении доступа перед сервером аутентификации

Лучшее, что можно сделать после установки обновлений на всех экземплярах, — перенести все общедоступные страницы входа и приложения за систему единого входа, чтобы запросы не достигали целевого сервера до её проверки. Cloudflare Access может применять независимую политику доступа до того, как запрос достигнет существующего сервера-шлюза. Среда Citrix по-прежнему определяет, какой рабочий стол может запустить пользователь, и проверяет полученный билет сеанса. Дополнительный рубеж защиты не позволит злоумышленнику добраться до сервера Gateway и попытаться использовать конкретные уязвимости. Ему будет видна только страница входа Cloudflare Access.

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

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

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

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

Подключение к исходному серверу должно обеспечивать такой же уровень защиты

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

Cloudflare Tunnel — наиболее распространённый вариант. Он создаёт только исходящий туннель от сервера приложения и позволяет закрыть все входящие IP-подключения. Это означает, что у сервера не будет общедоступного IP-адреса, доступного кому угодно.

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

Аутентифицированные запросы к исходному серверу могут дополнительно усилить защиту за счёт взаимной TLS-аутентификации соединения между Cloudflare и исходным сервером.

Исходный сервер, поддерживающий такую возможность, также можетпроверять JSON Web Token Access, включая его подпись, издателя, срок действия и целевую аудиторию приложения. Это лучший способ гарантировать, что запрос прошёл аутентификацию в Access.

Если вы не знаете, с чего начать,  обратитесь к эксперту Cloudflare, чтобы оценить свою архитектуру и определить, какие средства контроля подходят для вашей среды.

Защитите службу аутентификации, доступную через Интернет

Cloudflare Access определяет, кому разрешено обращаться к веб-приложению; межсетевой экран веб-приложений (WAF) Cloudflare проверяет HTTP-запросы к той же защищённой службе. WAF работает до проверок аутентификации Access, что позволяет полностью блокировать заведомо вредоносные IP-адреса, отдельные страны, ASN и другие источники, которым точно не следует обращаться к вашим приложениям. Брандмауэр непрерывно проверяет все запросы, а также выявляет пользователей, которым удалось пройти аутентификацию и которые пытаются использовать уязвимости с известными сигнатурами CVE.

Помимо управляемых сигнатур CVE, оценка опасности атаки WAF использует машинное обучение, чтобы выявлять потенциально вредоносные запросы, не совпадающие в точности с известными правилами. Администраторы могут использовать эту оценку в правилах, блокирующих запросы или требующих дополнительной проверки. Оценка опасности атаки WAF основана на данных наблюдений за сетевым трафиком глобальной сети Cloudflare и на материалах расследований Cloudforce One —общей платформы Cloudflare для анализа угроз.

Клиенты с подпиской на аналитику угроз Cloudforce One также могутиспользовать актуальные индикаторы угроз в политиках WAF. Это позволяет учитывать сведения об известных вредоносных источниках наряду с проверкой самого запроса.

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

Распространите Zero Trust на доступ к рабочему столу или откажитесь от зависимости от него

Защита веб-аутентификации может стать первым шагом, но не обязательно определять итоговую архитектуру. Архитектура Zero Trust для виртуальных рабочих столов Cloudflare также позволяет контролировать доступ непосредственно к инфраструктуре рабочих столов. С помощью Cloudflare One Client и подключения к частной сети команды могут ограничивать круг пользователей и устройств, которым разрешено обращаться к конечным точкам, передающим трафик рабочего стола, в том числе по существующему пути Independent Computing Architecture (ICA). Для этого необходимо отдельно спроектировать маршрутизацию и политики; один лишь прокси аутентификации в браузере такой возможности не предоставляет.

В некоторых рабочих процессах можно вовсе отказаться от ICA. Для поддерживаемых рабочих нагрузок Windows удалённый доступ к рабочему столу через браузер от Cloudflare подключает пользователей к хосту Windows через Cloudflare Tunnel без локального клиента удалённого рабочего стола. Если пользователям нужен рабочий стол только для открытия веб-приложений, Access и Browser Isolation могутзаменить этот сценарий использования без перехода на полноценный виртуальный рабочий стол.

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

Определите, какие службы аутентификации должны быть общедоступны

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

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

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

1. Отправьте запрос к защищённому имени хоста, не входя в систему. Убедитесь, что запрос останавливается на Cloudflare и не достигает исходного сервера.
2. Войдите с тестовой учётной записью, не входящей в разрешённую группу. Убедитесь, что она по-прежнему не может получить доступ к защищённому приложению.
3. Проверьте прямые адреса исходного сервера и альтернативные имена хоста. Убедитесь, что ни один из них не позволяет обойти политику доступа.
4. Войдите как пользователь с разрешённым доступом. Убедитесь, что аутентификация, запуск рабочего стола и повторное подключение к сеансу работают.

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

Объедините средства защиты

Полная архитектура размещает перед NetScaler проверку доступа, анализ веб-трафика и средства обеспечения доступности, а также ограничивает подключения к исходному серверу. Подключение к общедоступному исходному серверу и Tunnel — альтернативные варианты. Нативное подключение к рабочему столу остаётся отдельным, а вокруг этого трафика при желании можно установить дополнительный уровень сетевого доступа Zero Trust.

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

Начните работу

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

В подготовке этой публикации участвовали Андрей Мигия, Натан Сакетт и Даг Шеперд.

© Cloudflare Blog