Протокол Remote Desktop. Архитектура и возможности

Alexander Antipov

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

В следующих статьях будут подробно рассмотрены следующие вопросы:

• Работа подсистемы безопасности Remote Desktop
• Формат обмена служебной информацией в RDP
• Уязвимые места сервера терминалов и пути их устранения
• Подбор учетных записей пользователей по RDP протоколу (разработки компании Positive Technologies в данной области)

История появления RDP

Протокол Remote Desktop создан компанией Microsoft для обеспечения удаленного доступа к серверам и рабочим станциям Windows. Протокол RDP рассчитан на использование ресурсов высокопроизводительного сервера терминалов многими менее производительными рабочими станциями. Впервые сервер терминалов (версия 4.0) появился в 1998 году в составе Windows NT 4.0 Terminal Server, на момент написания статьи (январь 2009 года) последней версией терминального сервера является версия 6.1, включенная в дистрибутивы Windows 2008 Server и Windows Vista SP1. В настоящее время RDP является основным протоколом удаленного доступа для систем семейства Windows, а клиентские приложения существуют как для OC от Microsoft, так и для Linux, FreeBSD, MAC OS X и др.

Говоря об истории появления RDP, нельзя не упомянуть компанию Citrix. Citrix Systems в 1990-х годах специализировалась на многопользовательских системах и технологиях удаленного доступа. После приобретения лицензии на исходные коды Windows NT 3.51 в 1995 году эта компания выпустила многопользовательскую версию Windows NT, известную как WinFrame. В 1997 году Citrix Systems и Microsoft заключили договор, по которому многопользовательская среда Windows NT 4.0 базировалась на технологических разработках Citrix. В свою очередь Citrix Systems отказалась от распространения полноценной операционной системы и получала право на разработку и реализацию расширений для продуктов Microsoft. Данные расширения изначально назывались MetaFrame. Права на ICA (Independent Computing Architecture), прикладной протокол взаимодействия тонких клиентов с сервером приложений Citrix, остались за Citrix Systems, а протокол Microsoft RDP строился на базе ITU T.120.

В настоящее время основная конкурентная борьба между Citrix и Microsoft разгорелась в области серверов приложений для малого и среднего бизнеса. Традиционно решения на базе Terminal Services выигрывают в системах с не очень большим количеством однотипных серверов и схожих конфигураций, в то время как Citrix Systems прочно обосновалась на рынке сложных и высокопроизводительных систем. Конкуренция подогревается выпуском облегченных решений для небольших систем компанией Citrix и постоянным расширением функционала Terminal Services со стороны Microsoft.

Рассмотрим преимущества этих решений.

Сильные стороны Terminal Services:

• Простота установки приложений для клиентской части сервера приложений
• Централизованное обслуживание сессий пользователя
• Необходимость наличия лицензии только на Terminal Services

Сильные стороны решений Citrix:

• Простота масштабирования
• Удобство администрирования и мониторинга
• Политика разграничение доступа
• Поддержка корпоративных продуктов сторонних разработчиков (IBM WebSphere, BEA WebLogic)

Устройство сети, использующей Terminal Services

Microsoft предполагает два режима использования протокола RDP:

• для администрирования (Remote administration mode)
• для доступа к серверу приложений (Terminal Server mode)

RDP в режиме администрирования

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

RDP в режиме доступа к серверу терминалов

Данный режим доступен только в серверных версиях Windows. Количество удаленных подключений в данном случае не лимитируется, но требуется настройка сервера лицензий (License server) и его последующая активация. Сервер лицензий может быть установлен как на сервер терминалов, так и на отдельный сетевой узел. Возможность удаленного доступа к серверу терминалов открывается только после установки соответствующих лицензий на License server.

При использовании кластера терминальных серверов и балансировки нагрузки требуется установка специализированного сервера подключений (Session Directory Service). Данный сервер индексирует пользовательские сессии, что позволяет выполнять вход, а также повторный вход на терминальные серверы, работающие в распределенной среде.

Принцип работы RDP

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

RDP поддерживает несколько виртуальных каналов в рамках одного соединения, которые могут использоваться для обеспечения дополнительного функционала:

