Безпека служби Remote Desktop Services в Windows Server 2008 R2

Служба Remote Desktop Services (RDS) в Windows Server 2008 R2 це не просто ребрендинг свого попередника - служби Terminal Services. Нові функції, частина з яких з'явилася ще в Windows Server 2008, такі як RemoteApp, RD Gateway і RD Virtualization Host, дозволяють просто і зручно забезпечити розгортання і функціонування як окремих користувальницьких додатків, так і цілі робочих столів в RDS і VDI рішеннях, причому функціонал і зручність анітрохи не гірше, ніж у рішень Citrix або комплексів інших вендорів.

А як же йдуть справи з безпекою служби Remote Desktop Services? Microsoft істотно оновила і посилила безпеку даної служби. У даній статті ми поговоримо про механізми безпеки RDS, про забезпечення безпеки термінальних служб засобами групових політик і про практичні аспекти забезпечення безпеки рішень RDS.

Що нового в R2

Якщо вам доводилося працювати з версіями служб терміналів в Windows Server 2003 і Windows Server 2008, то ви, мабуть, пам'ятаєте, що в Windows 2008 з'явився ряд нових можливостей, таких як TS Web Access (підключення через браузер), TS Gateway (доступ до термінальних службам через Інтернет), RemoteApp (публікація окремих додатків по протоколу RDP) і служба Session Broker (забезпечення балансування навантаження).

У Windows Server 2008 R2 з'явився наступні функції:

  • Remote Desktop Virtualization для рішень VDI
  • Провайдер RDS для PowerShell (тепер адміністратор може управляти конфігурацією і управлінням RDS з командного рядка або за допомогою скриптів)
  • Remote Desktop IP Virtualization, що дозволяє призначати підключень IP адреси, грунтуючись на параметрах сесії або програми яку ви запускаєте
  • Нова версія протоколу RDP і клієнта Remote Desktop Connection (RDC) - v. 7.0
  • Управління ресурсами CPU для динамічного виділення процесорних ресурсів на основі кількості активних сесій
  • Сумісність з Windows Installer, що дозволяє встановлювати програми з можливістю донастройки установки програми на стороні користувача.
  • Підтримка на стороні клієнта до 16 моніторів.

Крім того, були доопрацьовані функції роботи з відео і аудіо, і повноцінна підтримка технології Windows Aero (відзначимо, що Aero не підтримує при мультимоніторних режимі роботи).

Природно, питання безпеки служби RDS залежать від конкретного рішення. Наприклад, якщо публікувати робочий стіл для користувачів, що підключаються через Інтернет або за допомогою браузера, то питання безпеки постає набагато гостріше, ніж при стандартному рішенні, коли клієнти підключаються за допомогою клієнта RDC по локальній мережі LAN.

Network Level Authentication

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

Налаштувати NLA можна на сервері RD Session, відкривши консоль Administrative Tools -> Remote Desktop Services -> Desktop Session Host Configuration.

  1. Клацніть правою кнопкою миші по підключенню
  2. Виберіть Properties
  3. Перейдіть на вкладку General
  4. Відзначте опцію "Allow connections only from computers running Remote Desktop with Network Level Authentication"
  5. натисніть OK.

Transport Layer Security (TLS)

У сесії RDS можна задіяти один з трьох механізмів безпеки, що дозволяють захистити з'єднання між клієнтів і сервером RDS Session Host:

  • RDP security layer - використовується вбудоване шифрування протоколу RDP, є менш безпечним.
  • Negotiate - шифрування TLS 1.0 (SSL) буде використовуватися в разі підтримки клієнтом, якщо клієнт його не підтримує, буде використовуватися звичайний рівень безпеки RDP.
  • SSL - шифрування TLS 1.будет використовуватися для аутентифікації сервера і шифрування даних, що передаються між клієнтом і сервером. Це найбільш безпечний режим.

Для забезпечення високого рівня безпеки необхідно використовувати шифрування SSL / TLS. Для цих цілей необхідно мати цифровий сертифікат, він може бути самоподпісанного або виданими центром сертифікації CA (що краще).

