Вывод из эксплуатации устаревших компонентов Citrix Gateway

Компания Citrix вместе с релизом Citrix ADC 12.0 (сборка 41.16) анонсировала устаревшие компоненты (Deprecated). Эти компоненты, такие как классические политики (Classic Policy), некоторые темы оформления и классический анализ конечного устройства (EPA) по прежнем поддерживаются в релизах 12.1 и 13.0.

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

Классические политики (Classic Policies).

Политики Citrix ADC используются для управления проверкой данных компонентами. Классические политики оценивают базовые характеристики трафика, в то время как инфраструктура продвинутых политик (Advanced Policy) позволяет анализировать больше данных и настраивать больше операций в правилах. Об отказе от классических политик впервые было объявлено несколько лет назад, я даже писал об этом в статье «Перевод механизма обработки трафика на инфраструктуру расширенных политик (Advanced Policy) в Citrix ADC».

Примечание.

Классические политики для Gateway и AAA продолжат поддерживаться без изменений функционала вплоть до второго квартала 2023-го года.

Для перехода на продвинутые политики существует инструмент Citrix ADC – nspepi, который можно использовать для конвертации команд, выражений и конфигурации. В качестве альтернативы, редактор выражений в графическом интерфейсе Citrix ADC – это отличный путь для ручной переделки классических выражений в продвинутые.

Необходимо отметить, что рекомендуется конвертировать все классические политики в продвинутые, чтобы использовать полностью поддерживаемую конфигурацию. В том числе, это касается таких политик как LDAP, RADIUS, сертификатов (CERT), syslog и политик сессий (session).

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

Убедитесь, что продвинутые политики созданы для замены каждой классической и привязаны к виртуальным серверам.

Продвинутые политики аутентификации (Advanced Authentication Policy).

В случае использования Citrix Gateway для проксирования ICA или VPN, политики аутентификации привязываются как обязательная часть настройки. Классические политики аутентификации могут быть привязаны в секцию базовой аутентификации (Basic Authentication) виртуального сервера Citrix Gateway, но продвинутые политики так не работают. Чтобы использовать продвинутые политики аутентификации, необходимо настроить виртуальный сервер аутентификации и привязать его в профиль аутентификации на виртуальном сервере Citrix Gateway.

В сценарии с одним фактором это также просто как создать виртуальный сервер аутентификации и привязать продвинутую политику аутентификации со схемой входа (Login Schema) к серверу. Для сценариев с несколькими факторами, необходимо настроить аутентификацию nFactor. Поддержка nFactor для Citrix Gateway доступна с релиза 11.1, таким образом достаточно много информации о настройке уже существует. Вместе с релизом Citrix ADC 13.0, сборка 36.27, добавлена новая возможность для упрощения настройки nFactor при помощи графического интерфейса – nFactor Visualizer.

Мобильные политики (Citrix Workspace App).

Для сценариев двухфакторной аутентификации LDAP и RADIUS с мобильными устройствами, может возникнуть потребность в некоторых изменениях, которые необходимо внести в политики сессий. Это связано с тем, что при использовании потока nFactor, нужен только один поток для мобильных и не мобильных соединений. При использовании базовой аутентификации потоки разделены.

Ранее, при настройке Citrix Gateway на использование аутентификации RADIUS и LDAP с мобильными устройствами, LDAP настраивался в качестве основной политики для веб-соединений, а для соединений Receiver/Workspace в качестве вторичной политики. На диаграмме ниже представлен пример настройки двухфакторной базовой аутентификации с LDAP и RADIUS.

В такой конфигурации, индекс учётных данных в политиках сессий, указывающих на LDAP, должен был отличаться для веб и мобильных соединений. Для веб-соединений индекс учётных данных должен быть установлен в значение основного (Primary), а для соединений Citrix Workspace в значение вторичного (Secondary). При использовании потока nFactor и продвинутых политик, единый поток может обрабатывать как мобильные, так и не мобильные устройства. Это значит, что LDAP может являться основной политикой для обоих сценариев использования, а политика RADIUS будет вторичной. Если политика сессий Citrix Workspace ранее указывала на вторичный индекс учётных данных, ее необходимо обновить на первичную, для успешной аутентификации мобильных устройств на Citrix Gateway.

Темы оформления.

Вместе с отказом от классических политик, устаревшими также становятся и ряд тем оформления. При использовании оформления по умолчанию (Default), Green Bubble или X1, вы могли видеть предупреждение, указывающее на устаревание данных тем и их недоступность в будущих релизах.

Рекомендуется использовать тему оформления RFWebUI с конфигурацией nFactor и продвинутыми политиками. При использовании одной из устаревших тем с внесёнными изменениями, необходимо учесть, что изменения не перенесутся на RFWebUI. Механизм внесения изменений RFWebUI отличается и потребует перенастройки. Одним из отличий является то, что страница входа хранится в другом расположении (/var/netscaler/logon/LogonPoint/) в отличии от устаревших тем (/netscaler/ns_gui/vpn/). Файлы, которые необходимо настраивать для RfWebUI, также отличаются: index.html, strings.en.json и theme.css.

Дополнительные рекомендации.

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

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

Рекомендуется использовать анализ конечного устройства (EPA) с nFactor вместо классического анализа (Classic EPA). Это значит, что любая политика пред-аутентификации или пост-аутентификации, которая привязана напрямую к Citrix Gateway, должна быть удалена и заменена конфигурацией с использованием виртуального сервера аутентификации.

Основные выводы.

Клиенты Citrix, заинтересованные в отказе от устаревших компонентов, должны рассмотреть следующие рекомендации:

• Конвертировать все классические политики в продвинутые.
• Выполнить поиск по активной конфигурации (Running), чтобы убедиться, что классические выражения не были пропущены.
• Использовать виртуальный сервер аутентификации для привязки продвинутых политик к виртуальному серверу Citrix Gateway.
• Использовать nFactor Visualizer (новый компонент в Citrix ADC 13.0) для упрощения настройки nFactor.
• Убедиться, что индекс учётных данных в политике сессий соответствует факторам LDAP.
• Переключить старые неподдерживаемые темы на RfWebUI.
• Отвязать все классические политики от компонентов перед привязкой продвинутых политик.
• Настроить nFactor EPA для любых политик пред и пост-аутентификации.

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

