RDS на основе сеансов в Windows Server 2012 R2. Часть 5 — Использование роли шлюза подключений (RD Gateway) — bearded sysadmin

Введение

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

Кроме того, ряд нормативных актов РФ в области информационной безопасности обязывает обеспечивать защищённый обмен сведениями определённого рода. В частности, если речь идёт о персональных данных, то основанный на одноимённом Федеральном законе №152-ФЗ приказ ФСТЭК России №21 обязывает охранять их от раскрытия, модификации и навязывания — ввода ложной информации — при передаче (или подготовке к передаче) по каналам связи, имеющим выход за пределы контролируемой зоны, в том числе — беспроводным.

Схожие требования прописаны и в приказе ФСТЭК России №17, который касается обеспечения безопасности данных, содержащихся в государственных информационных системах. Также о защите каналов связи и об организации защищённого удалённого доступа говорится в нормативных актах, регламентирующих оборону критической информационной инфраструктуры, в частности — в приказах ФСТЭК России №239 и №31.

Чаще всего для организации защищённого канала связи создают виртуальную частную сеть (VPN) с использованием криптоалгоритмов ГОСТ. Для этого применяются криптошлюзы и клиентское программное обеспечение. Законодателями мод в этой нише стали такие разработчики, как «ИнфоТеКС», «Код Безопасности» и «С-Терра».

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

В то же время решения на базе TLS-криптошлюзов позволяют создавать защищённые соединения и без VPN-клиентов, с использованием одного лишь браузера и установленных сертификатов. Это даёт возможность получать доступ к корпоративным ресурсам даже со смартфонов и планшетов. Реализация данного решения требует небольшого количества времени.

Ms remote desktop gateway, haproxy и перебор пароля

frontend fe_rdp_tsc
    bind *:443 ssl crt /etc/haproxy/cert/desktop.example.com.pem
    mode http
    ...
    default_backend be_rdp_tsc


backend be_rdp_tsc
    ...
    mode http
    ...

    #создать таблицу, строковую, 1000 элементов, протухает через 15 сек, записать кол-во ошибок за последние 10 сек
    stick-table type string len 128 size 1k expire 15s store http_err_rate(10s)
    #запомнить ip
    http-request track-sc0 src
    #запретить с http ошибкой 429, если за последние 10 сек больше 4 ошибок
    http-request deny deny_status 429 if { sc_http_err_rate(0) gt 4 }
	
	...
    server rdgw01 192.168.1.33:443 maxconn 1000 weight 10 ssl check cookie rdgw01
    server rdgw02 192.168.2.33:443 maxconn 1000 weight 10 ssl check cookie rdgw02

frontend fe_rdp_tsc
    bind *:443 ssl crt /etc/haproxy/cert/ertelecom_ru_2020_06_11.pem
    mode http
    ...
    #создать таблицу ip адресов, 1000 элементов, протухнет через 15 сек, сохрянять из глобального счётчика
    stick-table type ip size 1k expire 15s store gpc0
    #взять источник
    tcp-request connection track-sc0 src
    #отклонить tcp соединение, если глобальный счётчик >0
    tcp-request connection reject if { sc0_get_gpc0 gt 0 }
	
    ...
    default_backend be_rdp_tsc


backend be_rdp_tsc
    ...
    mode http
    ...
	
    #создать таблицу ip адресов, 1000 элементов, протухнет через 15 сек, сохранять кол-во ошибок за 10 сек
    stick-table type ip size 1k expire 15s store http_err_rate(10s)
    #много ошибок, если кол-во ошибок за 10 сек превысило 8
    acl errors_too_fast sc1_http_err_rate gt 8
    #пометить атаку в глобальном счётчике (увеличить счётчик)
    acl mark_as_abuser sc0_inc_gpc0(fe_rdp_tsc) gt 0
    #обнулить глобальный счётчик
    acl clear_as_abuser sc0_clr_gpc0(fe_rdp_tsc) ge 0
    #взять источник
    tcp-request content track-sc1 src
    #отклонить, пометить, что атака
    tcp-request content reject if errors_too_fast mark_as_abuser
    #разрешить, сбросить флажок атаки
    tcp-request content accept if !errors_too_fast clear_as_abuser
	
    ...
    server rdgw01 192.168.1.33:443 maxconn 1000 weight 10 ssl check cookie rdgw01
    server rdgw02 192.168.2.33:443 maxconn 1000 weight 10 ssl check cookie rdgw02

