RDP

Давайте рассмотрим характерную ситуацию малого пред­приятия.

Руководство которого всячески экономит на ИТ-сегменте:

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

                        Доступ в Интернет, как правило, в таких случаях орга­низуется через дешевый роутер, а на прокси-сервере и услугах его администрирования контора экономит, благо безлимит ныне доступен любому.

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

В простейшем случае удаленное администрирование организуется через переадресацию порта 3389 с роутера на терминальный сервер (так называемый port mapping).

Но что делать, если на этом же сервере работает в тер­минальном режиме «1C» и тем самым в группу пользовате­лей удаленных рабочих столов входит большая часть сот­рудников фирмы?

Относительно приемлемый и в то же время низкобюджет­ный режим ИТ-безопасности подобных организаций осно­вывается на разделении доступа к сессиям RDP:

·         сотрудники предприятия имеют терминальный доступ к серверу лишь из LAN;

·         администратор предприятия - вдобавок к этому еще из Интернета.

Реализуется такая схема созданием дублирующего слу­шателя RDP и прописыванием соответствующих разреше­ний для него.

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

При этом сотрудники предприятия, даже зная номер от­крытого наружу порта, получить из Интернета терминаль­ный доступ к серверу под своими логинами и паролями не смогут.

Создание нового слушателя RDP и его настройка

Итак, запускаем на сервере regedit и экспортируем узел реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ ControMerminal Server\WinStations\RDP-Tcp в текстовый reg-файл, после чего открываем файл на редактирование. Собственно говоря, нас интересуют лишь две строки:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ Terminal Server\WinStations\RDP-Tcp]

"PortNumber"=dword:00000d3d

Определяемся, на каком порту сервер (и роутер, конеч­но) будет нас слушать... ну, скажем, 4477 или 117D в шест- надцатеричке.

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

У вас должно получиться:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ Terminal Server\WinStations\RDP-Tcp2]

"PortNumber"=dword:0000117d

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

Перезагружаем сервер и запускаем оснастку «Кон­фигурация узла сеансов удаленных рабочих столов» - tsconfig.msc (в Windows 2003 - «Настройка служб термина­лов» - tscc.msc). 

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

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

Теперь осталось лишь организовать переадресацию с роутера и проверить результат работы. В параметрах NAT роутера создаем виртуальный сервер, внешний порт 4477, внутренний 4477 на вашем терминальном сервере.

Пробуем соединиться. Запускаем на своем домашнем компьютере «Подключение к удаленному рабочему столу» по нужному белому IP или заблаговременно созданному на сервере dyndns.org адресу company.dyndns.org:4477. На приглашение ввести логин и пароль вводим данные ад­министратора. Получаем доступ к удаленному рабочему столу подопечного сервера.

Для проверки завершаем сеанс и вновь подключаемся к company.dyndns.org:4477, но теперь вводим логин и па­роль пользователя, входящего только в группу пользовате­лей удаленных рабочих столов, но не в группу администра­торов.

 Если настроено все правильно, то должны получить ответ сервера:

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

Теперь осталось только удалить с роутера старый проброс стандартного порта 3389, через который мы и настрои­ли нового слушателя RDP, если, конечно, вы работали уда­ленно.

Цель достигнута: сотрудники компании изолированы вну­три локальной сети организации, а вы можете администри­ровать сервер из любого удобного для вас места.

Дополнительная защита протокола

Что можно сделать еще? Ну, во-первых, защитить соеди­нение. Во вкладке «Общие» свойств нашего нового RDP- подключения выставляем уровень шифрования в «Высо­кий» либо «FIPS-совместимый». Этот параметр потребует указания сертификата сервера - вполне подойдет автома­тически созданный.

Во-вторых, если у вас Windows Server 2008, т.е. версия RDP 6.0 и выше, можно включить дополнительно проверку подлинности со стороны сети (NLA).

Суть ее в том, что клиент авторизуется на сервере до создания терминальной сессии, что служит защитой про­тив DoS-атак, заставляющих сервер создавать RDP-сессии по каждому обращению на соответствующий порт.

Включается это флажком на той же самой вкладке «Об­щие Разрешить подключаться только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети».

Однако включение шифрования, и в особенности техно­логии NLA, требует в качестве клиентских машин Windows ХР SP3 и более поздние версии ОС. Причем если шифрование протокола на ХР после установки третьего сервис-пака бу­дет работать сразу и «прозрачно», то для возможности про­верки подлинности на уровне сети вам еще придется вруч­ную добавить новый криптопровайдер CredSSP.

1. Карманов Р. Защищаем и оптимизируем RDP - http:// kb.atraining.ru/windows-rdp-tuning.