• использование принтера или последовательного порта
• перенаправление файловой системы
• поддержка работы с буфером обмена
• использование аудио- подсистемы

Характеристики виртуальных каналов согласуются на этапе установки соединения.

Обеспечение безопасности при использовании RDP

Спецификация протокола RDP предусматривает использование одного из двух подходов к обеспечению безопасности:

• Standard RDP Security (встроенная подсистема безопасности)
• Enhanced RDP Security (внешняя подсистема безопасности)

Standard RDP Security

При данном подходе аутентификация, шифрование и обеспечение целостности реализуется средствами, заложенными в RDP- протокол.

Аутентификация

Аутентификация сервера выполняется следующим образом:

1. При старте системы генерируется пара RSA- ключей
2. Создается сертификат (Proprietary Certificate) открытого ключа
3. Сертификат подписывается RSA- ключом, зашитым в операционную систему (любой RDP -клиент содержит открытый ключ данного встроенного RSA- ключа).
4. Клиент подключается к серверу терминалов и получает Proprietary Certificate
5. Клиент проверяет сертификат и получает открытый ключ сервера (данный ключ используется в дальнейшем для согласования параметров шифрования)

Аутентификация клиента проводится при вводе имени пользователя и пароля.

Шифрование

В качестве алгоритма шифрования выбран потоковый шифр RC4. В зависимости от версии операционной системы доступны различные длины ключа от 40 до 168 бит.

Максимальная длина ключа для операционных систем Winodws:

• Windows 2000 Server – 56 бит
• Windows XP, Windows 2003 Server – 128 бит
• Windows Vista, Windows 2008 Server – 168 бит

При установке соединения после согласования длины генерируется два различных ключа: для шифрования данных от клиента и от сервера.

Целостность

Целостность сообщения достигается применением алгоритма генерации MAC (Message Authentication Code) на базе алгоритмов MD5 и SHA1.

Начиная с Windows 2003 Server, для обеспечения совместимости с требованиями стандарта FIPS (Federal Information Processing Standard) 140-1 возможно использование алгоритма 3DES для шифрования сообщений и алгоритма генерации MAC, использующего только SHA1, для обеспечения целостности.

Enhanced RDP Security

В данном подходе используются внешние модули обеспечения безопасности:

• TLS 1.0
• CredSSP

Протокол TLS можно использовать, начиная с версии Windows 2003 Server, но только если его поддерживает RDP- клиент. Поддержка TLS добавлена, начиная с RDP -клиента версии 6.0.

При использовании TLS сертификат сервера можно генерировать средствами Terminal Sercives или выбирать существующий сертификат из хранилища Windows.

Протокол CredSSP представляет собой совмещение функционала TLS, Kerberos и NTLM.

Рассмотрим основные достоинства протокола CredSSP:

• Проверка разрешения на вход в удаленную систему до установки полноценного RDP- соединения, что позволяет экономить ресурсы сервера терминалов при большом количестве подключений
• Надежная аутентификация и шифрование по протоколу TLS
• Использование однократного входа в систему (Single Sign On) при помощи Kerberos или NTLM

Возможности CredSSP можно использовать только в операционных системах Windows Vista и Windows 2008 Server. Данный протокол включается флагом Use Network Level Authentication в настройках сервера терминалов (Windows 2008 Server) или в настройках удаленного доступа (Windows Vista).

Схема лицензирования Terminal Services

При использовании RDP для доступа к приложениям в режиме тонкого клиента требуется настройка специализированного сервера лицензий.

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

Виды клиентских лицензий:

• временная лицензия (Temporary Terminal Server CAL)
• лицензия «на устройство» (Device Terminal Server CAL)
• лицензия «на пользователя» (User Terminal Server CAL)
• лицензия для внешних пользователей (External Terminal Server Connector)

Временная лицензия

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

Лицензия «на устройство»

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

Лицензия «на пользователя»

