Компьютерные сети и технологии
Привет
Пользователь:

Пароль:



[ ]
[ ]

В сети
Гостей: 12
Участников: 0
На странице: 1
Участников: 4059, Новичок: Wonfrien

Разное


Индивидуальный RDP-доступ для администратора
на Wednesday 29 August 2012
от список авторов отправить по email статья печатать статья
в Сетевые Операционные Системы ОС > ОС Windows

Индивидуальный RDP-доступ для администратора

Статья поможет сисадминам небольших предприятий организовать простое и достаточно безопасное удаленное администрирование, используя малоизвестные возможности реализации RDP на серверах под управлением Windows

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

Условия работы и постановка задачи
Давайте рассмотрим характерную ситуацию малого предприятия.
Руководство которого всячески экономит на ИТ-сегменте:

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


Свойства нового RDP - соединения


В простейшем случае удаленное администрирование организуется через переадресацию порта 3389 с роутера на терминальный сервер (так называемый port mapping).
Но что делать, если на этом же сервере работает в терминальном режиме «1С» и тем самым в группу пользователей удаленных рабочих столов входит большая часть сотрудников фирмы?
Ситуация, как правило, усугубляется тем, что руководство и работники предприятия знать не хотят о требованиях ИТ-безопасности, т.е. не желают своевременно менять пароли и соблюдать требования к их стойкости. То есть каждый желающий, зная IP конторы и логин с паролем любого из сотрудников, которому разрешен терминальный доступ, может из любой точки планеты зайти на сервер.
Конечно же, данная ситуация совершенно неприемлема. Однако как быть, если организация «экономит на спичках» и не хочет платить за услуги по устройству VPN?
Хотя, положа руку на сердце, следует признать тот факт, что организация VPN для удаленного доступа одного человека - это явная избыточность. Да и нагружать несчастный сервер еще и функциями управления VPN - это верный путь к жалобам пользователей на невыносимо медленную его работу.
Относительно приемлемый и в то же время низкобюджетный режим ИТ-безопасности подобных организаций основывается на разделении доступа к сессиям RDP:

- сотрудники предприятия имеют терминальный доступ к серверу лишь из LAN;
- администратор предприятия - вдобавок к этому еще из Интернета.
Реализуется такая схема созданием дублирующего слушателя RDP и прописыванием соответствующих разрешений для него.
В результате персонал предприятия, входящий в группу пользователей удаленных рабочих столов, будет исключительно изнутри сети обращаться к серверу по стандартному порту 3389, а администратор - еще и снаружи по определенным им самим портам на роутере и сервере.
При этом сотрудники предприятия, даже зная номер открытого наружу порта, получить из Интернета терминальный доступ к серверу под своими логинами и паролями не смогут.

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

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ Terminal Server\WinStations\RDP-Tcp] "PortNumber"=dword:0 0 0 0 0d3d

Определяемся, на каком порту сервер (и роутер, конечно) будет нас слушать... ну, скажем, 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.
Но то, как это сделать, выходит за рамки данной статьи. Всех интересующихся отсылаю к публикации Руслана Кар-манова «Защищаем и оптимизируем RDP» [1].
Ну, и, в-третьих, забота о стойкости логина и пароля администратора к brut-force атакам, разумеется, полностью на вашей совести.
Конечно же, VPN, IPSec и прочие порождения сумрачного гения ИТ-технологов требуют обращать больше внимания на безопасность... но ведь все в конечном счете определяется тем, сколько работодатель готов потратить на труд администратора, и этот рецепт - лишь для случаев жесткой экономии.

Позаимствовано: Системный Администратор 06 / 2012 (Андрей Бусыгин)

Поиск Компьютерные сети и технологии


Copyright © 2006 - 2016
При использовании материалов сайта ссылка на xnets.ru обязательна!
Rambler's Top100
Render time: 0.0984 second(s); 0.0212 of that for queries. DB queries: 28. Memory Usage: 5,003kb