Недавнее раскрытие информации о серьезной уязвимости в Citrix NetScaler указало на распространенное слабое место: страница входа представляет собой поверхность атаки, которая может быть использована для компрометации и доступа к серверу приложений. Действительно, среди the disclosuresопубликованных данныхthe disclosures фигурировала активно эксплуатируемая ошибка, которая позволяла злоумышленникам выполнять команды на уязвимых шлюзах без прохождения аутентификации. Как и в случае с любым экстренным патчем, администраторам пришлось взвешивать риски отключения или нарушения доступа пользователей против риска задержки критического обновления безопасности.
Если вы являетесь клиентом NetScaler и еще не установили патч для своего экземпляра, прекратите читать и сделайте это. Это серьезная проблема. После того как вы закончите патчинг, мы рассмотрим, как избежать будущей суматохи путем внедрения дополнительных средств контроля безопасности.
Эта проблема выходит за рамки NetScaler и применима к любому внутреннему приложению, доступному в Интернете. Порталы удаленного рабочего стола, административные консоли и другие общедоступные страницы аутентификации заслуживают одинакового внимания: требуется ли целевой аудитории неограниченный доступ в Интернет? И может ли злоумышленник обойти эту проверку подлинности, чтобы добраться до сервера приложения?
Компания Citrix выпустила обновления программного обеспечения для устранения этой ошибки, а компания Cloudflare выпустила экстренное правило веб-фаервола (WAF) 1 октября. Но наличие патча не гарантирует безопасность: каждый экземпляр необходимо выявить, обновить и протестировать. Применение обновлений в рабочей среде — сложный процесс, который может привести к простоям или нарушениям в работе сотрудников, которым по-прежнему нужны их рабочие столы. Клиенты, пациенты и другие пользователи, зависящие от удаленного рабочего стола, определенно не заботятся о вашем патче безопасности.
Использование брандмауэра веб-приложений (WAF) может выиграть дополнительное время до того, как патч будет полностью развернут, но это реактивная мера, которая не учитывает следующую обнаруженную эксплойт-угрозу. Cloudflare и другие поставщики средств безопасности делают все возможное, чтобы охватить вариации и аналогичные атаки. Но ИИ ускоряет скорость, с которой злоумышленники могут обнаруживать новые и необычные варианты. Вот почему крайне важно выстроить эшелонированную защиту, чтобы гарантировать, что ни один сбой программного обеспечения или эксплойт не приведет к критической проблеме безопасности.
Cloudflare сочетает политики доступа, безопасность веб-приложений и ограниченные подключения к источнику для защиты службы аутентификации до того, как будет обнародована новая уязвимость. Элементы контроля доступа ограничивают тех, кто может получить доступ к серверу приложений; проверка WAF оценивает веб-запросы на наличие атак; ограничения исходного сервера предотвращают прямое подключение в обход этих средств защиты. Это снижает риски без необходимости ожидания новой сигнатуры эксплойта или замены существующей платформы рабочих столов.
Эксплойт для NetScaler
Citrix сообщила о зафиксированных случаях эксплуатации уязвимостей CVE-2026-88771 и CVE-2026-88772. Первая позволяет выполнять команды без аутентификации на уязвимых устройствах, в том числе в конфигурации по умолчанию. Вторая затрагивает конфигурации, использующие протокол защищенности транспортного уровня датаграмм (DTLS). Дополнительные бюллетени по October 3 и October 8 устраняли другие уязвимости в конфигурациях SAML. Эти эксплойты позволяли злоумышленникам выполнять произвольные скрипты на целевых машинах, а также организовывать атаки типа «отказ в обслуживании» (DoS).
В предупреждении CISA и техническом исследовании Mandiant уязвимости, наблюдаемая эксплуатация и рекомендации по реагированию описаны более подробно. Подробную информацию о доступной защите веб-приложений см. в .
В типичной среде Citrix пользователь проходит аутентификацию через шлюз NetScaler Gateway, который затем использует службу выдачи защищенных билетов (ticket authority) для передачи данных в StoreFront, отображающий доступные пользователю приложения и рабочие столы. Установленное на устройстве приложение Citrix затем использует эту информацию для установления отдельного соединения по протоколу независимой архитектуры вычислений Citrix (ICA). Шлюз проверяет билет перед проксированием подключения к рабочему столу. В документации Citrix эти этапы описаны как отдельные стадии рабочего процесса подключения. Весь эксплойт проистекает из того факта, что шлюз должен быть общедоступен в Интернете, иначе пользователи не смогли бы инициировать подключение к своему рабочему столу.
Перенесите решение об доступе перед сервер аутентификации
Лучшее, что вы можете сделать после исправления всех ваших экземпляров — это перенести любые общедоступные страницы входа или приложения за единый вход (SSO) до того, как запрос поступит на целевой сервер. Cloudflare Access может применять независимую политику доступа до того, как запрос достигнет существующего сервера шлюза. Среда Citrix по-прежнему определяет, какой рабочий стол может запустить пользователь, и проверяет полученный сессионный билет. Дополнительный периметр гарантирует, что злоумышленник никогда не сможет добраться до сервера шлюза для запуска конкретных эксплойтов. Он увидит только страницу входа Cloudflare Access.
Это решение больше не зависит от распознавания сигнатуры эксплойта и ее блокировки, а опирается на набор политик Zero Trust, которые определяют, должен ли этот пользователь вообще находиться в системе. На подходе еще больше подобных атак, и внедрение элементов управления Zero Trust во всей вашей сети — это самое важное, что вам следует сделать дальше.
Это следует принципу, описанному в собственной архитектуре Cloudflare как «клиент ноль»: уменьшите экспозицию и используйте независимую защиту, чтобы один сбой не привел к компрометации. Практической отправной точкой здесь является служба, к которой пользователи обращаются перед входом в свои приложения.
Защита пути веб-аутентификации добавляет периметр перед существующими элементами управления Citrix. Она не распространяет этот периметр автоматически на другие службы шлюза, включая прослушиватели с поддержкой DTLS. Эти интерфейсы по-прежнему нуждаются в собственном аудите доступности и применимых обновлениях безопасности, даже если поддерживаемые ими сеансы рабочих столов уже требуют аутентификации.
Исходное подключение должно обеспечивать соблюдение того же периметра
Изменения DNS-записи и принудительного применения политик Access недостаточно. Если злоумышленник может подключиться к исходному адресу или альтернативному имени хоста, он может обойти средства контроля, размещенные перед ним. Access применяет строго определенное имя хоста: если к серверу аутентификации можно получить доступ по IP-адресу или альтернативному имени хоста, то применение политик Access теряет смысл. Важно принять меры для обеспечения того, чтобы весь трафик поступал из запросов, проверенных с помощью Access. Существует несколько различных подходов для реализации этого в зависимости от вашей внутренней архитектуры.
Cloudflare Tunnel — наиболее часто используемый подход. Он устанавливает туннель только с исходящим трафиком от вашего сервера приложений и позволяет закрыть весь входящий IP-трафик. Это означает, что у сервера не будет публичного IP-адреса, к которому кто-либо мог бы получить доступ.
Когда общедоступный IP-адрес источника должен оставаться неизменным или нет возможности запустить программное обеспечение коннектора, сетевые ограничения и аутентификация источника должны ограничивать принимаемые им соединения. Например, выделенные исходящие IP-адреса CDN предоставляют аккаунту выделенные адреса-источники для трафика от Cloudflare к его источникам. Брандмауэр сервера приложения может разрешать эти адреса и отклонять другие источники. Это делает сетевое ограничение специфичным для трафика аккаунта, а не разрешает трафик из общих диапазонов адресов Cloudflare широким образом.
Проверка подлинности при обращении к источнику (Authenticated Origin Pulls) может добавить дополнительный уровень безопасности с помощью взаимного TLS для проверки соединения между Cloudflare и источником.
Источник, поддерживающий это, может также проверить JSON Web Token Access, включая его подпись, издателя, срок действия и целевую аудиторию приложения. Это лучший способ гарантировать, что запрос был аутентифицирован с помощью Access.
Если вы не знаете, с чего начать, проконсультируйтесь со специалистом Cloudflare, чтобы оценить вашу архитектуру и определить, какие элементы управления подходят для вашей среды.
Защитите веб-службу аутентификации
Cloudflare Access определяет, кто может получить доступ к веб-приложению; брандмауэр веб-приложений (WAF) компании Cloudflare проверяет HTTP-запросы к тому же защищенному сервису. WAF запускается до любых проверок аутентификации Access, что дает вам возможность полностью блокировать известные вредоносные IP-адреса, определенные страны, номера автономных систем (ASN) или другие атрибуты, которые, как вы точно знаете, не должны иметь доступа к вашим приложениям. Брандмауэр работает непрерывно для всех запросов, а также выявляет пользователей, которым удалось пройти аутентификацию, при попытке запустить эксплойты с известными сигнатурами CVE.
Наряду с управляемыми сигнатурами CVE, оценка атак WAF (WAF Attack Score) использует машинное обучение для выявления потенциально вредоносных запросов, которые не полностью соответствуют известному правилу. Администраторы могут использовать эту оценку в правилах, которые блокируют запросы или требуют их подтверждения. Оценка атак WAF основана на наблюдениях за сетью в глобальной сети Cloudflare, а каналы исследований Cloudforce One питают платформу обмена данными об угрозах Cloudflare.
Клиенты с подпиской на аналитику угроз Cloudforce One также могут использовать актуальные индикаторы угроз в политиках WAF. Это добавляет контекст об известных вредоносных источниках в дополнение к проверке самого запроса.
Снижение уровня уязвимости не устраняет злоумышленника, который уже закрепился в системе. Серьезно: обновите систему, если вы еще этого не сделали, и следуйте руководству Citrix по подозрению на взлом. В нем описано, как сохранять доказательства, отзывать учетные данные и сертификаты, расследовать подключенные системы, а также выполнять переустройку или восстановление из заведомо исправного состояния.
Расширьте возможности Zero Trust на доступ с настольных ПК или откажитесь от зависимости от них
Защита веб-аутентификации может быть первым шагом, а не окончательной архитектурой. Архитектура Zero Trust от Cloudflare для виртуальных рабочих столов также поддерживает контроль доступа к самой инфраструктуре рабочего стола. С помощью клиента Cloudflare One и подключения к частной сети команды могут ограничивать пользователей и устройства, которые могут достигать конечных точек, передающих трафик рабочего стола, включая существующий путь Independent Computing Architecture (ICA). Для этого требуется собственная маршрутизация и проектирование политик; это не та функция, которую может обеспечить только прокси веб-аутентификации.
Некоторые рабочие процессы позволяют избавиться от зависимости от ICA. Для поддерживаемых рабочих нагрузок Windows удаленный доступ к рабочему столу на базе браузера от Cloudflare подключает пользователей к хосту Windows через Cloudflare Tunnel без использования локального клиента удаленного рабочего стола. Если пользователям нужен рабочий стол только для открытия веб-приложений, Access и Browser Isolation могут заменить этот сценарий использования веб-доступа без необходимости развертывания полноценного виртуального рабочего стола.
Начните с защиты службы аутентификации и существующих подключений к рабочему столу. Затем замените виртуальные рабочие столы, используемые только для веб-доступа, и перенесите поддерживаемые рабочие нагрузки Windows на удаленные рабочие столы на базе браузера. Снижение уровня уязвимости не требует обязательного ожидания полной миграции рабочих столов.
Определите, какие службы аутентификации должны быть общедоступными
Такая же оценка применима и за пределами виртуальных рабочих столов. Портал для сотрудников или консоль управления могут быть доступны авторизованным пользователям из любого места, при этом нет необходимости принимать запросы приложений от всех подряд.
Не каждая страница аутентификации может требовать предварительного подтверждения личности сотрудника. Страницы входа для клиентов и конечные точки поставщика удостоверений, необходимые для установки первоначального сеанса, возможно, должны оставаться общедоступными. Защищайте их осознанно и избегайте появления циклических зависимостей аутентификации. Смысл в том, чтобы сделать доступность вопросом проектирования, а не унаследованным поведением по умолчанию.
Начните с одной ограниченной службы. Сопоставьте с ней веб-пути и пути, не связанные с веб, а затем поместите решение о доступе перед ее интерфейсом аутентификации. Прежде чем расширять развертывание, проверьте границу в собственной среде:
- Запросите защищенное имя хоста без входа в систему. Убедитесь, что запрос останавливается на уровне Cloudflare, а не доходит до источника.
- Войдите в систему с помощью тестовой учетной записи вне разрешенной группы. Убедитесь, что она по-прежнему не может получить доступ к защищенному приложению.
- Проверьте адреса прямых источников и альтернативные имена хостов. Убедитесь, что ни одно из них не обходит политику доступа.
- Войдите в систему как утвержденный пользователь. Убедитесь, что аутентификация, запуск рабочего стола и возобновление сеанса по брандмауэру по-прежнему работают.
Проверяйте соответствующие журналы политик, брандмауэра и источника, а не полагайтесь только на то, что отображает браузер. Повторяйте эти проверки при изменении настроек маршрутизации, идентификации или отработки отказа, чтобы следующее обновление конфигурации случайно не открыло путь, который вы закрыли.
Объедините средства управления
Полноценная архитектура выводит решение о доступе, веб-проверку и элементы управления доступностью перед NetScaler с ограничениями на подключение к источнику. Общедоступный источник и пути Tunnel являются альтернативами. Собственное подключение к рабочему столу остается изолированным, а вокруг этого трафика располагается дополнительный уровень сетевого доступа Zero Trust.
Начало работы
Проконсультируйтесь со специалистом Cloudflare, чтобы спланировать правильные элементы управления для вашей среды. Загрузите описание решения и
Андрей Мигия, Натан Сакетт и Даг Шепард внесли свой вклад в подготовку этой публикации.