Лицензирование «на пользователя» обеспечивает дополнительную гибкость, позволяя пользователям подключаться с различных устройств. В текущей реализации Terminal Services нет средств контроля использования пользовательские лицензий, т.е. количество доступных лицензий на сервере лицензий не уменьшается при подключении новых пользователей. Использование недостаточного количества лицензий для клиентских подключений нарушает лицензионное соглашение с компанией Microsoft. Чтобы одновременно использовать на одном сервере терминалов клиентские лицензии для устройств и для пользователей, сервер должен быть настроен для работы в режиме лицензирования «на пользователя».

Лицензия для внешних пользователей

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

Для сервера лицензий может быть установлена одна из двух ролей:

• Сервер лицензий для домена или рабочей группы (Domain or Workgroup License server)
• Сервер лицензий предприятия (Entire Enterprise License Server)

Роли отличаются способом обнаружения сервера лицензий: при использовании роли Enterprise терминальный сервер выполняет поиск сервера лицензии по каталогу ActiveDirectory, в противном случае поиск выполняется при помощи широковещательного NetBIOS- запроса. Каждый найденный сервер проверяется на корректность при помощи RPC -запроса.

Перспективные технологии Terminal Services

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

В Terminal Services для Windows 2008 Server введены следующие возможности.

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

Какие преимущества дает нам защита RDP при помощи SSL? Во первых надежное шифрование канала, проверку подлинности сервера на основании сертификата и проверку подлинности пользователя на уровне сети. Последняя возможность доступна начиная с Windows Server 2008. Проверка подлинности на уровне сети позволяет повысить безопасность сервера терминалов за счет проверки подлинности пользователя еще до начала сеанса.

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

Для полноценного использования всех возможностей RDP через SSL клиентские ПК должны работать под управлением Windows XP SP3, Windows Vista или Windows 7 и использовать RDP клиент версии 6.0 или более поздней.

При использовании Windows Server 2003 SP1 и более поздних версий, будут доступны шифрование канала при помощи SSL (TLS 1.0) и проверка подлинности сервера, клиентские ПК должны иметь версию RDP клиента 5.2 или более позднюю.

В нашей статье мы будем рассматривать настройку терминального сервера на базе Windows Server 2008 R2, однако все сказанное будет справедливо и для Windows Server 2003 (за исключением отсутствующих возможностей).

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

Затем следует выполнить запрос сертификата подлинности сервера со следующими параметрами:

Отправьте запрос центру сертификации и установите выданный сертификат. Данный сертификат должен быть установлен в локальное хранилище компьютера, иначе он не сможет быть использован службами терминалов. Чтобы проверить это запустим консоль MMC (Пуск - Выполнить - mmc ) и добавим оснастку Сертификаты (Файл - Добавить или удалить оснастку ) для учетной записи компьютера.

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

Если вы получали сертификат с помощью изолированного (автономного) ЦС (сеть не имеет доменной структуры) то он по умолчанию будет установлен в хранилище учетной записи пользователя и придется выполнить ряд дополнительных действий.

Откройте Internet Explorer - Свойства обозревателя - Содержимое - Сертификаты , выданный сертификат должен быть установлен в хранилище Личные .

Произведите его экспорт. При экспорте укажите следующие опции:

• Да, экспортировать закрытый ключ
• Удалить закрытый ключ после успешного экспорта

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

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

Теперь в Администрирование - Службы удаленных рабочих столов откройтеКонфигурация узла сеансов удаленных рабочих столов (в Windows Server 2003 Администрирование - Настройка служб терминалов).

И напоследок капля дегтя в бочке меда. Терминальные службы Windows не умеют проверять подлинность подключающихся клиентов, поэтому если стоит такая необходимость следует использовать дополнительные методы защиты, такие как SSH туннель или IPSec VPN.

Бытует мнение, что подключение по удаленному рабочему столу Windows (RDP) очень небезопасно в сравнении с аналогами (VNC, TeamViewer, пр). Как следствие, открывать доступ из вне к любому компьютеру или серверу локальной сети очень опрометчивое решение - обязательно взломают. Второй аргумент против RDP как правило звучит так - «жрет трафик, для медленного интернета не вариант». Чаще всего эти доводы ничем не аргументированы.