Настройка зон сервера BIND в CentOS Stream 9

Второй, он же заключительный, веб-каст на тему сервера разрешения имён BIND в CentOS Stream 9. В веб-касте представлено описание и демонстрации настройки зон прямого и обратного просмотра для сервера BIND. Помимо этого, демонстрируется локальная и удаленная проверка разрешения имён, а также диагностика работы сервера при помощи системного журнала (Journald).

Подробности и видео: LebedevUM

P.S. Это второй, заключительный веб-каст в группе, поэтому если вы не знакомы с сервером разрешения имен, рекомендую начать просмотр с веб-каста «Установка сервера BIND в CentOS Stream 9».

Посмотреть эту публикацию в Instagram

Публикация от Yuriy Lebedev (@lebedevum)

Ускорение синхронизации конфигурации GSLB при помощи Citrix ADC

Глобальная балансировка нагрузки серверов (GSLB) – это слабо связанная распределенная система между несколькими центрами обработки данных или точками присутствия в различных географических расположениях. В связи с этим, обеспечение целостной конфигурации между всеми узлами GSLB может стать испытанием. Для решения данной задачи в Citrix ADC используется возможность синхронизации GSLB. В прошлый раз мы рассматривали, как эта возможность упрощает управление для администраторов.

По мере роста развертывания GSLB, вместе с увеличением и усложнением конфигурации, возникает задача о необходимости синхронизировать конфигурацию в реальном времени. Дополнительную сложность может представлять задержка между определенными узлами GSLB в 100-300 миллисекунд.

Далее мы рассмотрим новую возможность инкрементальной синхронизации в Citrix ADC (Релиз 13.0, сборка 79.x) и то, как она помогает синхронизировать конфигурацию между узлами GSLB в реальном времени с поддержкой отказоустойчивости вне зависимости от конфигурации или развертывания GSLB.

Сокращение времени синхронизации при помощи инкрементальной синхронизации.

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

set gslb parameter -automaticConfigSync ENABLED

Затем данный сайт используется для применения конфигурации, необходимой в развертывании. Это обязанность сайта – синхронизировать конфигурацию во все остальные сайты GSLB (подчинённые сайты).

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

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

Полная синхронизация конфигурации.

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

В таких сценариях выполняться полная синхронизация конфигурации GSLB, в рамках которой весь файл конфигурации GSLB передается из основного сайта в подчинённый и сравнивается с конфигурацией подчинённого сайта. Различия в конфигурации применяются к подчинённому сайту.

Синхронизация файлов геолокации и ключей/сертификатов.

Синхронизация GSLB также отвечает за передачу файлов, используемых в развертывании GSLB, таких как файлы геолокации, которые используются в методе статической близости GSLB, сертификатов SSL и пар ключей, используемых для сервисов GSLB (кроме конфигурации). Эти файлы должны быть синхронизированы только тогда, когда они становятся частью конфигурации GSLB за счёт ассоциации с сущностями GSLB.

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

set gslb parameter -GSLBSyncLocFiles DISABLED