frontend fe_rdp_tsc
    ...
    stick-table type ip size 1k expire 15s store gpc0
    http-request track-sc0 src
    http-request deny deny_status 429 if { sc0_get_gpc0 gt 0 }
    ...
    default_backend be_rdp_tsc

backend be_rdp_tsc
    ...
    stick-table type ip size 1k expire 15s store http_err_rate(10s)
    acl errors_too_fast sc1_http_err_rate gt 8
    acl mark_as_abuser sc0_inc_gpc0(fe_rdp_tsc) gt 0
    acl clear_as_abuser sc0_clr_gpc0(fe_rdp_tsc) ge 0
    http-request track-sc1 src
    http-request allow if !errors_too_fast clear_as_abuser
    http-request deny deny_status 429 if errors_too_fast mark_as_abuser
    ...

Oracle api gateway

Сервис Oracle API Gateway стал доступен любому пользователю в конце 2021 года и уже пытается активно конкурировать с Amazon API Gateway. Получится ли у него отвоевать хотя бы часть аудитории у AWS, нам только предстоит увидеть… а сравнивать всегда интереснее на собственном опыте. Почитать про создание своего API Gateway можно вот в этой статье.

Особенности платформы:

• RESTful API в комбинации с Oracle Functions, а также возможностями Kubernetes и Compute.

• Каждая служба в облачной инфраструктуре Oracle интегрируется с IAM для аутентификации и авторизации (консоль, SDK или CLI и REST API).

• Интеграция с системой управления доступом Oracle Cloud Infrastructure.

• Бесплатный период длительностью в тридцать дней, чтобы опробовать возможности широкого спектра сервисов Oracle Cloud, в том числе к Databases, Analytics, Compute, Container Engine for Kubernetes и т. д.

• Платформа Oracle Cloud позиционирует себя как более экономичное решение, чем AWS, и в качестве примера упоминает, что соотношение цены и производительности в 2 раза выше, а стоимость исходящей пропускной способности составляет только 1/4 от стоимости у AWS.

Архитерктура tls-криптошлюза

Аутентификация пользователей

Возможности tls-клиента

Вопросы и ответы по продукту vipnet tls gateway

Дополнительные функции

Зачем вообще нужны api gateway

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

Представьте себе: у вас есть интернет-магазин по продаже реплик молота Тора. Для удобства пользователя имеется как сайт под десктоп и мобильные устройства, так и приложения для Android и iPhone, которые взаимодействуют с сервером через REST API.

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

API Gateway выполняет множество задач: принимает, обрабатывает и распределяет запросы, контролирует трафик, осуществляет мониторинг и контроль доступа. 

В микросервисной архитектуре паттерн API Gateway появился в качестве службы, обеспечивающей единую точку входа для веб-приложений и API, эдакой «серверной части для клиентской части». В чём польза именно для микросервисов? 

Например — возможность повторного использования компонентов, упрощение бэкенда приложения, обеспечение доступа к статическим веб-страницам и документам, удобная проверка авторизации и подбор оптимального для каждого типа клиента API — как это делает Netflix API Gateway.

Как используют облачные api gateway

Виртуальная доска

Простое приложение, состоящее из двух конечных точек — POST для записи сообщений и GET для извлечения трёх последних сообщений. Реализовано с помощью AWS Gateway, AWS DynamoDB, AWS Serverless Application Model и Lambda. 

Голосовой сервиc

Рецепт сервиса записи к врачу и регистрации в поликлинике, разработанный коммуникационной платформой Voximplant и Yandex.Cloud.

Бот для телеграма

Запуск бота на Python внутри одного из облачных сервисов, а именно — Yandex.Cloud.