Протокол RDP существует не первый день, его дебют состоялся еще на Windows NT 4.0 более 20 лет назад и с тех пор утекло много воды. На данный момент RDP не менее безопасен, чем любое другое решение для удаленного доступа. Что касается требуемой полосы пропускания, так в этом плане есть куча настроек, с помощью которых можно добиться отличной отзывчивости и экономии полосы пропускания.

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

Сейчас расскажу как защитить RDP и настроить его на оптимальную производительность.

Во-первых, версий RDP протокола существует много. Все дальнейшее описание будет применимо к RDP 7.0 и выше. Это значит, что у вас как минимум Windows Vista SP1. Для любителей ретро есть специальный апдейт для Windows XP SP3 KB 969084 который добавляет RDP 7.0 в эту операционку.

Настройка №1 - шифрование

На компьютере, к которому вы собираетесь подключаться открываем gpedit.msc Идем в Конфигурация компьютера - Административные шаблоны - Компоненты Windows - Службы удаленных рабочих столов - Безопасность

Устанавливаем параметр «Требовать использования специального уровня безопасности для удаленных подключений по методу RDP» в значение «Включено» и Уровень безопасности в значение «SSL TLS 1.0»

Этой настройкой мы включили шифрование как таковое. Теперь нам нужно сделать так, чтобы применялись только стойкие алгоритмы шифрования, а не какой-нибудь DES 56-bit или RC2.

Поэтому в этой же ветке открываем параметр «Установить уровень шифрования для клиентских подключений». Включаем и выбираем «Высокий» уровень. Это нам даст 128-битное шифрование.

Но и это еще не предел. Самый максимальный уровень шифрования обеспечивается стандартом FIPS 140-1. При этом все RC2/RC4 автоматически идут лесом.

Чтобы включить использование FIPS 140-1, нужно в этой же оснастке пойти в Конфигурация компьютера - Конфигурация Windows - Параметры безопасности - Локальные политики - Параметры безопасности.

Ищем параметр «Системная криптография: использовать FIPS-совместимые алгоритмы для шифрования, хэширования и подписывания» и включаем его.

И в завершении в обязательном порядке включаем параметр «Требовать безопасное RPC-подключение» по пути Конфигурация компьютера - Административные шаблоны - Компоненты Windows - Службы удаленных рабочих столов - Безопасность.

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

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

Настройка №2 - смена порта

По умолчанию протокол RDP висит на порту TCP 3389. Для разнообразия его можно изменить, для этого в реестре нужно изменить ключик PortNumber по адресу

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Настройка №3 - сетевая аутентификация (NLA)

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

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

Настройка №4 - что еще проверить

Во-первых проверьте, что параметр «Учетные записи: разрешать использование пустых паролей только при консольном входе» включен. Параметр можно найти в Конфигурация компьютера - Административные шаблоны - Компоненты Windows - Службы удаленных рабочих столов - Безопасность.

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

Настройка №5 - оптимизация скорости

Идем в раздел Конфигурация компьютера - Административные шаблоны - Компоненты Windows - Службы удаленных рабочих столов - Среда удаленных сеансов.

Здесь можно и нужно отрегулировать несколько параметров:

• Наибольшая глубина цвета - можно ограничиться 16 битами. Это позволит сэкономить трафик больше чем в 2 раза по сравнению с 32х битной глубиной.
• Принудительная отмена фонового рисунка удаленного стола - для работы он не нужен.
• Задание алгоритма сжатия RDP - лучше установить значение Оптимизация использования полосы пропускания. В этом случае RDP будет жрать памяти чуть больше, но сжимать будет эффективнее.
• Оптимизировать визуальные эффекты для сеансов служб удаленных рабочих столов - ставим значение «Текст». Для работы то что нужно.

В остальном при подключении к удаленному компу со стороны клиента дополнительно можно отключить:

• Сглаживание шрифтов. Это сильно уменьшит время отклика. (Если у вас полноценный терминальный сервер, то этот параметр так же можно задать на стороне сервера)
• Композицию рабочего стола - отвечает за Aero и пр
• Отображение окна при перетаскивании
• Визуальные эффекты
• Стили оформления - если хочется хардкора