Все вместе эти обновления компонента GSLB существенно сокращают общее время синхронизации, как показано в таблице ниже (таблица показывает сравнение полной и инкрементальной синхронизации для нескольких строк изменённой конфигурации в развертывании GSLB, состоящем из трёх сайтов с круговой задержкой (RTT) в 200 миллисекунд от основного сайта до подчинённых и базовой конфигурацией GSLB размером примерно в 75000 строк.

Синхронизация	Время
Полная синхронизация (Full Synchronization)	181 секунда
Инкрементальная синхронизация (Incremental Synchronization)	8 секунд

Отказоустойчивая синхронизация конфигурации.

Данное обновление компонента синхронизации GSLB также включает в себя возможности мониторинга сайтов GSLB, которое преследует две цели.

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

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

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

set gslb parameter -GSLBConfigSyncMonitor ENABLED

Заключение.

Компонент инкрементальной синхронизации, вместе с возможностью мониторинга сайта позволяет настраивать быструю и устойчивую синхронизацию конфигурации, которая способна помочь с решением задачи управления динамическими обновлениями конфигурации. Узнать больше о глобальной балансировки серверов (GSLB) и синхронизации конфигурации можно при помощи официальной документации по продукту и моей предыдущей статьи «Упрощение управления устройствам Citrix ADC в конфигурации глобальной балансировки серверов (GSLB)».

Упрощение управления устройствами Citrix ADC в конфигурации глобальной балансировки серверов (GSLB)

Устойчивость и отказоустойчивость встроены в протокол DNS. Если сервер имен не может ответить на запрос, клиент DNS отказывается от этого сервера после настроенного количества повторных попыток. Затем клиент отправляет запрос на другой сервер, который представляется авторитетным сервером имен для запрашиваемого доменного имени.

Система доменных имен (DNS) – это слабо связанная распределенная система, при этом все сервера имен должны иметь комплексное представление о конфигурации, чтобы клиент получал целостный ответ. Будучи расширением DNS – GSLB позволяет адаптировать ответ к динамическим рабочим нагрузкам. Это значит, что необходимо иметь целостную конфигурацию GSLB между всеми участвующими серверами имен. Отказоустойчивость – это обязательная основа при обработке запросов DNS и в настройке серверов имен для GSLB.

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

Далее мы рассмотрим, как Citrix ADC может предоставить отказоустойчивую распределенную плоскость управления для GSLB, упрощая администраторам ИТ управление устройствами GSLB.

Целостное представление GSLB.

Если DNS отключается, пользователи не могут получить доступ к приложениям. Иметь как минимум один уровень устойчивости – это критически важная задача, поэтому устройства GSLB должны быть настроены в режиме Active-Active, при котором все устройства активно обрабатывают запросы DNS. Чтобы клиентские запросы DNS обрабатывались на любом устройстве в группе, все устройства должны иметь целостное представление:

• О конфигурации GSLB.
• Об информации выполнения (Runtime Information).

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

Протокол обмена показателями (Metric Exchange Protocol, MEP) в Citrix ADC доставляет комплексное представление о текущем состоянии между устройствами GSLB, а возможность синхронизации конфигурации GSLB в реальном времени предлагает целостное представление о конфигурации.

Целостность конфигурации GSLB.

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

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

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

Статус синхронизации GSLB.

Можно просмотреть статус синхронизации GSLB при помощи команды show gslb syncstatus. Если включить предупреждение GSLB-SYNC-STATUS-FLIP администратор будет получать уведомления о всех ошибках синхронизации GSLB и сможет предпринять необходимые действия при помощи опций уведомления.

Заключение.

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

Узнать больше про Citrix ADC и глобальную балансировку серверов можно в документации по продукту и Citrix Tech Zone.

Шифры безопасности и их реализация в Citrix ADC

Многие специалисты по информационным технологиям отлично ориентируются в основах шифрования SSL/TLS, а также в окружающих терминах, таких как «Heartbleed» и «POODLE». Но теория и реальный мир в ряде аспектов – это две абсолютно разные вещи, и опросы клиентов Citrix ADC показали, что многие используют конфигурацию из коробки для своих критических приложений. В том числе это касается и выбора наборов шифров SSL для коммуникаций клиентов с ADC (Client-to-ADC) и ADC с серверами (ADC-to-Server).

Корректный выбор и применение наборов шифров крайне важен не только для безопасности бизнес-приложений, но и для обеспечения доступности пользовательских возможностей. Далее мы рассмотрим, как корректно выбирать наборы шифров для окружений и управлять ими при помощи Citrix ADC, обеспечивая безопасность и доступность окружений.

Структура набора шифров (Cipher Suite).

Рассмотрим набор шифров SSL на примере набора от TLS 1.2.

Наиболее важными частями в наборе шифров (Cipher Suite) являются обмен ключами (Key Exchange) и массовое шифрование (Bulk Encryption). Которые определяют способ начального обмена ключами шифрования SSL и последующее шифрование данных во время сессии. Секция сигнатуры (Signature) менее интересна в разрезе нашего рассмотрения, но она оказывает непосредственное влияние на производительность.

Обмен ключами (Key Exchange):

• RSA – один из старейших методов обмена ключами, он обычно используется для обеспечения совместимости со старыми клиентами, его использование постепенно сокращается.
• DHE – обмен Диффи-Хеллмана (Diffie-Hellman) позволяет двум участникам независимо друг от друга сгенерировать общий секрет без риска компрометации.
• ECDHE – Версия с эллиптической кривой для DHE обладает свойствами DHE, но при этом использует меньше вычислительных ресурсов.

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

Массовое шифрование (Bulk Encryption):

• RC4 – это устаревший шифр, который использовался из-за его простоты и скорости, но из-за серьезных уязвимостей лучше отказаться от его использования.
• DES – это ещё один устаревший шифр, обладающий ключом с короткой длиной, который также не следует использовать.
• 3DES – запущенный три раза DES для достижения дополнительной безопасности. Постепенно от него отказываются и единственный сценарий, когда его использование оправдано – это обеспечение совместимости.
• AES – наиболее популярный шифр данных, используемый в SSL.
• ChaCha20 – современный, безопасный, быстрый шифр, который набирает популярность.

К счастью, стандарты TLS 1.3 немного проще за счёт того, что они поддерживают только эфемерный обмен ключами Диффи-Хеллмана (Diffie-Hellman), нужно только перечислить шифр массового шифрования данных и алгоритм аутентификации сообщений. Пример шифра TLS 1.3: TLS_AES_256_GCM_SHA384.

Теперь, когда мы прошлись по основам, рассмотрим, как определяются наборы шифров для соединений SSL. 

Процесс квитирования SSL.

В процессе начального квитирования SSL, клиент отправляет список шифров на сервер, в порядке предпочтения. Это сообщение называется clientHello, его можно легко увидеть в трассировке Wireshark, если открыть первый пакет, отправленный от клиента к серверу.

Пример, секции наборов шифров (Cipher Suites):

На снимке экрана, клиент предпочитает наборы шифров TLS 1.3, затем запрашивает шифры ECDHE от TLS 1.2, если соединение TLS 1.3 невозможно установить.

Наиболее важная вещь, которую нужно отметить – сервер SSL/TLS отвечает за выбор набора шифров. Это значит, что клиенты подключающиеся к Citrix ADC, находятся под властью машины, соответственно, очень важно корректно настроить наборы шифров для ADC. В противном случае опубликованные приложения подвержены риску компрометации.

Citrix ADC и группы/наборы шифров.

Как же все вышесказанное применяется по отношению к Citrix ADC? 

В первую очередь необходимо запомнить тот факт, что Citrix ADC одновременно выступает как клиентом, так и сервером для разных потоков подключений. В терминологии ADC – это типы подключений SSL: BackEnd и FrontEnd.

Предпочтительный путь настройки целостных параметров ADC – это использовать профили SSL (SSL Profiles).

Можно добавить профили SSL для подключений FrontEnd и BackEnd, которые будут использовать виртуальные серверы (vServer) и SNIP для предоставления соединений и подключения к клиентам/сервисам.

Так же в профиле SSL в разделе продвинутых параметров (Advanced Settings) можно добавить группы шифров SSL.

Здесь необходимо установить наиболее безопасную группу шифров для использования по умолчанию во всех вновь создаваемых виртуальных серверах (vServer) на Citrix ADC. Важно отметить, что наборы шифров, перечисленные выше по списку, имеют большее предпочтение. Это значит, что если клиент поддерживает первый набор шифров в списке, то Citrix ADC его и выберет.

Рассмотри группу шифров по умолчанию (DEFAULT) в Citrix ADC.

На самом деле, в верху списка размещаются несколько шифров TLS 1.0, что означает их предпочтение в случае, если клиент их поддерживает. Именно поэтому важно проверить существующие профили/группы и создать собственные.

Рекомендации.

Золотое правило настройки: «Всегда размещайте более безопасные наборы шифров (Cipher Suite) в начале списка предпочтений (Preference List)».

Это значит, что всегда необходимо размещать наборы шифров, TLS 1.3 или TLS 1.2 с использованием обмена ключами ECDHE в начале списка предпочтений. Звучит достаточно просто, но есть ряд нюансов и исключений, которые необходимо учесть. Тем не менее, безопасность должна оставаться в приоритете.

Рекомендации по наборам шифров:

• Если это возможно, придерживайтесь золотого правила.
• Создавайте настраиваемую группу шифров по умолчанию для обоих типов подключений (FrontEnd и BackEnd). Не следует использовать группу шифров Citrix ADC по умолчанию без тщательной проверки.
• Создайте дополнительные настраиваемые группы шифров для каждого сервиса, требующего более или менее строгой безопасности.
• Если вы не уверены в том, что считать безопасным, а что нет, можете обратиться к новейшему списку предпочтений Windows Server 2022, чтобы увидеть, что Microsoft считает безопасным.

Предостережения по наборам шифров:

• Не используйте наборы шифров SSL3, TLS1 и TLS1.1 (если это возможно).
• Не размещайте небезопасные наборы шифров в начале групп шифров по умолчанию для исключительных сценариев. Вместо этого, используйте настраиваемые группы шифров для реализации требований и применяйте их только по необходимости.
• При размещении небезопасных наборов шифров убедитесь, что они находятся внизу списка.
• Не используйте уязвимые шифры для массового шифрования (Bulk Encryption), такие как RC4, DES или 3DES, если это возможно.

Совместимость и производительность.

Есть только две причины, по которым отходят от золотого правила (Всегда размещайте более безопасные наборы шифров в начале списка предпочтений): совместимость и производительность.

Совместимость (Compatibility).

Существуют ситуации, в большинстве своем связанные с подключениями клиентов (FrontEnd), когда Citrix ADC должен обслуживать клиентов со старыми операционными системами или приложениями, которые требуют устаревших версий TLS и/или наборов шифров. В таких ситуациях необходимо разобраться в бизнес-обоснованиях и совместно с командой обеспечения безопасности определить риски и дальнейшие шаги. Это очень важно, чтобы лица, принимающие решения, понимали риски, связанные с использованием небезопасных наборов шифров. Не следует принимать такое решение самостоятельно, не согласовав его со всеми заинтересованными сторонами.

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

Производительность (Performance).

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

Размеры ключей могут играть важную роль в производительности. Ключи шифрования большего размера – более безопасны, но во многих случаях стараются использовать достаточную, а не максимально возможную безопасность, с целью обеспечения необходимого уровня производительности. Например, ключ RSA с длиной 2048, считается безопасным, но при этом он меньше, чем ключи с длиной 3072 и 4096. Ключи большего размера предоставляют более высокий уровень безопасности, который, как правило, не требуется на сегодняшний день (или в ближайшем будущем). При этом увеличенная длина ключа будет создавать дополнительную нагрузку на вычислительные ресурсы при установке соединения SSL.

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

Несмотря на то, что это все правда, переход к обмену ключами DHE или ECDHE может существенно сократить общее количество запросов в секунду, которое система, такая как Citrix ADC сможет поддерживать. Это в двойне правда для старого оборудования, которое не имеет аппаратной поддержки для расчета эллиптических кривых, такого как аппаратные платформы (MPX) Citrix ADC 5900/8600/26000 с их чипсетами Intel Coleto Creek.

В таком случае, к вопросу выбора предпочтительных наборов шифров нужно подойти максимально серьезно (особенно для соединений FrontEnd), или можно оказаться в ситуации, когда пострадают возможности пользователей из-за перегруженности вычислительных ресурсов ADC.

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

Заключение.

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

P.S. Если тема траффика HTTPS вам интересна, я могу порекомендовать несколько моих статей по этой тематике: «HTTP3, TLS 1.3 и Citrix ADC» и «Использование Citrix ADC для развертывания сетевого моста QUIC».

Практический аспект настройки SSL/TLS для веб-серверов можно посмотреть в веб-кастах «Настройка SSL/TLS для Apache в CentOS 8» и «TLS-шифрование NGINX в CentOS 8».

Обеспечение безопасности инфраструктуры разрешения имен DNS при помощи Citrix ADC

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

Далее мы рассмотрим, как Citrix ADC может помочь защитить инфраструктуру DNS против известных уязвимостей.

Отравление кэша (Cache Poisoning).

Для уменьшения шанса атакующего на фальсификацию ответа (спуфинг), клиенты DNS должны случайным образом определить идентификатор транзакции и запроса DNS, а также эфемерный порт источника, используемый для отправки запроса DNS. Это требует от злоумышленника быстро угадать 32-ух битное целое число. Но если клиент DNS отправляет подряд несколько запросов серверу разрешения имен, то атакующий для успешной фальсификации ответа должен угадать только 16-ти битный идентификатор запроса (так как эфемерный порт источника UDP является константой).

Citrix ADC позволяет настроить ограничение числа запросов с одинаковым 4-ым полем в заголовке UDP. После достижения порогового значения, Citrix ADC начинает сбрасывать поступающие запросы UDP. Данный лимит можно настроить при помощи следующей команды:

set dns parameter -maxPipeline ЗНАЧЕНИЕ

Обратите внимание, установка параметра в значение ноль (0) обозначает отключения лимита в числе конвейерных запросов, таким образом, необходимо установить лимит в подходящее положительное целое число не равное 0.

Также можно включить DNSSEC для зоны, размещаемой на Citrix ADC, чтобы избежать отравления кэша (Cache Poisoning).

Атаки амплификации (Amplification Attacks).

В атаках амплификации DNS атакующий использует маленькие запросы, чтобы исчерпать ресурсы сервера DNS. Атака направлена на вычислительные ресурсы, память и пропускную способность сервера DNS, таким образом, за счет истощения ресурсов сервера, он перестает отвечать на корректные запросы от клиентов. Существуют разные способы защиты от атак амплификации DNS.

Одним из способов защиты инфраструктуры от атак амплификации DNS является белые (Whitelist) или черные списки (Blacklist) клиентских IP-адресов. Если защита на базе IP-адресов не подходит, можно определить шаблон атаки, настроить соответствующие политики при помощи выражений политик Citrix ADC и принудительно заставить клиентов, повторно инициировать запросы DNS по TCP. Дополнительно можно настроить конечные точки DNS на IP-адресах передачи любому из узлов (Anycast) для защиты от распределенных атак на доступность (DDoS).

Атака амплификации корневых ссылок (Root Referral Amplification Attack).

Авторитетным серверам DNS рекомендуется возвращать корневые записи NS в авторитетной секции ответа на запрос информации об имени домена, для которого сервер не авторизован. Размер корневых записей NS включает связующие записи, и достигает 512 байт. Это может увеличить запрос DNS как минимум в 5 раз. Атакующий может использовать спецификацию DNS для отправки запроса авторитетным серверам имен для доменов, не входящих в их зону ответственности.

Можно устранить эту угрозу при помощи Citrix ADC, отключив параметр настройки dnsRootReferral. В таком случае, Citrix ADC не будет отвечать на запросы доменов за пределами зон, для которых ADC настроен быть авторитетным.

set dns parameter -dnsRootReferral DISABLED

Атака амплификации на базе запроса ANY (ANY Query-Based Amplification Attack).

Тип запроса ANY возвращает все записи для указанного доменного имени. Это обозначает значительно больший размер ответа по сравнению с остальными запросами. Атакующие используют запросы ANY для выполнения распределенных атак на доступность (DDoS) уязвимой сетевой инфраструктуры. Для противостояния подобным угрозам можно настроить ограничивающие политики (Rate-Limiting) для запрещения запросов ANY сверх установленного лимита.

add stream selector dns_anyquery_amplification "dns.req.question.type.eq(ANY)"

add ns limitIdentifierdns_ampl_attack_limitid -threshold 1000 -timeSlice 10000 -selectorName

dns_anyquery_amplification

add dns policy dns_amp_attack_pol "sys.check_limit(\"dns_ampl_attack_limitid\")"

dns_default_act_Drop

bind dns global dns_amp_attack_pol -priority 10add ns variable dns_tcp_requests -type ulong -scope transaction

Атака амплификации DNS на базе NXDOMAIN (NXDOMAIN-Based Amplification Attack).

Боты DNS могут внедрять вредоносные запросы к несуществующим доменным именам. Доменные имена для подобных атак, как правило, генерируются случайным образом. Создание ответа NXDOMAIN может быть более ресурсоемкой операцией, чем обслуживание настроенных записей для авторитетных серверов разрешения имен. Ответ NXDOMAIN в случае зон со включенным DNSSEC может быть еще более ресурсоемкой операцией.

Один популярный подход к устранению атак на базе NXDOMAIN – это определение шаблона домена и сброс подобных запросов, либо принудительное переключать клиента на TCP при помощи отправки усеченного ответа. Принудительное переключение на TCP является одним из способов проверки подлинности клиентов. Но вредоносные боты стали значительно сложнее и за счет полной поддержки стека TCP/IP, они могут повторно инициировать запрос по протоколу TCP. В идеале необходимо определить шаблон в доменных именах и настроить соответствующие политики для сброса запросов, соответствующих шаблону.

Citrix ADC может выступать в качестве авторитетного сервера имен для зон DNS и может устранить атаки амплификации на базе NXDOMAIN при помощи следующих опций настройки:

set dns parameter -NXDomainRateLimitThreshold ЗНАЧЕНИЕ

Если Citrix ADC настроен в качестве прокси, запросы с NXDOMAIN как правило не попадают в кэш. Фоновые серверы переполняются большим числом запросов, чем они могут обработать и в результате перестают обрабатывать корректные запросы. Когда Citrix ADC получает ответ NXDOMAIN, он кэшируется, в итоге выталкивая из кэша корректные записи.

Можно защитить кэш DNS против атак NXDOMAIN за счет выделения только малой части памяти для кэширования негативных записей и за счет установки TTL негативных записей в более низкое значение (рекомендуется использовать значение не более 1 или 2-ух минут). Пример конфигурации:

set dns parameter -maxNegativeCacheSize 200 -maxnegcacheTTL 120

Обратите внимание в примере выше, параметр maxNegativeCache задается в мегабайтах, а maxnegcacheTTL – в секундах.

Туннелирование DNS (DNS Tunneling).

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

Техники обнаружения туннелей DNS, такие как анализ полезной нагрузки и анализ траффика могут помочь при устранении данной угрозы. Анализ полезной нагрузки DNS исследует один или более запросов на предмет индикаторов туннеля. При помощи анализа траффика учитываются объем и шаблоны на протяжении отрезка времени. Число, частота и прочие атрибуты запросов могут также учитываться. При помощи богатой инфраструктуры политик DNS в Citrix ADC можно реализовать обнаружение на базе полезной нагрузки и трафика.

Если Citrix ADC находится перед фермой серверов LDNS, необходимо устранить возможность туннелирования DNS, чтобы ресурсы использовались только для разрешенных сценариев применения DNS. Решение, представленное ниже, основано на предположении, что длина доменных имен должна быть короче 200 байт и размер полезной нагрузки запросов DNS не должен превышать 256 байт.

add dns policy dns_tunnel_payload_1 "dns.req.question.domain.length.gt(200)" dns_default_act_Drop

add dns policy dns_tunnel_payload_2 "dns.length.gt(256)" dns_default_act_Drop

bind dns global dns_tunnel_payload_1 20 -gotoPriorityExpression next -type REQ_DEFAULT

bind dns global dns_tunnel_payload_2 30 -gotoPriorityExpression next -type REQ_DEFAULT

Атака TCP Slowloris.

Атакующий может отправить запрос DNS по частям и стек сервера будет ожидать завершения запроса в рамках определенного периода простоя. Однако атакующий может не послать все данные целиком или отправлять части с большим интервалом между ними. Это может привести к отказу в обслуживании корректных запросов (из-за потребления памяти на сервере имен для поддержки соединений TCP в рамках периода ожидания множества частей запросов). Следующая конфигурация Citrix ADC позволит устранить подобные атаки:

set dns parameter -splitPktQueryProcessing DROP

Заключение.

Для большинства хорошо изученных атак, доступны способы противодействия в параметрах DNS. В некоторых случаях можно использовать инфраструктуру политик Citrix ADC для инспекции запросов и ответов на предмет аномалий и применять подходящие действия для защиты ресурсов DNS и сетевой инфраструктуры в целом. Инфраструктура политик Citrix ADC – расширяемая платформа, которую сетевые и системные администраторы могут использовать для применения правил защиты от новейших угроз, обеспечивая немедленную защиту инфраструктуры DNS в безопасном, постоянно меняющемся окружении.

Узнать больше о политиках DNS, можно при помощи документации Citrix по темам политик ответчика (Responder Policy) для DNS и политик перезаписи (Rewrite Policy) для DNS.

Использование Citrix ADC для развертывания сетевого моста QUIC

Citrix ADC теперь поддерживает режим развертывания сетевого моста QUIC (прокси) для трафика HTTP/3, обеспечивая балансировку нагрузки, расширенную безопасность и более высокую производительность для трафика QUIC. Развертывание прокси предполагает, что Citrix ADC разрывает трафик клиента до сервера и повторно устанавливает новое соединение к серверу для получения запрашиваемой информации.

Citrix ADC обеспечивает постоянные соединения QUIC между клиентом и сервером, что полезно в случае миграции соединений или повторной привязки NAT. Новый зашифрованный транспортный протокол интернета QUIC ускоряет трафик протокола передачи гипертекста (HTTP) за счёт встроенной безопасности и, как ожидается, заменит TCP и TLS в сети. HTTP/3 – это новейшая версия HTTP, она определяет потоки данных между браузерами и веб-сайтами. Ранее я уже писал про преимущества протокола QUIC.

Отличия HTTP/3.

Многие годы протокол HTTP эволюционировал и во многом стал похож на связку протоколов TCP, TLS и HTTP/2, реализованных на базе транспортного протокола UDP. Однако с точки зрения установки соединения и передачи данных – это более эффективно. На диаграмме ниже показано сравнение стеков протокола HTTP/2 и HTTP/3. Типичное квитирование QUIC требует одного цикла обработки между сервером и клиентом по сравнению с двумя циклами для квитирования TCP и TLS. Другими словами, QUIC обрабатывает аутентификацию и шифрование за один шаг.

Отличительные особенности HTTP/3:

• Быстрое квитирование (Faster Handshake): HTTP/3 использует QUIC, объединенный с TLS 1.3, что ускоряет квитирование.
• Улучшенная производительность (Improved Performance): HTTP/3 не подвержен ошибками блокировки заголовка TCP, что является одной из самых больших проблем HTTP/2.
• Встроенная безопасность (Built-in Security): TLS 1.3 новее и более безопасен, чем TLS 1.2 в HTTP/2.
• Устойчивая миграция сети (Reliable Network Migration): HTTP/2 требует пересмотра сессии для браузеров, а с QUIC передача проще.

Сетевой мост QUIC и Citrix ADC.

Сетевой мост QUIC (QUIC Bridge) – это один из возможных сценариев применения HTTP/3 в Citrix ADC. В данном случае Citrix ADC выступает в качестве прокси и маршрутизирует, а также балансирует нагрузку пакетов данных QUIC от клиентов к фоновым серверам.

Рассмотрим пример, в котором клиент с включенной поддержкой HTTP/3 в браузере собирается посетить веб-сайт со своего ноутбука. Клиент вводит URL и имя хоста преобразуется в IP-адрес. В развертывании прокси квитирование происходит между клиентом и Citrix ADC, а другое соединение между Citrix ADC и сервером. Citrix ADC располагается между участниками и управляет трафиком. На диаграмме ниже показан Citrix ADC в режиме прокси.

Режим передачи сетевой мост QUIC (QUIC Bridge) в Citrix ADC:

1. Клиент подключается к URL через сеть Wi-Fi.
2. Сервер DNS разрешает имя хоста в IP-адрес.
3. Устанавливается соединение UDP.
4. Контроллер доставки приложений (ADC) маршрутизирует пакеты QUIC до сервера назначения на базе типа пакета.
5. Выполняется балансировка нагрузки (Load Balancing).
6. Клиент перемещается в мобильную сеть из сети Wi-Fi.
7. Устанавливается соединение UDP.
8. Контроллер доставки приложений (ADC) маршрутизирует пакеты QUIC до сервера назначения на базе типа пакета.
9. Удержание сессии (Session Persistency) гарантирует подключение к тому же серверу после миграции соединения.

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

Начать использовать HTTP/3.

Прокси QUIC в Citrix ADC можно использовать и для защиты приложений от уязвимостей. Большинство браузеров на сегодняшний день поддерживают HTTP/3 и Citrix ADC может помочь с балансировкой нагрузки трафика QUIC, вне зависимости от используемых браузеров и приложений.

Поддержка сетевого моста QUIC доступна в Citrix ADC с версии 13.0.76.x. Дополнительную информацию можно получить при помощи следующих ссылок: QUIC, Citrix Application Delivery Controller (ADC) и Citrix Application Delivery Management (ADM).

Стандартный коммутатор (vSS) в VMware vSphere 7

 

Давненько у нас не было веб-кастов про VMware vSphere 7, а тем временем пришло время обсудить устройство сети и стандартный коммутатор vSphere (vSphere Standard Switch).

В веб-касте представлено описание компонентов сети составляющих основу сетевого стека хостов ESXi, а все демонстрации веб-каста представлены в двух интерфейсах: веб-интерфейсе хоста ESXi и vSphere Client. В веб-касте вы найдете настройку существующего коммутатора (vSS) и создание нового стандартного коммутатора, в том числе демонстрируется настройка устойчивого соединения с внешней сетью при помощи группы входящих каналов (Uplink), создание групп портов (Port Group) и переключение ресурсов между стандартными коммутаторами. В результате демонстраций настраивается разделение трафика управления хостом ESXi с трафиком виртуальных машин.

Подробности и видео: LebedevUM.

P.S. Чуть позже я планирую вернуться к вопросу виртуальных сетей VMware vSphere.

Тонкости настройки syslog в Citrix ADC

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

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

Можно разделить требования к syslog Citrix ADC на две части: функциональные возможности Citrix ADC и операционная система Citrix ADC. Рассмотрим обе стороны этого вопроса.

Syslog для функциональных возможностей Citrix ADC.

Документация по syslog для Citrix ADC рекомендует использовать выражения продвинутых политик (Advanced Policy Expression) при настройке Citrix ADC, так как выражения классических политик (Classical Policy) устарели и не будут поддерживаться в будущих релизах.

Процесс настройки сообщений syslog для отправки на удаленный сервер в общем виде состоит из 3 шагов:

1. Создание сервера syslog для определения назначения и способа отправки сообщений.
2. Создание политик syslog для определения момента отправки сообщений.
3. Привязка политик syslog для определения сообщений, которые должны быть отправлены.

Если нет особых требований, то абсолютно нормально отправлять все уровни журнала, за исключением уровня отладки (Debug). Уровень отладки может быть включен, в крайнем случае, для устранения неисправностей. Необходимо осторожно подходить к уровню отладки (Debug), так как на этом уровне генерируется значительный объем данных, который быстро заполняет доступное хранилище.

Если существуют требования учёта срабатываний списков контроля доступа (ACL), ведение журнала ACL должно быть включено и для сервера syslog, куда будут отправляться журналы, а также отдельные правила ACL для записи в журнал.

Также не лишним будет включить отправку пользовательских сообщений syslog. В противном случае в журнале не отобразятся настраиваемые действия (Actions).

Пример команд для настройки отправки сообщений syslog для хранения на сервер syslog и Citrix Application Delivery Management (ADM):

add audit syslogAction retention-syslog-SRV -logLevel EMERGENCY ALERT CRITICAL ERROR WARNING NOTICE INFORMATIONAL -acl ENABLED -userDefinedAuditlog YES

add audit syslogAction CitrixADM-syslog-SRV -logLevel EMERGENCY ALERT CRITICAL ERROR WARNING NOTICE INFORMATIONAL -userDefinedAuditlog YES

add audit syslogPolicy retention-syslog-POL true retention-syslog-SRV

add audit syslogPolicy CitrixADM-syslog-POL true CitrixADM-syslog-SRV

bind audit syslogGlobal -policyName retention-syslog-POL -priority 100

bind audit syslogGlobal -policyName CitrixADM-syslog-POL -priority 110

Syslog для операционной системы Citrix ADC.

Довольно часто в развертываниях встречается отсутствующая конфигурация для отправки сообщений о происходящем в операционной системе на внешний сервер syslog. Все, что попадает в журнал, – это вход пользователя в систему и запуск команды shell, ничего более в журнал на сервере syslog не попадает. Это значит, что в случае сбоя и невозможности получить локальный журнал на Citrix ADC, узнать подробности происходившего не получится. Более того, при условии возможности интерактивного входа, передовой опыт не позволяет доверять целостности файлов локальных журналов.

Некоторые конфигурационные файлы, хранящихся в /etc, могут быть скопированы в /nsconfig, для большей устойчивости в процессе перезагрузки. /etc/syslog.conf – один из примеров таких файлов.

Выбор syslog local, зависит от конфигурации сервера syslog, на который будут отправляться сообщения. Для Citrix ADM можно использовать все доступные уровни local от 0 до 7. Звёздочка (*) после local7, определяет все сообщения для отправки на сервер syslog.

Также необходимо отредактировать /nsconfig/rc.netscaler для перезапуска демона syslog после загрузки, чтобы убедиться в использовании корректного конфигурационного файла. Если Citrix ADC сконфигурирован в высоко доступной паре, NSIP не может быть указан в явном виде, вместо этого, он может быть извлечен из файла na.conf, как показано в примере ниже.

Одна последняя вещь, которую нужно учесть – все команды, которые выполняются в оболочке, выполняются от имени пользователя root, который и будет указан в поле имени пользователя (username) в сообщениях syslog.

Для включения отправки сообщений syslog о событиях в операционной системе на внешний сервер выполните следующие действия:

1. Скопируйте /etc/syslog.conf в /nsconfig/syslog.conf.

2. Добавьте следующие строки в /nsconfig/syslog.conf.

local7.*                 @<IP-АДРЕС СЕРВЕРА SYSLOG>

local7.*                 @<IP-АДРЕС СЕРВЕРА SYSLOG>

3. Добавьте следующие строки в /nsconfig/rc.netscaler:

pkill syslogd

nsip=$(grep -i ‘set ns config -IPAddress’ /nsconfig/ns.conf | cut -d ‘ ’ -f 5)

/usr/sbin/syslogd -b $nsip -n -v -v -8 -C &

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

Надёжный внешний репозиторий для хранения журналов syslog – это критически важный аспект при устранении неисправностей, проведении расследований и прочих задачах. Надеюсь, информация из данного блога окажется для вас полезной и пригодится в дальнейшем. За основу данного материала я хотел бы поблагодарить Magnus Esse, а дополнительную информацию по ведению журнала событий аудита можно получить в документации.

Протокол gRPC доступен для развертываний Citrix ADC

В Citrix ADC протокол gRPC – это легковесная, высокопроизводительная платформа удаленного вызова процедур (RPC) с открытым исходным кодом. Платформа gRPC оптимальна для работы с разными языками, запущенными на любых операционных системах. Она обеспечивает лучшую безопасность и производительность по сравнению с другими протоколами.

За счёт использования gRPC поверх протокола HTTP/2 можно:

• Разрабатывать распределенные приложения для центров обработки данных и публичных/частных облачных инфраструктур.
• Предоставлять ускоренные клиент-серверные коммуникации для мобильных, веб или облачных приложений.
• Упрощать доступ к облачным сервисам и приложениям.
• Разворачивать микро-сервисы.

Почему gRPC в Citrix ADC.

Протокол gRPC в Citrix ADC применяется поверх HTTP/2 для поддержки высоко производительных и масштабируемых интерфейсов разработки приложений (API). За счет использования двоичных значений вместо текста, достигается увеличенная эффективность полезной нагрузки с точки зрения потребления памяти и хранения значений в числовых форматах.

В Citrix ADC запросы HTTP/2 мультиплексируются в одном подключении TCP, обеспечивая несколько конкурентных сообщений без ущерба для использования сетевых ресурсов. Также используется сжатие заголовков с целью сокращения размера запросов и ответов.

Принцип работы gRPC.

Конечная конфигурация gRPC работает как отправка запроса gRPC от клиента по протоколу HTTP/2 и отправка ответа обратно от сервера gRPC. На следующей диаграмме показана работа конфигурации gRPC на устройстве Citrix ADC.

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

1. Для развертывания конфигурации gRPC, необходимо сначала включить HTTP/2 в профиле HTTP и включить глобальную поддержку HTTP/2 на стороне сервера.
2. Когда клиент отправит запрос gRPC, виртуальный сервер балансировки нагрузки проверит трафик gRPC при помощи политик.
3. На базе проверки политик, виртуальный сервер балансировки нагрузки (с привязанными к нему сервисами gRPC) завершит обработку запроса и перешлет его фоновому серверу gRPC.
4. Аналогичным образом, когда сервер gRPC отвечает клиенту, Citrix ADC завершает обработку ответа и перенаправляет его клиенту gRPC.

Заключение.

Использование gRPC в развертывании Citrix ADC имеет преимущества над традиционными интерфейсами разработки приложений (API), так как работа происходит поверх протокола HTTP/2. Она поддерживает быстрые и эффективные коммуникации для развертываний микросервисов в облаках. Так как все большее число сервисов Citrix перемещается в облако, возможность обрабатывать вызовы gRPC при помощи Citrix ADC обеспечит требуемые производительность и безопасность вместе с простотой управления.

Дополнительную информацию о gRPC, его настройке и развертывании в качестве сервиса можно получить в разделе документации Citrix ADC, посвященном gRPC.

HTTP3, TLS 1.3 и Citrix ADC

Обсудим новинки интернет-безопасности, которые появились за последние несколько лет.

Новейшие браузеры теперь поддерживают HTTP3 (также известный как HTTP-over-QUIC). Раньше это был HTTP2, который являлся улучшенной версией HTTP1.1 за счёт возможностей мультиплексирования. Это увеличивало производительность, но могло привести к некоторым ошибкам блокировки Head-Of-Line (HOL).

Блокировка Head-Of-Line (HOL) – это проблема ограничения производительности, которая происходит при задержке первого пакета в линии. HTTP3 решил данную проблему, позволив остальным потокам пакетов передаваться без ошибок. На данный момент HTTP3 поддерживается всеми основными браузерами: Chrome, Firefox и Safari. 

В связи с непрерывным ростом использования интернета в последнее десятилетие, как никогда актуальна потребность в скорости, производительности и безопасности. HTTP3 вместе с TLS1.3 модернизирует интернет при помощи возможностей безопасности и производительности:

• HTTP3 исправляет ошибки блокировки заголовка линии (HOL), которым подвержен HTTP2.
• HTTP3 использует QUIC, при работе с TLS 1.3. Это минимизирует время на установку соединения, в то же время объединяет криптографическое и транспортное квитирование. QUIC – это транспортный протокол общего назначения, который улучшает производительность веб-приложений, ориентированных на подключение с использованием TCP.
• TLS 1.3 – это новый протокол шифрования, который улучшает безопасность и производительность (сокращая накладные расходы HTTPS) по сравнению с предыдущими версиями TLS.

На диаграмме ниже представлены различия между HTTP2 и HTTP3 с использованием QUIC (интегрированного с TLS 1.3):

Нужно отметить, что Citrix ADC – это первый контроллер доставки приложений (ADC) на рынке, который включил поддержку протокола TLS 1.3 практически сразу после его ратификации. К текущему моменту уже более 1000 клиентов Citrix используют программные возможности TLS 1.3. Аппаратное ускорение TLS 1.3 уже доступно с новейшими моделями Citrix ADC, а вслед за ним ожидается и поддержка HTTP3 с QUIC.

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

Ещё одна замечательная особенность – это возможности Citrix Application Delivery Management (ADM), позволяющие упростить управление Citrix ADC и предоставляющие подробности SSL (SSL Insights). Подробности SSL предоставляют прозрачность безопасности веб-транзакций (HTTPS), позволяя администраторам вести мониторинг всех защищаемых веб-приложений, обслуживаемых Citrix ADC и обеспечивая представления реального времени и исторические тренды безопасных транзакций. При помощи этой расширенной видимости администраторы могут получить следующие преимущества:

• Влияние изменений конфигурации на клиентов: администратор может понять влияние на клиентов перед внесением изменений в конфигурацию, такого как отключение SSLv3 или удаление шифра RC4-MD5. Это может быть выполнено при помощи оценки исторических данных транзакций с указанием протоколов и шифров.
• Качество производительности клиентов: администраторы могут понять влияние на время отклика приложения на базе использованных шифров/протоколов или передаваемых сертификатов.
• Безопасность приложения: администраторы могут оценивать транзакции приложений, запущенные с использованием слабозащищенных протоколов, шифров или слабых ключей.

Также решение на базе Citrix ADC под управлением ADM приобретает особое значение в условиях пандемии, когда многие администраторы работают удаленно и вынуждены подключаться из вне.

Миссия Citrix ADC заключается в непрерывной доставке инноваций и добавлении улучшений производительности и безопасности интернет протоколов.

При помощи следующих ссылок можно подробнее познакомиться с Citrix ADC и Citrix ADM.