Напевно, багато хто з вас уже чув і бачив цю абревіатуру - дослівно перекладається вона, як Протокол віддаленого робочого столу (RemoteDesktopProtocol). Якщо когось цікавлять технічні тонкощі роботи цього протоколу прикладного рівня - можуть почитати літературу, починаючи з тієї самої вікіпедії. Ми ж розглянемо суто практичні аспекти. А саме той, що цей протокол дозволяє дистанційно підключатися до комп'ютерів, під керуванням Windows різних версій з використанням вбудованого в Windows інструменту «Підключення до віддаленого робочого столу».
Які плюси та мінуси у використанні протоколу RDP?
Почнемо з приємного – з плюсів. Плюс полягає в тому, що цей інструмент, який правильніше називати КлієнтомRDP, доступний будь-якому користувачеві Windows як на комп'ютері, з якого належить керувати віддаленим, так і тому, хто хоче відкрити доступ до свого комп'ютера.
Через підключення до віддаленого робочого столу можливо не тільки бачити віддалений робочий стіл та користуватися ресурсами віддаленого комп'ютера, а також підключати до нього локальні диски, принтери, смарткарти тощо. Звичайно, якщо ви захочете подивитися відео або послухати музику через RDP - навряд чи цей процес принесе вам задоволення, т.к. в більшості випадків ви побачите слайд шоу, і звук швидше за все буде перериватися. Але не під ці завдання розроблялася служба RDP.
Ще одним безперечним плюсом є те, що підключення до комп'ютера здійснюється без будь-яких додаткових програм, які в більшості своїй платні, хоча і мають свої переваги. Час доступу до RDP-сервера (яким є ваш віддалений комп'ютер) обмежується лише вашим бажанням.
Мінусів лише два. Один суттєвий, інший – не дуже. Перший і суттєвий - для роботи з RDP комп'ютер, до якого здійснюється підключення, повинен мати білий (зовнішній) IP, або на цей комп'ютер повинна бути можливість "прокинути" порт з маршрутизатора, який знову ж таки повинен мати зовнішній IP. Статичним він буде чи динамічним – значення не має, але він має бути.
Другий мінус – не такий суттєвий – останні версії клієнта перестали підтримувати 16-колірну колірну схему. Мінімум – 15біт. Це сильно уповільнює роботу по RDP, коли ви підключаєтеся по хирлявому-дохлому інтернету зі швидкістю, що не перевищує 64 кілобіти в секунду.
Для чого можна використовувати віддалений доступ по RDP?
Організації зазвичай використовують RDP-сервера для спільної роботи в програмі 1С. А деякі навіть розвертають на них робочі місця користувачів. Таким чином, користувач, особливо, якщо у нього роз'їзна робота, може за наявності 3G інтернету або готельного/кафешного Wi-Fi - підключатися до свого робочого місця і вирішувати всі питання.
У деяких випадках домашні користувачі можуть використовувати віддалений доступ до свого домашнього комп'ютера, щоб отримати дані з домашніх ресурсів. В принципі, служба віддаленого робочого столу дозволяє повноцінно працювати з текстовими, інженерними та графічними програмами. З обробкою відео та звуку з вищенаведених причин – працювати не вийде, але все одно – це дуже суттєвий плюс. А ще можна на роботі переглядати закриті політикою компанії ресурси, підключившись до домашнього комп'ютера без будь-яких анонімайзерів, vpn та іншої нечисті.
Готуємо інтернет
У попередньому розділі ми говорили про те, що для забезпечення можливості віддаленого доступу за протоколом RDP нам потрібна зовнішня IP-адреса. Цей сервіс може забезпечити провайдер, тому телефонуємо або пишемо, або заходимо в особистий кабінет та організовуємо надання цієї адреси. В ідеалі він має бути статичний, але і з динамічним, у принципі, можна жити.
Якщо комусь не зрозуміла термінологія, то статична адреса - це незмінний, а динамічний - іноді змінюється. Для того, щоб повноцінно працювати з динамічними IP-адресами, придумали різні сервіси, які забезпечують прив'язку динамічного домену. Що і як, незабаром буде стаття на цю тему.
Готуємо роутер
Якщо ваш комп'ютер підключений не безпосередньо до провайдерського проводу до інтернету, а через роутер - з цим пристроєм нам доведеться також зробити деякі маніпуляції. А саме - прокинути порт сервісу - 3389. В іншому випадку NAT вашого роутера просто не пускатиме вас всередину домашньої мережі. Теж відноситься до налаштування RDP-сервера в організації. Якщо ви не знаєте, як прокинути порт - читайте статтю про те, як прокинути порти на маршрутизаторі (відкриється в новій вкладці), потім повертайтеся сюди.
Готуємо комп'ютер
Для того, щоб створити можливість віддаленого підключення до комп'ютера, необхідно зробити дві речі:
Дозволити підключення до Властивостей Системи;
- встановити пароль для поточного користувача (якщо він не має пароля), або створити нового користувача з паролем спеціально для підключення по RDP.
Як чинити з користувачем - вирішуйте самі. Однак, майте на увазі, що штатно не серверні операційні системи не підтримують множинний вхід. Тобто. якщо ви залогінилися під собою локально (консольно), а потім зайдете під тим самим користувачем віддалено - локальний екран заблокується і сеанс на тому самому місці відкриється у вікні Підключення до віддаленого робочого столу. Введіть пароль локально, не вийшовши з RDP - викинете вас з віддаленого доступу, і ви побачите поточний екран на своєму локальному моніторі. Те саме чекає, якщо ви зайдете консольно під одним користувачем, а віддалено спробуєте зайти під іншим. І тут система запропонує завершити сеанс локального користувача, що може бути зручно.
Отже, заходимо до Пуск, клацаємо правою кнопкою по меню Комп'ютерта натискаємо Властивості.
У властивостях Системиобираємо Додаткові параметри системи
У вікні, що відкрилося, переходимо на вкладку Віддалений доступ…
…натискаємо Додатково…
І ставимо єдину галку на цій сторінці.
Це «домашня» версія Windows 7 - у кого Pro і вище, буде більше прапорців і можна зробити розмежування доступу.
Натискаємо ОКскрізь.
Тепер, ви можете зайти в Підключення до віддаленого робочого столу (Пуск>Всі програми>Стандартні), вбити туди IP-адресу комп'ютера, або ім'я, якщо хочете підключитися до нього зі своєї домашньої мережі та користуватися всіма ресурсами.
Ось так. В принципі все просто. Якщо раптом будуть якісь питання чи щось залишиться незрозумілим – ласкаво просимо у коментарі.
Досить часто у багатьох користувачів, які використовують сеанси віддаленого доступу, виникає питання, як змінити порт RDP. Зараз подивимося на найпростіші рішення, а також зазначимо кілька основних етапів у процесі налаштування.
Навіщо потрібен протокол RDP?
Для початку кілька слів про RDP. Якщо подивитися на розшифровку абревіатури, можна зрозуміти, що віддалений доступ
Говорячи простою мовою, це засіб термінального сервера або робочої станції. Установки Windows (причому будь-яка з версій системи) використовують стандартні параметри, які підходять більшості користувачів. Тим не менше іноді виникає необхідність їх зміни.
Стандартний порт RDP: чи потрібно його міняти?
Отже, незалежно від модифікації Windows, всі протоколи мають встановлене значення. Це порт RDP 3389, який використовується для здійснення сеансу зв'язку (підключення одного терміналу до віддалених).
З чим пов'язана ситуація, коли стандартне значення треба поміняти? Насамперед лише із забезпеченням безпеки локального комп'ютера. Адже якщо розібратися, за встановленого стандартного порту, в принципі, будь-який зловмисник може запросто проникнути в систему. Отже, зараз подивимося, як змінити порт RDP, встановлений за замовчуванням.
Зміна налаштувань у системному реєстрі
Відразу зазначимо, що процедура зміни проводиться виключно в ручному режимі, причому в самому клієнті віддаленого доступу будь-яке скидання або встановлення нових параметрів не передбачено.
Для початку викликаємо стандартний редактор реєстру командою regedit у меню "Виконати" (Win + R). Тут нас цікавить гілка HKLM, де по дереву розділів потрібно спуститися через директорію термінального сервера до каталогу RDP-Tcp. У вікні праворуч знаходимо ключ PortNumber. Його значення нам і треба поміняти.
Заходимо у редагування та бачимо там 00000D3D. Багато хто відразу дивується з приводу того, що це таке. А це просто шістнадцяткове уявлення десяткового числа 3389. Щоб вказати порт саме у десятковому вигляді, використовуємо відповідний рядок відображення уявлення значення, а потім вказуємо потрібний нам параметр.
Після цього перевантажуємо систему, а під час спроби підключення вказуємо новий порт RDP. Ще одним способом підключення є використання спеціальної команди mstsc /v:ip_address:XXXXX, де XXXXX - новий номер порту. Але це ще не все.
Правила для файрволу Windows
На жаль, але вбудований брандмауер Windows може блокувати новий порт. Отже, необхідно внести зміни до налаштувань самого фаєрволу.
Викликаємо налаштування фаєрволу з розширеними параметрами безпеки. Тут слід спочатку вибрати вхідні підключення та клацнути на рядку створення нового правила. Тепер вибираємо пункт створення правила для порту, потім вводимо його значення для TCP, далі дозволяємо підключення, розділ профілів залишаємо без змін і нарешті присвоюємо нове правило назву, після чого тиснемо кнопку завершення налаштування. Залишається перевантажити сервер і при підключенні вказати новий порт RDP через двокрапку у відповідному рядку. За ідеєю проблем спостерігатися не повинно.
Перекидання порту RDP на роутері
У деяких випадках, коли використовується бездротове з'єднання, а не кабельне, може знадобитися прокидати порт на маршрутизаторі (роутері). Нічого складного у цьому немає.
Спочатку у властивостях системи дозволяємо та вказуємо користувачів, які мають на це право. Потім заходимо в меню налаштувань роутера через браузер (192.168.1.1 або наприкінці 0.1 – все залежить від моделі роутера). У полі (якщо основна адреса у нас 1.1) бажано вказати адресу, починаючи з третьої (1.3), а правило видачі адреси прописати для другої (1.2).
Потім у мережевих підключеннях використовуємо перегляд деталей, де слід переглянути деталі, скопіювати звідти фізичну MAC-адресу та вставити її у параметри роутера.
Тепер у розділі налаштувань NAT на модемі включаємо підключення до сервера, додаємо правило і вказуємо порт XXXXX, який потрібно прокинути на стандартний порт RDP 3389. Зберігаємо зміни та перевантажуємо роутер (без перезавантаження новий порт сприйнятий не буде). Перевірити підключення можна на якомусь спеціалізованому сайті на кшталт ping.eu у розділі тестування портів. Як бачимо все просто.
Насамкінець зверніть увагу, що значення портів розподіляються таким чином:
- 0 – 1023 – порти для низькорівневих системних програм;
- 1024 – 49151 – порти, що виділяються для приватних цілей;
- 49152 – 65535 – динамічні приватні порти.
Взагалі, багато користувачів, щоб уникнути проблем зазвичай вибирають порти RDP з третього діапазону списку. Втім, і фахівці, і експерти рекомендують використовувати у налаштуванні саме ці значення, оскільки вони підходять для більшості завдань.
Що ж до саме така процедура використовується в основному лише у випадках Wi-Fi-з'єднання. Як вже можна було помітити, при звичайному дротовому підключенні вона не потрібна: достатньо змінити значення ключів реєстру та додати правила для порту у файрволлі.
RDP - Remote Desktop Protocol (Віддалений Робочий Стіл)
У першу чергу, тут йтиметься про StandAlone Server. Тобто, про окремо — сервер, що стоїть. А не про контролерів домену та корпоративні мережі. (там потрібні висококваліфіковані фахівці)
Ситуація, коли тобі на думку спала якась ідея і ти вирішив її втілити в життя. І для її реалізації тобі потрібна наявність Сервера, який ти орендуєш у певному дата-центрі.
Вибрав потрібний тариф, заплатив гроші і ось у тебе вже є Сервер, на якому встановлено необхідне тобі програмне забезпечення. У більшості випадків для таких пробних проектів достатньо Windows 2003 Server. Цілком бюджетно та ефективно.
Техпідтримка тобі видасть IP адресу, Логін та Пароль для RDP доступу, і ти починаєш свою подорож, повну…, ну взагалі – мало не здасться.
За замовчуванням, можна сказати, що цей сервіс у Windows налаштований так, щоб завдати користувачеві чимало клопоту та проблем.
Хоча, звичайно, він сам по собі працює і чудово виконує свою функцію. Але з часом, (іноді, це може виявитися занадто пізно) безтурботний власник віддаленого сервера жахнеться усвідомивши, що реально діється з його системою і який натовп спраглих крові стоїть навколо стін його фортеці.
Це як відключити інфрачервоний фільтр у відеореєстратора і раптом почати, бачити джерела відеозйомки - камери ДІБДР з фотофіксацією, і сигнали пультів дистанційного керування телевізором.
Ти починаєш бачити і потім, можливо, розуміти.
З одного боку, розробники програмного забезпечення вдають, що вони роблять свої системи для звичайної людини, і ти починаєш цьому вірити.
Але з іншого боку — ці ж розробники припускають, що клавіатуру може взяти лише сертифікований фахівець. І щоб сертифікат був цього року.
Такий парадокс.
Давай я розповім тобі, як все виглядає насправді.
А насправді, орди кулхацкерів прочитавши дюжину рядків на форумах завантажують готові списки серверів, у яких відкритий RDP порт. І починають ломитися на твою машину. Хто вручну (але це рідко), а в основному різними програмами, запускаючи словники по перебору: логін - пароль. І ніхто їх ні в чому не обмежує. Їм там навіть тісно часом.
Причому, я дивлюся на логи, і бачу, що здебільшого, це одні й ті ж словники.
А твій сервер змушений відбиватися. А ти – не в курсі. І не розумієш, чому маєш низьку продуктивність, чому довго виконуються запити.
Ти ж про велике думаєш. Стратегічно, про функціонал. А тут — якісь гальма не зрозумілі.
Тому ти почнеш оптимізувати пам'ять, видаляти тимчасові змінні, дефрагментувати диски тощо.
І, можливо, навіть уважно подивишся на вкладку «Події» в оснастці управління.
Але запевняю тебе, що ти там не побачиш причини! Тому що там не відображаються спроби неправильного введення логіну та пароля. Можливо, ти навіть сперечатимешся з іншими людьми, що тебе ось не ламають, бо бояться чи поважають.
Ні. Запевняю тебе, просто розробники вони такі веселі хлопці. І спочатку трохи переважують чашу терезів у бік пітьми. Вони кажуть, що якби ці події відображалися, то навантаження на сервер було б вищим.
Але тільки треба помітити, що перше, що кожен має зробити — це включити це відображення. Хоча, звичайно, існують повністю закриті від зовнішнього світу деякі технологічні системи, де ніхто і ніколи ні чого не зламує. Але там саме такі системи обслуговують цілі команди профі.
Так, що давай, для початку — поправимо цю ситуацію і наведемо систему до нормального робочого вигляду.
Що ми зробимо:
- Обмежимо кількість дозволених одночасно відкритих сеансів.
(Якщо ти сам адмініструєш свій віддалений сервер, навіщо тобі треба, щоб хтось, крім тебе, одночасно з тобою керував сервером?
Хоча ще один може знадобитися — наприклад, для техпідтримки. А більше – навіщо?) - І ввімкнемо світло. Тобто дозволимо системі відображати в оснастці "Events" невдалі спроби входу.
І ось тут – ти здивуєшся. - Заборонимо доступ до сервера з більш ніж 3000 IP-адрес, які власне кажучи нічим іншим не займаються, крім доставляти людям проблеми. Імпортуємо чорний список.
Якщо ти знічев'я зробиш запити в мережі про налаштування RDP, то зустрінеш дуже багато порад (і я сам довго був упевнений, що вони дуже ефективні, поки не вирішив провести експеримент)
- Обмежити кількість дозволених помилкових спроб входу.
(Якщо ти не п'яний - то 3х разів тобі вистачить, щоб зрозуміти, що клавіатура не тією мовою і не тим регістром.) - Обмежити час для цих трьох спроб.
(Можна ж, 3 рази на тиждень, а можна — 3 рази на секунду, та ще й багатопотоково. І тому, як ніхто з кулхацкерів не тицяє в клавіатуру одним пальцем довго вибираючи букву, то там йде пристойний трафік, який за 10 хвилин, які визначили розробники встигне перебрати кілька сотень, кілька тисяч комбінацій.) - Встановити час блокування для входу у випадку, якщо ти п'яний, або якщо ти це не ти.
(За замовчуванням — 3 хвилини ні кого не засмутять. Виставимо півгодини. Нехай втомляться чекати.)
Зізнаюся, я дуже зрадів, коли знайшов такі статті, і відразу все зробив як треба. Був упевнений, що тепер можна зосередитися на самому проекті, і не турбуватися сильно за безпеку.
Як були десятки тисяч спроб на протязі доби. (А я не сиджу уткнувшись в монітор цілий день, але щодня заходжу перевірити працездатність своїх додатків) Так все і залишилося.
І все ніяк не міг зрозуміти, як же так, ось я бачу, що у мене налаштовано 3 спроби і потім блокування на 30 хвилин. А цей бот фігачить вже шість годин невтомно перебираючи логіни від Administrator до ферапонта.
Але все було не дозвілля. І потім — я все налаштував, значить — має працювати!
Одного разу, довелося переносити один власний проект з одного сервера на інший, внаслідок виходу з ладу RAID масиву. І старий сервер, протягом якогось часу був мені доступний, але на ньому можна було без побоювань спробувати провести небезпечні та не дуже експерименти. Тому я вирішив на ньому перевірити.
Для цього протягом декількох хвилин намагався залогінитися з неправильним паролем, очікуючи, що ось зараз мене система аутентифікації заблокує. Фігушки. Нічого не трапилося.
Я витратив кілька днів на більш детальне вивчення цієї проблеми. Поринув у мануали та мізерні коментарі. Усі як один запевняють на форумах – такий спосіб суперефективний.
І ось, що я тепер тобі скажу:
- по-перше – цей спосіб працює тільки під контролером домену (не знаєш – що це таке? Плюнь – це тобі не треба) а для standalone server – потрібно поринути у спеціальні знання та вивчити заклинання.
- по-друге — виявляється, і, мабуть, багато помилково і наївно припускають інше (як і я сам), що при реалізації такого механізму буде заблокований той, хто намагається увійти.
Ні, якраз, не він. А будеш заблокований Ти!
Так – саме твій обліковий запис буде заблокований на той час, який там ти прописав. І ти сам нізащо не зможеш увійти на власний сервер!
Виходячи з дому і замкнувши двері, зламаю замок. Відморожу вуха — на зло Бабусі.
Але думаю, що розлучення з такими ілюзіями — коштувало кілька днів мук.
З преамбулою покінчили. Давай займемося справою.
1. Обмежимо кількість дозволених одночасно відкритих сеансів.
Знаходимо та відкриваємо оснащення «Terminal Services Configuration»:
У цій оснастці вибираємо відкриваємо в «властивості» RDP-Tcp вкладку, де і обмежуємо «Msximum Connections» до 2х, для всіх мережевих адаптерів.
Тиснемо ОК. Тепер одночасно з тобою зможе зайти тільки ще одна людина. А без тебе всім бажаючим доведеться ставати в шеренги по двоє.
У чергу — сучі діти!
2. Включаємо відображення невдалих спроб входу до оснастки «Events».
Знаходимо і відкриваємо оснащення "Local Security Settings" і в ньому - розділ: "Audit Policy":
І змінюємо значення властивостей усіх записів Audit - як показано на скріншоті. Потрібно буде потім перезавантажитися, щоб зміни стали активними.
Можна зачекати і за кілька годин подивитися на тепер уже реальну картину, щоб осмислити в якому світі ми живемо, і хто нас оточує.
3. Забороняємо доступ до сервера від 100% шкідливих IP-адрес. Імпортуємо чорний список.
Тут у тебе 2 варіанти:
- Швидкий і одразу все.
- Ручний з розумінням, що саме ти робиш.
Швидкий спосіб.
Після чого, у тебе має вийти ось так:
Ручний спосіб з розумінням.
- Спочатку необхідно створити додаткову політику. Відкриваєш оснастку "Local Security Settings".
- Вибираєш розділ "IP Security Policies on Local Computer" та правою кнопкою: "Create IP Security Policy..." запускаєш Майстер налаштування.
- Вигадуєш ім'я для нового Правила. Наприклад: "Block IP".
- Далі, на всі питання тисни і на завершення у тебе буде форма для редагування властивостей Політики.
- Додаємо нове Правило. Тиснемо . і якщо стоїть галочка Wizard, то запуститься ще один Майстер, на які потрібно відповісти.
- Tunnel Endpoint. тисни
- Network Type. Там уже стоїть "All network connections". тисни
- IP Filter List.
Додаємо новий Фільтр. Тиснемо і вигадуємо осмислене Ім'я.
Наприклад: Block brute forcing IP.
Список у нього поки що порожній. Зберігаємо як є.
Служба 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 з'явився ряд нових можливостей, таких як (підключення через браузер), (доступ до термінальних служб через Інтернет), (Публікація окремих додатків за протоколом RDP) і служба (забезпечення балансування навантаження).
У 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 () і вище, а також клієнта RDP 6.0 або вище.
Налаштувати NLA можна на сервері RD Session, відкривши консоль Administrative Tools -> Remote Desktop Services -> Desktop Session Host Configuration.
- Клацніть правою кнопкою миші на підключення
- Виберіть Properties
- Перейдіть на вкладку General
- Позначте опцію “Allow connections only from computers running Remote Desktop with Network Level Authentication”
- Натисніть кнопку 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, всі клієнти, які не підтримують даний вид шифрування, не зможуть підключитися до сервера.
Налаштувати тип автентифікації сервера та рівень шифрування можна так:
- На сервері RD Session Host відкрийте вікно конфігурації Remote Desktop Session Host і перейдіть у вікно властивостей.
- На вкладці General, у випадаючих меню виберіть необхідний рівень безпеки та тип шифрування.
- Натисніть кнопку 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 за допомогою Network Level Authentication:Політика включає вимогу NLA для всіх з'єднань із термінальним сервером (клієнти без підтримки NLA підключитися не зможуть).
Параметри налаштування клієнта RDC знаходяться в підрозділі RemoteDesktopConnectionClient:
- Donotallowpasswordstorusaved: політика забороняє зберігати паролі в клієнті 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. За замовчуванням використовується сертифікат.
Протокол 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 (за винятком відсутніх можливостей).
Для успішної реалізації цього рішення у вашій мережі повинен знаходитися працюючий центр сертифікації, налаштування якого ми розглядали в . Для довіри сертифікатам виданим даним ЦС на термінальний сервер необхідно встановити сертифікат ЦС (або ланцюжок сертифікатів) у сховищі.
Потім слід виконати запит на сертифікат автентичності сервера з наступними параметрами:
Ім'я - повне ім'я термінального сервера (тобто server.domain.com якщо сервер входить до домену domain.com)
- Тип сертифікату Сертифікат автентифікації сервера
- Встановіть опцію Створити новий набір ключів
- CSP - Microsoft RSA SChannel Cryptographic Provider.
- Встановіть прапорець Позначити ключ як експортований.
- Для ЦС підприємства встановіть прапорець Використовувати локальне сховище комп'ютера для сертифіката. (В автономному ЦС ця опція недоступна).
Надішліть запит центру сертифікації та встановіть виданий сертифікат. Цей сертифікат повинен бути встановлений у локальне сховище комп'ютера, інакше він не може бути використаний службами терміналів. Щоб перевірити це запустимо консоль MMC (Пуск - Виконати - mmc) і додамо оснастку Сертифікати(Файл - Додати або видалити оснастку) для облікового запису комп'ютера.
У корені консолі виберіть натисніть Вигляд - Параметрита встановіть режим перегляду Впорядкувати сертифікати за призначенням. Виданий сертифікат повинен перебувати у групі Перевірка автентичності сервера.
Якщо ви отримували сертифікат за допомогою ізольованого (автономного) ЦС (мережа не має доменної структури), то він за замовчуванням буде встановлений у сховищі облікового запису користувача і доведеться виконати ряд додаткових дій.
Відкрийте Internet Explorer - Властивості браузера - Вміст - Сертифікати, виданий сертифікат має бути встановлений у сховищі Особисті.
Виконайте його експорт. При експорті вкажіть такі опції:
- Так, експортувати закритий ключ
- Видалити закритий ключ після успішного експорту
Після цього видаліть сертифікат із сховища. У оснащенні Сертифікати (локальний комп'ютер)виберіть розділ Перевірка автентичності сервера, клацніть правою кнопкою миші Усі завдання - Імпортта імпортуйте сертифікат.
Тепер у Адміністрація - Служби віддалених робочих століввідкрийте Конфігурація вузла сеансів віддалених робочих столів(Windows Server 2003 Адміністрація - Налаштування служб терміналів).
Виберіть необхідне підключення та відкрийте його властивості. У самому низу натисніть кнопку Вибратиі виберіть сертифікат, отриманий на попередньому кроці (у Windows Server 2003 це вікно виглядає дещо інакше).
Після вибору сертифіката вкажіть інші властивості:
- Рівень безпеки SSL
- Рівень шифрування Високийабо FIPS-сумісний
- Встановіть прапорець Дозволити підключатися лише з комп'ютерів.(недоступно у Windows Server 2003)
Збережіть введені параметри, на цьому налаштування сервера закінчено.
На клієнтському ПК створіть підключення до віддаленого робочого столу, використовуйте як адресу повне ім'я сервера, зазначене в сертифікаті. Відкрийте властивості підключення та на закладці Підключення - Перевірка автентичності серверавстановіть опцію Попереджати.
Щоб цей ПК довіряв сертифікатам виданим нашим центром сертифікації, не забудьте встановити на нього сертифікат ЦС у сховище. Довірені кореневі центри сертифікації.
У Windows 7 (при використанні RDP клієнта версії 7) цей сертифікат потрібно встановити в сховище облікового запису комп'ютера, для цього імпортуйте його через оснастку Сертифікати (локальний комп'ютер)у консолі MCC, аналогічно тому, як це робили вище. В іншому випадку підключення буде неможливо і ви отримаєте таку помилку:
Встановивши сертифікат ЦС, можете пробувати підключитися, зверніть увагу, що ім'я користувача та пароль буде запропоновано ввести ще до створення RDP сесії. У разі успішного з'єднання зверніть увагу на замок у заголовку вікна, який свідчить про роботу через SSL. Натиснувши на нього, можна переглянути інформацію про сертифікат.
І насамкінець крапля дьогтю в бочці меду. Термінальні служби Windows не вміють перевіряти справжність клієнтів, тому якщо варто така необхідність слід використовувати додаткові методи захисту, такі як SSH тунель або IPSec VPN.