Остальные параметры типа фона рабочего стола, глубины цвета мы уже предопределили на стороне сервера.

Дополнительно на стороне клиента можно увеличить размер кэша изображений, делается это в реестре. По адресу HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\ нужно создать два ключа типа DWORD 32 BitmapPersistCacheSize и BitmapCacheSize

• BitmapPersistCacheSize можно установить равным 10000 (10 Мб) По умолчанию этот параметр берет значение 10, что соответствует 10 Кб.
• BitmapCacheSize так же можно установить равным 10000 (10 Мб). Вы вряд ли заметите, если RDP-подключение съест лишних 10 Мб от вашей оперативной памяти

Про проброс всяких принтеров и пр говорить ничего не буду. Кому что нужно, тот то и пробрасывает.

На этом основная часть настройки заканчивается. В следующих обзорах расскажу, как можно еще улучшить и обезопасить RDP. Используйте RDP правильно, всем стабильного коннекта! Как сделать RDP терминал сервер на любой версии Windows смотрите .

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

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

История появления

Протокол удаленного рабочего стола, а именно так расшифровывается аббревиатура RDP, появился в далеком 1998 году. Этот проприетарный протокол прикладного уровня, в то время входил в состав ОС Windows NT 4.0 Terminal Server, и позволял реализовать идею удаленного функционирования клиент-серверных приложений. Как вы понимаете, не всегда есть возможность обеспечить все рабочие места мощными компьютерами, а уж в те далекие годы производительность оставляла желать лучшего.

Решением этой проблемы выступает следующая конструкция: мощный сервер (или кластер серверов) осуществляет основную массу операций вычислений, а маломощные клиентские компьютеры/приложения подключаются к нему, используя протокол RDP, осуществляют свои задачи. Таким образом, на конечных пользовательских узлах появилась возможность работать со сложными приложениями и программами, даже при наличии ограниченных ресурсов — ведь основная нагрузка ложилась на сервер, а клиентский ПК получал только основной результат операции на мониторе.

Описание протокола RDP

• По умолчанию, для подключения используется порт TCP 3389
• Как уже упомянуто выше, при подключении предоставляется возможность работать с файлами на удаленном машине
• Для обеспечения безопасности реализовано шифрование и 56 и 128 битным ключами
• Также для функций безопасности, используется возможности протоколов TLS
• Общий буфер обмена — вы можете копировать данные и удаленной машины, и вставлять их на локальный ПК.
• Реализована возможность подключения локальных ресурсов к удаленному ПК.
• Протокол RDP предоставляет доступ к портам локального компьютера (последовательные и параллельные)

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

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

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

Аутентификация

Если настроена система обеспечения безопасности протокола RDP, аутентификация происходит следующим образом:

1. При инициализации подключения формируется пара RSA ключей
2. Далее создается специальный сертификат открытого ключа
3. Операционная система проводит процесс подписи сертификата RSA ключем
4. Далее клиент осуществляем подключение к серверу, получает от него сертификат, и если тот проходит проверку, инициализируется сессия удаленного управления

Как запустить

В операционных системах, таких как Windows XP, Vista, Seven, по умолчанию включено клиентское ПО Remote Desktop Connection. Для его запуска вам необходимо нажать сочетание клавиш Win+R , набрать mstsc и нажать Enter .

Служба удаленного рабочего стола (Remote Desktop Services - RDS) в Windows Server 2008 R2 имеет нечто большее, чем просто новое название; это вам не устаревшая служба терминалов. Благодаря новым компонентам (некоторые из них были представлены в Windows Server 2008), таким как RemoteApp, RD Gateway и RD Virtualization Host, эта роль сервера Windows теперь предоставляет вам гибкость в установке отдельных приложений или полных машин с помощью RDS или VDI решения – во многих случаях без необходимости в использовании Citrix или иных добавляемых модулей сторонних производителей.

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

Что нового в R2