Трекер пульсометрии

Один из вариантов решения для сбора данных пульсовой оксиметрии для нескольких пользователей, отслеживания этих данных и обмена ими. Фронт написан на VueJS, бэкенд реализован с применением Amazon API Gateway. 

Статический сайт в облаке

Пошаговая инструкция по деплою статического сайта в облако, прикрутке к нему сертификата Let’s Encrypt, домена второго уровня и настройке API-шлюза в системе Yandex.Cloud.

Блог

И снова приложение на микросервисах — реализация клиентской части на VueJS, взаимодействие настроено через REST API и gRPC, а в качестве базы данных используется MongoDB.

Как работает шлюз удалённых рабочих столов?

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

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

Нововведения в службе шлюза удалённых рабочих столов

Нововведений в службе RD Gateway по сравнению с предыдущей версией действительно много и вот самые значительные из них:

Что же нового приносят эти функции? Давайте разбираться.

Мониторинг и работа с журналами

Общие сведения

Отказоустойчивость и масштабирование

Подключение пользователей к ресурсам фермы rds с помощью шлюза

Все настройки клиента относительно использования шлюза выполняются в окне Подключения к удалённому рабочему столу (mstsc.exe). Для того, чтобы задать клиенту параметры подключения к шлюзу, необходимо на вкладке Дополнительно в разделе Подключение из любого места нажать кнопку Параметры.

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

На Windows RT и Windows 8/8.1 можно осуществлять подключение с помощью приложения Удалённый рабочий стол. Для того, чтобы указать сервер шлюза, через который будет установлено подключение, необходимо зайти в настройки приложения. Сделать это можно в окне приложения, нажав комбинацию клавиш Win I, или зайдя в пункт Параметры панели Charms.

