Наверняка, многие из вас уже слышали и видели эту аббревиатуру - дословно переводится она, как Протокол удалённого рабочего стола (Remote Desktop Protocol) . Если кого-то интересуют технические тонкости работы этого протокола прикладного уровня - могут почитать литературу, начиная с той же самой википедии. Мы же рассмотрим чисто практические аспекты. А именно тот, что данный протокол позволяет удалённо подключаться к компьютерам, под управлением 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 раза за неделю, а можно — 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).
- Always Prompt for Password upon Connection : данная политика используется, если необходимо всегда спрашивать пароль пользователя при подключении к сессии RD, даже если пароль был введен в клиенте RDC. По умолчанию, пользователи могут автоматически входить в сессию, если они указали пароль в клиенте RDC.
- Require Secure RPC Communication : — при включенной политики разрешены только аутентифицированные и шифрованные запросы от клиентов.
- Require Use of Specific Security Layer for Remote (RDP ) Connections : при включенной политике, все соединения между клиентом и сервером терминалов должны использовать уровень безопасности, указанный здесь (RDP, Negotiate или SSL/TLS)
- Do Not Allow Local Administrators to Customize Permissions : политика отключает возможность администраторам настраивать параметры безопасности RD Session Host.
- Require User Authentication for Remote Connections by using Network Level Authentication: Политика включает требование NLA для всех соединения с терминальным сервером (клиенты без поддержки NLA подключиться не смогут).
Параметры настройки клиента RDC находятся в подразделе Remote Desktop Connection Client :
- Do not allow passwords to be saved : политика запрещает сохранять пароли в клиенте RDC, опция «Сохранить пароль» становится недоступна, все ранее сохраненные пароли будут удалены.
- Specify SHA 1 thumbprints of certificates representing trusted .rdp publishers : эта политика позволяет создать список отпечатков SHA1 сертификатов, и если сертификат соответствует отпечатку в это списке, он считается доверенным.
- Prompt for credentials on the client computer : политика активирует запрос учетных данных пользователя на клиентском компьютере, а не сервере 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.