Если вы приступаете к работе с RDS после работы со службами терминалов Windows Server 2008 Terminal Services, вы не встретите там много значительных изменений, как при переходе с Windows Server 2003. WS 2008 добавил некоторые значительные улучшения в службы терминалов, включая TS Web Access для подключения через браузер, TS Gateway для пользователей, подключающихся через интернет, RemoteApp для доставки отдельных приложений пользователям через Remote Desktop Protocol (RDP) протокол и Session Broker, который включает функцию балансировки нагрузки.

• Виртуализация удаленного рабочего стола (Remote Desktop Virtualization) для VDI решения
• RDS Provider для PowerShell, чтобы администраторы могли изменять конфигурацию и выполнять задачи в интерпретаторе команд и с помощью сценариев
• Виртуализация сетевого адреса (Remote Desktop IP Virtualization), которая позволяет присваивать IP адреса соединениям для каждого отдельного сеанса или программы
• Новая версия RDP и Remote Desktop Connection (RDC) клиента, версия 7.0
• Fair Share CPU планирование для динамического распределения времени обработки между сеансами на основе количества активных сеансов.
• Совместимость с Windows Installer для упрощения установки программ, требующих настройки под отдельных пользователей.
• Действительная поддержка нескольких мониторов (до 16 штук), благодаря которым программы работают так же, как они работают на клиентских машинах.

Также есть улучшения в аудио/видео и поддержке Windows Aero в RD сеансе (однако обратите внимание, что Desktop Composition, которая обеспечивает работу Aero, не поддерживается в сеансах с несколькими мониторами).

Аспекты и механизмы безопасности

Конечно потенциальные проблемы безопасности зависят от того, как устанавливать RDS. Если у вас более сложная конфигурация, в которой пользователи подключаются через интернет и/или браузер, у вас будет больше аспектов безопасности, которые нужно учитывать и прорабатывать, нежели при использовании простой конфигурации, в которой пользователи подключаются исключительно через RDC клиентов по LAN.

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

Проверка подлинности на сетевом уровне (Network Level Authentication)

Для максимального уровня безопасности следует требовать проверку подлинности на сетевом уровне (Network Level Authentication - NLA) для всех подключений. NLA требует, чтобы пользователи аутентифицировались на сервере RD Session Host, прежде чем сеанс будет создан. Это помогает защитить удаленные компьютеры от злоумышленных пользователей и вредоносного ПО. Чтобы использовать NLA, клиентский компьютер должен использовать операционную систему, которая поддерживает протоколы Credential Security Support Provider (CredSSP), то есть Windows XP SP3 и выше, а также иметь клиента RDC 6.0 или выше.

NLA настраивается на сервере RD Session Host в следующем разделе: Инструменты администрирования (Administrative Tools) | Службы удаленного рабочего стола (Remote Desktop Services) | Конфигурация узла сеансов удаленного рабочего стола (Desktop Session Host Configuration). Для настройки подключения на использование NLA, выполните следующие шаги:

1. Нажмите правой клавишей Подключение (Connection)
2. Выберите Свойства
3. Перейдите в закладку Общие (General)
4. Отметьте флажком опцию " Разрешать подключения только от компьютеров с удаленным рабочим столом с сетевой проверкой подлинности (Allow connections only from computers running Remote Desktop with Network Level Authentication)", как показано на рисунке 1
5. Нажмите OK.

Рисунок 1

Протокол Transport Layer Security (TLS)

Сеанс RDS может использовать один из трех уровней безопасности для защиты подключений между клиентами и сервером RDS Session Host:

• Уровень безопасности RDP " этот уровень использует собственное RDP шифрование и является наименее безопасным. Сервер RD Session Host не проходит проверку подлинности.
• Согласовать (Negotiate) " TLS 1.0 (SSL) шифрование будет использоваться, если клиент его поддерживает. Если нет, сеанс перейдет обратно на RDP безопасность.
• SSL " TLS 1.0 шифрование будет использоваться для проверки подлинности сервера и шифрования данных, передаваемых между клиентом и Session Host сервером. Это самая безопасная опция.

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