У доповненні до рівня безпеки можна вибрати рівень шифрування з'єднання. Доступні наступні види шифрування:

  • Low - використовується 56 бітове шифрування даних, що відправляються з клієнта на сервер. Дані, що передаються з сервера на клієнт не зашифровано.
  • Client Compatible - даний вид шифрування використовується за умовчанням. В цьому випадку шифрується весь трафік між клієнтом і сервером з максимальною довжиною ключа, яку підтримує клієнт.
  • High - всі дані передаються між клієнтом і сервером в обидві сторони шифруються 128 бітовим ключем
  • FIPS Compliant - всі дані передаються між клієнтом і сервером в обидві сторони шифруються методом FIPS 140-1.

Варто відзначити, що якщо використовуються рівні шифрування High або FIPS Compliant, то всі клієнти, які не підтримують даний вид шифрування, не зможуть підключитися до сервера.

Налаштувати тип аутентифікації сервера і рівень шифрування можна наступним чином:

  1. На сервері RD Session Host, відкрийте вікно конфігурації Remote Desktop Session Host і перейдіть у вікно властивостей.
  2. На вкладці General, у випадних меню, виберіть потрібний рівень безпеки і тип шифрування.
  3. натисніть OK.

групові політики

Для налаштування параметрів RDS в Windows Server 2008 R2 є ряд опцій групової політики. Всі вони розташовані в розділі Computer Configuration \ Policies \ Administrative Templates \ Windows Components \ Remote Desktop Services (скріншот консолі Group Policy Management Console відображений на картинці).

Як ви бачите тут є політики управління ліцензуванням, політики настройки клієнта RDC і самого сервера RD Session Host. До політикам безпеки RD Session Host відносяться:

  • Set Client Connection Encryption Level: політика використовується для управління рівнем шифрування. Якщо її активувати, всі з'єднання повинні використовувати вказаний рівень шифрування (за замовчуванням - High).
  • AlwaysPromptforPassworduponConnection: дана політика використовується, якщо необхідно завжди питати пароль користувача при підключенні до сесії RD, навіть якщо пароль був введений в клієнті RDC. За замовчуванням, користувачі можуть автоматично входити в сесію, якщо вони вказали пароль в клієнті RDC.
  • RequireSecureRPCCommunication: - при включеній політики дозволені тільки аутентифіковані і шифровані запити від клієнтів.
  • RequireUseofSpecificSecurityLayerforRemote (RDP) Connections: при включеній політиці, всі з'єднання між клієнтом і сервером терміналів повинні використовувати рівень, який зображено тут (RDP, Negotiate або SSL / TLS)
  • DoNotAllowLocalAdministratorstoCustomizePermissions: політика відключає можливість адміністраторам налаштовувати параметри безпеки RD Session Host.
  • Require User Authentication for Remote Connections by using Network Level Authentication: Політика включає вимогу NLA для всіх з'єднання з термінальним сервером (клієнти без підтримки NLA підключитися не зможуть).

Параметри настройки клієнта RDC знаходяться в підрозділі Remote Desktop Connection Client:

  • Donotallowpasswordstobesaved: політика забороняє зберігати паролі в клієнті RDC, опція "Зберегти пароль" стає недоступна, все раніше збережені паролі будуть видалені.
  • SpecifySHA1 thumbprintsofcertificatesrepresentingtrusted.rdppublishers: ця політика дозволяє створити список відбитків SHA1 сертифікатів, і якщо сертифікат відповідає відбитку в це списку, він вважається довіреною.
  • Promptforcredentialsontheclientcomputer: Політика активує запит облікових даних користувача на клієнтському комп'ютері, а не сервері RD Session.

RD Web Access

Користувачі комп'ютерів, на яких не встановлений клієнт RDC, можуть отримувати доступ до опублікованих додатків за допомогою веб-браузера. Для цього користувач повинен в браузері відкрити URL, на якому опубліковані ресурси RDS. Сервер RD Web Access - це окрема роль сервера RD, зазвичай він розташовується на виділеному сервері.

Веб інтерфейс сервера RD Web Access заснований на використанні SSL і користувачі можуть авторизуватися на ньому за допомогою своїх облікових даних. Аутентифіковані користувачі бачать лише список тих опублікованих програм (RemoteApp), до яких у них є доступ.

Сервер Web Access для шифрування використовує сертифікат X.509. За замовчуванням використовується самоподпісанний сертифікат.

Категорія