Статья поможет сисадминам небольших предприятий организовать простое и достаточно безопасное удаленное администрирование, используя малоизвестные возможности реализации 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-файл, после чего открываем файл на редактирование. Собственно говоря, нас интересуют лишь две строки:
Определяемся, на каком порту сервер (и роутер, конечно) будет нас слушать... ну, скажем, 4477 или 117D в шест-надцатеричке. Правим название будущей ветки реестра на RDP-Tcp2 и номер порта на 117D. Можете назначить любой порт, не используемый предприятием, но все же избегайте тех, что задействованы широко распространенными сетевыми сервисами. У вас должно получиться:
Сохраняем файл реестра, а потом двойным щелчком импортируем его. Перезагружаем сервер и запускаем оснастку «Конфигурация узла сеансов удаленных рабочих столов» -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 и прочие порождения сумрачного гения ИТ-технологов требуют обращать больше внимания на безопасность... но ведь все в конечном счете определяется тем, сколько работодатель готов потратить на труд администратора, и этот рецепт - лишь для случаев жесткой экономии.