• Низкий (Low) " использует 56-разрядное шифрование для данных, пересылаемых с клиента на сервер. Не шифрует данные, пересылаемые с сервера клиенту.
• Совместимый с клиентом (Client Compatible) " это опция по умолчанию. Она шифрует данные передаваемые между клиентом и сервером с самым надежным ключом, который поддерживает клиент.
• Высокий (High) " эта опция шифрует данные в обоих направлениях между клиентом и сервером с помощью 128-битного шифрования.
• FIPS-совместимый (FIPS Compliant) " эта опция шифрует данные передаваемые в обоих направлениях между клиентом и сервером с помощью FIPS 140-1 утвержденного алгоритма шифрования.

Обратите внимание, что если выбрать опцию «Высокий» или «FIPS-совместимый», любые клиенты, не поддерживающие такие уровни шифрования, не смогут подключиться.

Вот, как настраивать параметры проверки подлинности и шифрования сервера:

1. На сервере RD Session Host откройте раздел конфигурации Remote Desktop Session Host Configuration, а затем свойства подключения, как говорилось выше.
2. В закладке Общие выберите соответствующий уровень безопасности и шифрования из раскрывающегося списка, как показано на рисунке 2.
3. Нажмите OK.

Рисунок 2

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

Групповая политика

Есть ряд параметров групповой политики для RDS в Windows Server 2008 R2. Они расположены в разделе Конфигурация компьютера (Computer Configuration)\ Политики (Policies)\ Административные шаблоны (Administrative Templates)\ Компоненты Windows (Windows Components)\ Службы удаленного рабочего стола (Remote Desktop Services) в консоли управления групповой политикой вашего домена, как показано на рисунке 3.

Как вы видите, здесь есть политики для лицензирования RDC клиентов и сервера RD Session Host. Политики для сервера RD Session Host, связанные с безопасностью, включают:

• Шаблон сертификата проверки подлинности сервера (Server Authentication Certificate Template): используйте эту политику, чтобы указать имя шаблона сертификата, которые определяет, какой сертификат будет автоматически выбираться для проверки подлинности сервера RD Session Host. Если включить эту политику, только сертификаты, создаваемые с помощью указанного шаблона, будут учитываться при выборе сертификата для проверки подлинности сервера RD Session Host.
• Задать уровень шифрования клиентских подключений (Set Client Connection Encryption Level): эта политика используется, чтобы контролировать то, будет ли требоваться определенный уровень шифрования. Когда вы включаете эту политику, все соединения должны использовать указанный уровень шифрования. Уровнем шифрования по умолчанию является Высокий уровень.
• Всегда запрашивать пароль при подключении (Always Prompt for Password upon Connection): можно использовать эту политику, чтобы заставить RDS всегда запрашивать пароль пользователя при входе в RD сеанс, даже если пароль введен на RDC клиенте. По умолчанию, пользователи могут входить автоматически, если пароль введен на клиенте RDC.
• Требовать защищенные RPC соединения (Require Secure RPC Communication): включение этой политики означает, что только зашифрованные и прошедшие проверку подлинности запросы с клиентов будут разрешены. Соединения с не доверенными клиентами не будут разрешены.
• Требовать использование определенного уровня безопасности для RDP подключений (Require Use of Specific Security Layer for Remote (RDP) Connections): если включить эту политику, все соединения между клиентами и серверами Session Host должны использовать уровень безопасности, который вы здесь укажете (RDP, Negotiate или SSL/TLS)
• Не разрешать локальным администраторам настраивать разрешения (Do Not Allow Local Administrators to Customize Permissions): эта политика отключает права администраторов на изменение разрешений безопасности в инструментах настройки RD Session Host Configuration, что не позволяет локальным администраторам изменять группы пользователей в закладке Разрешений (Permissions) в инструменте конфигурации.
• Требовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети (Require User Authentication for Remote Connections by using Network Level Authentication): с помощью этой политики вы можете требовать NLA для всех удаленных подключений к серверу RD Session Host. Только клиенты с поддержкой NLA смогут подключаться.

Примечание: вот, как узнать, поддерживает ли клиентский компьютер проверку подлинности на сетевом уровне: откройте RDC клиент и нажмите значок в верхнем левом углу, затем выберите "О программе (about) ". Если NLA поддерживается, вы увидите строку "Network Level Authentication Supported".