В случае когда развернуты приложения RemoteApp и они подключены средствами Панели управления, приложений Удалённый рабочий стол или GPO, достаточно сперва выполнить обновление приложений (как описано в статье RDS на основе сеансов в Windows Server 2021 R2.

Предупреждение о самоподписанном сертификате rdp

По умолчанию в Windows для защиты RDP сессии генерируется самоподписанный

сертификат. В результате при первом подключении к RDP/RDS серверу через клиента mstsc.exe, у пользователя появляется предупреждение:

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

Чтобы продолжить установление RDP подключении пользователь должен нажать кнопку Да. Чтобы RDP предупреждение не появлялось каждый раз, можно включить опцию “Больше не выводить запрос о подключениях к этому компьютеру».

Работа с криптоключами

Режимы работы

Создаем шаблон rdp сертификата в центре сертификации (ca)

Попробуем использовать для защиты RDP подключений доверенный SSL/TLS сертификат, выданный корпоративным центром сертификации. С помощью такого сертификата пользователь может выполнить проверку подлинности RDP сервера при подключении. Предположим, что у вас в домене уже развернут корпоративной центр сертификации (Microsoft Certificate Authority), в этом случае вы можете настроить автоматическую выдачу и подключение сертификатов всем компьютерам и серверам Windows в домене.

Н на вашем CA нужно создать новый тип шаблона сертификата для RDP/RDS серверов.

1. Запустите консоль Certificate Authority и перейдите в секцию Certificate Templates;
2. Сделайте копию шаблона сертификата Computer (Certificate Templates -> Manage -> Computer -> Duplicate);
   
3. На вкладке General укажите имя нового шаблона сертификата – RDPTemplate. Убедитесь, что значение поля Template Name полностью совпадает с Template display name;
   
4. На вкладке Compatibility укажите минимальную версию клиентов в вашем домене (например, Windows Server 2008 R2 для CA и Windows 7 для клиентов). Тем самым будут использоваться более стойкие алгоритмы шифрования;
5. Теперь на вкладке Extensions в политике приложений (Application policy) нужно ограничить область использования такого сертификата только для Remote Desktop Authentication (укажите следующий object identifier — 1.3.6.1.4.1.311.54.1.2). Нажмите Add -> New, создайте новую политику и выберите ее;
   
6. В настройках шаблона сертификата (Application Policies Extension) удалите все политики кроме Remote Desktop Authentication;
7. Чтобы использовать данный шаблон RDP сертификатов на контролерах домена, откройте вкладку Security, добавьте группу Domain Controllers и включите для нее опцию Enroll и Autoenroll;
   
8. Сохраните шаблон сертификата;
9. Теперь в оснастке Certificate Authority, щёлкните по папке Certificate Templates, выберите New ->Certificate Template to Issue -> выберите созданный шаблон RDPTemplate.
   

Управление tls-криптошлюзом

Управление доступом удалённых пользователей

Установка instantssl сертификата: citrix secure gateway

Установка ssl-сертификата

Для шлюза удаленного рабочего стола должен быть установлен SSL-сертификат. Чтобы установить SSL-сертификат, щелкните имя сервера удаленного рабочего стола в консоли управления удаленным рабочим столом и выберите View or modify certificate properties.

Возможно 3 способа импорта сертификатов:

• создание самоподписанного сертификата и его импорт;
• импорт ранее загруженного сертификата (самоподписанного или стороннего);
• загрузка стороннего сертификата (например, Comodo) и его импорт;

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

Введите имя сертификата и его расположение на сервере. Нажмите OK.

Сертификат будет сгенерирован.

В результате отобразится – кому, кем и до какого числа выдан ssl-сертификат. Нажмите Apply для сохранения изменений.

Теперь самоподписанный SSL-сертификат успешно установлен на TCP-порт 443 (порт SSL по умолчанию).

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

Чтобы изменить номер порта для шлюза RD, щелкните правой кнопкой мыши имя сервера и выберите свойства в консоли управления удаленным рабочим столом (Action →Properties).

Установка службы rd gateway

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

Запустить установку роли RD Gateway можно зайдя в Службы удалённых рабочих столов и там либо нажать на ссылку Шлюз удалённых рабочих столов в панели Обзор развёртывания либо в выпадающем меню Задачи на панели Серверы развёртывания выбрать пункт Добавить серверы шлюзов удалённых рабочих столов.

Любое из описанных выше действий приведёт к вызову мастера установки роли шлюза удалённых рабочих столов. В первом окне выбираем сервер или несколько серверов на которые будет установлена роль RD Gateway.

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

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

После того, как сервер добавлен в развёртывание и на него установлены все необходимые службы, потребуется настроить сертификат подлинности. Сделать это можно прямо из окна развёртывания нажав на ссылку Настроить сертификат в уведомлении или позже зайдя в Свойства развёртывания (Диспетчер серверов > Службы удалённых рабочих столов > Общие сведения > Обзор развёртывания > Задачи).

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

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

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

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

Окно свойств шлюза RDS позволяет настроить самые основные параметры, а именно: выполнить ли конфигурацию RD Gateway в автоматическом режиме, задать настройки вручную либо вовсе не использовать службу шлюза удалённых рабочих столов. Если выбрана опция Использовать следующие параметры сервера шлюза удалённых рабочих столов, то нижеследующие параметры потребуется указать вручную:

• Имя сервера. Внешнее имя шлюза к которому обращаются пользователи.
• Метод входа. Доступны варианты для настройки проверки подлинности пользователя используя пароль или используя смарт-карту.
• Использовать ли учётные данные шлюза удалённых рабочих столов для удалённых компьютеров.
• Не использовать сервер шлюза удалённых рабочих столов для локальных подключений. Этот параметр позволяет снизить нагрузку на RD Gateway, т.к. для локальных клиентов соединение с фермой RDS устанавливается минуя шлюз.

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

Выводы

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

Также большим подспорьем для развития TLS-криптошлюзов станет наращивание защитной функциональности — например, добавление инструментов межсетевого экранирования, средств обнаружения вторжений, брандмауэров веб-приложений (Web Application Firewall) и других подобных модулей, — а также расширение возможностей интеграции с другими элементами системы информационной безопасности и IT-инфраструктуры.

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