Другие параметры групповой политики, о которых следует упомянуть, расположены в разделе клиентских соединений RD Connection Client. Они включают:

• Не разрешать сохранение паролей (Do not allow passwords to be saved): включение этого параметра отключит опцию сохранения паролей в диалоге клиента RDC. Если пользователь откроет RDP файл и сохранит свои параметры, ранее сохраненные пароли будут удалены. Это заставляет пользователя вводить свой пароль при каждом входе.
• Указывать отпечатки SHA1 сертификатов, представляющих доверенных издателей RDP (Specify SHA1 thumbprints of certificates representing trusted .rdp publishers): с помощью этого параметра можно указать список отпечатков SHA1 сертификатов, и если сертификат соответствует отпечаткам в списке, он будет считаться доверенным.
• Запрашивать учетные данные на клиентском компьютере (Prompt for credentials on the client computer) : эта политика включает запрос учетных данных на клиентских компьютерах, а не на сервере RD Session Host.
• Настроить проверку подлинности сервера для клиента (Configure server authentication for client) : с помощью этого параметра можно указать, сможет ли клиент создать подключение к RD Session Host серверу, когда не может проверить подлинность сервера RD Session Host. Самым безопасным параметром будет опция "Не подключаться при неудачной аутентификации (Do not connect if authentication fails)."

Можно также использовать групповую политику для настройки FIPS соответствия, но эту политику здесь не найти с другими RDS политиками безопасности. Она расположена в следующем разделе: Конфигурация компьютера (Computer Configuration)\Настройки Windows (Windows Settings)\Настройки безопасности (Security Settings)\ Локальные политики (Local Policies)\Опции безопасности (Security Options). В правой панели пролистайте вниз к: Системная криптография: использовать FIPS-совместимые алгоритмы для шифрования, хеширования и подписывания ("System Cryptography: use FIPS compliant algorithms for encryption, hashing and signing"). При включении этой политики она поддерживает только Triple DES (3DES) алгоритм шифрования для RDS соединений.

RD Web Access

На компьютерах, где не установлен RDC клиент, пользователи могут получать доступ к опубликованным приложениям, к которым они имеют доступ из веб браузера. Пользователь переходит на URL адрес, по которому опубликованы RDS ресурсы. Сервер веб доступа RD Web Access Server является отдельным от RD Session Host сервером. Вы указываете, какие RD Web Access серверы могут подключаться к каким RD Session Host серверам.

Веб интерфейс настраивается с SSL и пользователь должен пройти проверку подлинности с помощью своих учетных данных. Прошедший проверку подлинности пользователь сможет увидеть лишь те RemoteApp программы, использование которых разрешено для его учетной записи, поскольку эти опубликованные программы «урезаются» с помощью списка управления доступом (ACL).

Сервер Web Access использует X.509 сертификат для обеспечения шифрования. По умолчанию используется саморегистрирующийся сертификат. Для большей безопасности следует получить сертификат в публичном центре сертификации или в PKI вашей компании.

RD Gateway

The RD Gateway (RDG) используется для предоставления пользователям доступа к RD ресурсам через интернет. Сервер шлюза Gateway расположен на границе, и он фильтрует входящие RDS запросы в соответствии с Network Policy Server (NPS). NPS использует две политики: Политика авторизации подключений (Connection Authorization Policy - CAP), в которой указывается, какие пользователи могут иметь доступ к RDG и Политика авторизации ресурсов (Resource Authorization Policy - RAP), указывающая, к каким устройствам CAP пользователь может подключаться через RDG.

Заключение

Службы удаленного рабочего стола в Windows Server 2008 R2 значительно расширяют функционал своего предшественника, службы терминалов " но они также представляют некоторые новые аспекты безопасности, которые следует учитывать. Следуя рекомендациям к обеспечению максимальной безопасности при настройке компонентов RDS конфигурации " RD Session Host, RD Web Access Server, RD Gateway и клиент " а также используя групповую политику для управления конфигурацией, вы сможете получить безопасную среду и воспользоваться преимуществами RDS доставки приложений и обеспечить своим пользователям ощущение работы на полноценных компьютерах.