Защищаем удаленный сервер на Windows как можем

Тема безопасности сервера Windows не раз поднималась, в том числе и в этом блоге. Тем не менее мне хотелось бы еще раз освежить в памяти старые методы защиты и рассказать о малоизвестных новых. Разумеется, будем использовать по максимуму встроенные средства.

Итак, предположим, что у нас есть небольшая компания, которая арендует терминальный сервер в удаленном дата-центре.

При проектировании любой защиты следует начинать с модели угроз — от кого или чего, собственно, будем защищаться. В нашей типовой конфигурации я буду строить оборону от внешних злобных хакеров, от некомпетентных (а может, и немного злонамеренных) пользователей. Начнем с внешнего периметра обороны — фаервола.

За тобой как за огненной стеной

Во времена Windows 2003 встроенный фаервол представлял собой жалкое зрелище, и в случае невозможности применения сторонних средств приходилось использовать IPSec. Пример такой настройки разобран, например, в материале Secure Windows Servers using IPSec Firewall.

Сейчас, с появлением WFP (Windows Filtering Platform) дела стали получше. В принципе, с этим фаерволом так или иначе сталкивался, наверное, каждый системный администратор Windows, поэтому настройка удаленного доступа к серверу только с определенных IP не должна вызывать затруднений. Я обращу внимание на некоторые «фишки», которые используются редко.

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

Теперь, если мы захотим запретить пользователям терминального сервера выходить с этого сервера в интернет — у нас это получится.

Стоит отметить, что при настройке правил доступа к серверу (входящие подключения) явно создавать правила для исходящего трафика не нужно. В терминах iptables — established и related всегда разрешены.

Для ценителей командной строки настройку фаервола можно производить в контексте netsh advfirewall. Почитать про команды можно в материале «Брандмауэр Windows 7 в режиме повышенной безопасности», я же добавлю, что блокировка входящих и исходящих подключений включается командой:

Еще одной особенностью фаервола windows является то, что любая программа или настройка меняет его правила без уведомлений. Например, отключили вы все правила на нашем дедике, рядом появился второй, вы сделали между ними локальную сеть, настроили общий доступ и… внезапно у вас включается smb для всех и вся со всеми вытекающими последствиями.

Выхода, по сути, два с половиной (напомню, мы пока говорим только про встроенные средства): регулярно проверять, не изменились ли правила, и использовать старый добрый IPSec или — как по мне, самый разумный вариант — настраивать фаервол групповой политикой. Настройка производится в Конфигурация компьютера — Конфигурация Windows — Параметры Безопасности — Монитор брандмауэра Защитника Windows в режиме повышенной безопасности.

Настройка фаервола групповой политикой.

Также при помощи фаервола windows можно реализовать простой fail2ban. Достаточно включить аудит неудачных попыток входа и при нескольких неудачах подряд блокировать IP источника. Можно использовать самописные скрипты, а можно уже готовые средства, о которых я писал в статье «Как дать шифровальщикам потопить компанию».

Если же встроенного фаервола не хватает и хочется использовать что-то более серьезное, то можно установить стороннее ПО. Жаль, что большинство известных решений для Windows Server — платные. Другим вариантом будет поставить перед сервером роутер. Понятно, что такая установка подойдет, если мы используем colocation, а не аренду сервера где-то далеко-далеко за рубежом. Если же зарубежный дата-центр — это наш выбор, то можно использовать виртуализацию — например, встроенный Hyper-V — и установить в виртуалку привычный GNU\Linux или FreeBSD.

Возникает вопрос: как сделать так, чтоб виртуалка имела прямой выход в интернет, а сервер — нет? Да еще чтобы MAC-адрес сервера не светился хостеру и не требовал тем самым покупки еще одного IP-адреса.

Осторожно! Дальнейшие действия лучше проводить через IP-KVM!

Для этого виртуальную машину нужно снабдить двумя сетевыми адаптерами. Один — для непосредственного подключения к интернету, для него мы сделаем виртуальный коммутатор типа «внешний» и снимем галочку, разрешающую операционной системе взаимодействие с этим коммутатором. Этой самой галочкой мы лишим сервер прямого доступа в интернет (настройку виртуальной машины-фаервола лучше произвести заранее), и его MAC не будет светиться хостеру.

Настройка внешнего виртуального коммутатора.

Другой виртуальный коммутатор следует сделать типа «внутренний» для взаимодействия виртуальной машины и сервера. На нем уже нужно настроить локальную адресацию. Так получится создать виртуальный роутер, стоящий перед сервером и защищающий его.

Заодно на этой виртуальной машине можно настроить любимый VPN до офиса или удаленных сотрудников, не заморачиваясь с ролью «Маршрутизация и удаленный доступ» или со встроенным IPSec, как я рассказывал в статье «Как я базы 1С в Германии прятал». Главное, не забыть проверить автозапуск этой виртуальной машины при старте системы.

Подключаться к такому серверу можно при помощи обычного RDP или использовать HTML5 клиенты с двухфакторной аутентификацией. Стоит на случай брутфорса озаботиться и решениями fail2ban, и блокировкой учетной записи на некоторое время при нескольких неудачных попытках авторизации подряд.

Снаружи сервер мы более-менее защитили, перейдем к защите внутренней.

Защита внутренняя: остановить и не пущать

Конечно, для защиты сервера изнутри очень хочется поставить какой-нибудь антивирус — мало ли что пользователи сервера накопируют или накачают из интернета. Но на практике антивирус на сервере может принести больше вреда, чем пользы. Поэтому я обычно использую механизмы блокировки запуска ПО не из белого списка — в частности, механизм SRP (software restriction policies), о котором я тоже упоминал в статье «Как дать шифровальщикам потопить компанию».

Остановлюсь чуть подробнее на одном подводном камне, о котором часто забываем при включении SRP со стандартными настройками, когда блокируется все, кроме папок Windows и Program Files. Действительно, это отфильтровывает почти всех зловредов. Но не очень работает со злонамеренностью сотрудников, ведь в системных папках есть подпапки с правом на создание объектов пользователями. Например, можно посмотреть на папку C:\Windows\Temp.

Разрешения на папку, которая попадет в белый список.

И такая папка не одна. Можно, конечно, проводить аудит системных папок самостоятельно, а можно довериться людям, которые это уже сделали. Например, специалист Stefan Kanthak в своем блоге (по ссылке есть тестовый вирус EICAR, антивирус может сработать) в довольно агрессивной манере проходится по антивирусам и методам защиты Windows и заодно предлагает уже собранный пакет настроек SRP, который будет блокировать и такие подозрительные папки. По запросу автор предоставляет и программу для конвертирования этих настроек реестра в файлы локальных политик.

Если вы предпочитаете использовать механизм AppLocker c более гибкими настройками, то вам может помочь решение AaronLocker.

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

Если AppLocker появился уже довольно давно, а возраст SRP перевалил за 15 лет, то относительно свежей альтернативой является WDAC (Windows Defender Application Control). Действительно, со времен Security Essentials встроенный «антивирус» обзавелся многими интересными возможностями. Например, WDAC — модуль, который отвечает за политики доступа к приложениям и библиотекам. Ранее он являлся частью Device Guard (защита компьютера, в том числе с применением технологий виртуализации), и немного про его настройку рассказывалось в материале «Принцип работы S Mode в Windows 10 и настройка Device Guard своими руками». Подробнее со всеми тонкостями можно ознакомиться в официальной документации, мне же остается добавить несколько минусов, отличающих его от классических решений вроде SRP и AppLocker:

• Графической настройки нет, все через командлеты PowerShell.
• Нет настроек в срезе пользователя, только для компьютера.
• Настройка делается довольно непривычно — подготавливается файл в формате xml, который затем приводится к бинарному, и распространяется по компьютерам.

Зато возможна настройка в срезе приложения: например, если вы хотите дать доступ к cmd.exe вашему скрипту, а не стороннему вирусу — это можно реализовать. Да еще и политику можно применить до загрузки системы, при помощи UEFI.

Блокировка хрома через WDAC.

В целом из-за тягостной настройки сложилось впечатление, что WDAC больше позиционируется не сам по себе для управления компьютерами, а как средство, позволяющее интегрироваться с централизованными MDM-системами вроде Microsoft Intune. Но при этом разработка старых добрых SRP прекращена в Windows 10 1803.

Если говорить про Защитник Windows, нельзя не упомянуть про Credential Guard и Remote Credential Guard.

Первое средство использует опять же виртуализацию, запуская компонент LSA (Local Security Authority) в изолированном от операционной системы процессе, что сильно усложняет процесс кражи хешей паролей и билетов Kerberos. Подробнее про технологию можно почитать в официальной документации. Для работы процессор должен поддерживать виртуализацию, а также в системе должна быть включена безопасная загрузка (Secure Boot) и модуль TPM для привязки учетных данных к оборудованию. Включить Credential Guard можно через групповую политику Конфигурация компьютера — Административные шаблоны — Система — Device Guard — Включить средство обеспечения безопасности на основе виртуализации.

Включение Credential Guard.

Второе средство служит для защиты передаваемых учетных данных (особенно админских!) для удаленного подключения, например, по тому же RDP. Ранее для этих целей предлагался механизм Restricted Admin Mode, но он ограничивал подключение только одним сервером. Подключившись к серверу, нельзя было просто так использовать ресурсы сети, права администратора применялись только к одному серверу а-ля системный аккаунт Local System.

Remote Credential Guard позволяет передавать учетные данные с локальной машины удаленному серверу без явного ввода пароля, что, помимо расширенной безопасности, даст и удобство подключения к серверам (SSO). Почитать подробнее можно в документации, ну а я добавлю, что для работы механизма достаточно включить его поддержку на сервере — например, через реестр командой:

А потом подключаться к серверу командой:

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

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Рекомендации по обеспечению безопасности Windows Server 2008/2012

Этот материал содержит базовые рекомендации по обеспечению безопасности серверов под управлением Microsoft Windows Server 2008/2012:

Регулярно устанавливайте важные обновления ОС Windows Server и ПО

Поддержание операционной системы и установленного ПО в актуальном состоянии, помимо устранения неисправностей в работе программ, помогает обеспечить защиту вашего сервера от части уязвимостей, о которых стало известно разработчикам до момента выхода апдейта. Вы можете настроить Windows на автоматическую загрузку (установку) важных и рекомендуемых обновлений через утилиту «Центр обновления Windows».

Используйте только ПО из проверенных источников

Несмотря на распространенность качественных программных open-source продуктов, доступных «в один клик», призываем вас изучить известные уязвимости такого ПО перед его установкой и использовать для загрузки дистрибутивов только официальные источники. Именно самостоятельная установка администратором или пользователем уязвимого или уже «упакованного» вирусным кодом софта зачастую является причиной проблем с безопасностью инфраструктуры.

Виртуальный сервер на базе Windows

Уделите должное внимание настройке Firewall

Для серверов Windows Server, доступных через интернет и при этом не находящихся за выделенным устройством, выполняющим функцию фаерволла, Брандмауэр Windows является единственным инструментом защиты внешних подключений к серверу. Отключение неиспользуемых разрешающих и добавление запрещающих правил будет означать, что меньше портов на сервере прослушивают внешний входящий трафик, что снижает вероятность атак на эти порты. Например, для работы стандартного веб-сервера достаточно открыть следующие порты:
80 – HTTP
443 – HTTPS

Для портов, доступ к которым должен оставаться открытым, следует ограничить круг источников подключения путем создания «белого списка» IP-адресов, с которых будут приниматься обращения. Сделать это можно в правилах Брандмауэра Windows. Это обеспечит уверенность в том, что у всех, кому требуется доступ к серверу, он есть, но при этом запрещен для тех, кого «не звали».

Ниже представлен список портов, доступ к которым лучше ограничить только кругом клиентов, внесенных в белый список IP:

• 3389 – Стандартный порт RDP
• 990 – FTPS
• 5000-5050 – порты для работы FTP в пассивном режиме
• 1433-1434 – стандартные порты SQL
• 53 – DNS

Переименуйте стандартную учетную запись администратора

Т.к. стандартная запись локального администратора «Administrator» по-умолчанию включена во всех сегодняшних версиях ОС Windows и имеет неограниченные полномочия, именно к этому аккаунту чаще пытаются подобрать пароль для получения доступа к управлению сервером, т.к. это проще, чем выяснять имена пользователей.

Рекомендуется сменить имя пользователя для стандартной учетной записи Adminstrator. Для этого выполните следующие действия:

1. Откройте оснастку «Выполнить» (WIN+R), в появившемся окне введите: secpol.msc
2. Откройте Редактор локальной политики безопасности. В меню выберите Локальные политики -> Параметры безопасности -> Учетные записи: Переименование учетной записи администратора

Во вкладке Параметр локальной безопасности измените имя учетной записи администратора на желаемое и сохраните изменения.

Создайте несколько административных аккаунтов

Если в администрировании вашей инфраструктуры задействовано несколько человек, создайте для каждого из них отдельную учетную запись с административными правами. Это поможет отследить, кто именно санкционировал то ли иное действие в системе.

По возможности используйте для работы учетную запись с ограниченными правами

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

Не предоставляйте общий доступ к директориям без ввода пароля, разграничивайте права общего доступа

Никогда не разрешайте подключение к общим папкам сервера без ввода пароля и анонимный доступ. Это исключит возможность простого получения несакционированного доступа к вашим файлам. Даже если эти файлы сами по себе не имеют никакой ценности для злоумышленника, они могут стать «окном» для дальнейшего вторжения, так как пользователи вашей инфраструктуры, вероятнее всего, доверяют этим файлам и вряд ли проверяют их на вредоносный код при каждом запуске.

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

Включите запрос пароля для входа в систему при выходе из режима ожидания и автоотключение сессий при бездействии.

Если вы используете физический сервер Windows, настоятельно рекомендуем включить запрос пароля пользователя при выходе из режима ожидания. Сделать это можно во вкладке «Электропитание» Панели управления (область задач страницы «Выберите план электропитания»).

Помимо этого, стоит включить запрос ввода пароля пользователя при подключении к сессии после установленного времени ее бездействия. Это исключит возможность простого входа от имени пользователя в случае, когда последний, например, забыл закрыть RDP-клиент на персональном компьютере, на котором параметры безопасности редко бывают достаточно стойкими. Для конфигурации этой опции вы можете воспользоваться утилитой настройки локальных политик secpol.msc, вызываемой через меню «Выполнить» (Win+R->secpol.msc).

Используйте Мастер настройки безопасности

Мастер настройки безопасности (SCW – Security Configuration Wizard) позволяет создавать XML-файлы политик безопасности, которые затем можно перенести на различные серверы вашей инфраструктуры. Эти политики включают в себя правила использования сервисов, конфигурацию общих параметров системы и правила Firewall.

Корректно настройте групповые политики безопасности

Помимо предварительной настройки групповых политик Active Directory (при их использовании) время от времени проводите их ревизию и повторную конфигурацию. Этот инструмент является одним из основных способов обеспечения безопасности Windows-инфраструктуры.

Для удобства управления групповыми политиками, вы можете использовать не только встроенную в дистрибутивы Windows Server утилиту «gpmc.msc», но и предлагаемую Microsoft утилиту «Упрощенные параметры настройки безопасности» (SCM-Security Compliance Manager), название которой полностью описывает назначение.

Используйте локальные политики безопасности

Помимо использования групповых политик безопасности Active Directory следует также использовать локальные политики, так как они затрагивают не только права пользователей, выполняющих вход через доменную учетную запись, но и локальные аккаунты. Для управления локальными политиками вы можете использовать соответствующую оснастку «Локальная политика безопасности», вызываемую командой secpol.msc («Выполнить» (WIN+R)).

Безопасность служб удаленных рабочих столов (RDP)

— Блокировка RDP-подключений для учетных записей с пустым паролем

Эта мера является весьма очевидной, но она не должна игнорироваться. Для блокировки подключений к удаленным рабочим столам пользователю, пароль для которого не указан, откройте утилиту «Computer Configuration» -> «Настройки Windows» -> «Настройки безопасности» -> «Локальные политики безопасности -> «Параметры безопасности» и включите (Enable) параметр «Учетные записи: Разрешить использование пустых паролей только при консольном входе(Accounts: Limit local account use of blank passwords to console logon only).

— Смена стандартного порта Remote Desktop Protocol

Нажмите ОК и закройте редактор ресстра

Обратите внимание на ваши правила Firewall (Брандмауэр Windows). Они должны разрешать внешние подключения по установленному выше порту. Для добавления разрешающего правила выполните следующее:
— Откройте Брандмауэр Windows
— В левой части окна программы выберите «Дополнительные параметры», а затем «Правила для входящих подключений», и нажмите «Создать правило»

— В появившемся окне Мастера выберете правило «Для порта»
— Далее указываем «Определенный локальный порт TCP: <номер выбранного вами выше порта>». Нажимаем готово.

>Перезагружаем сервер для применения изменений.

Для подключения к серверу через установленный вручную порт необходимо на локальной машине ввести номер порта после IP-адреса сервера, разделив эти значения двоеточием, в окне подключения к удаленному рабочему столу, как показано на изображении:

— Настройка шлюза служб терминалов (Terminal Services Gateway)

Служба «Шлюз TS (служб удаленных рабочих столов)» позволяет удаленным пользователям осуществлять удаленное подключение к терминальным серверам и другим машинам частной сети с включенной функцией RDP. Она обеспечивает безопасность подключений за счет использования протокола HTTPS (SSL), снимая с администратора необходимость настройки VPN. Этот инструмент позволяет комплексно контролировать доступ к машинам, устанавливать правила авторизации и требования к удаленным пользователям, а именно:

• пользователей (группы пользователей), которые могут подключаться к внутренним сетевым ресурсам;
• сетевые ресурсы (группы компьютеров), к которым пользователи могут подключаться;
• должны ли клиентские компьютеры быть членами групп Active Directory;
• необходимо ли клиентам использовать проверку подлинности на основе смарт-карт или пароля, или они могут использовать любой из двух вышеперечисленных способов аутентификации.

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

Установка службы Шлюза TS

Для установки шлюза служб терминала на соответствующей машине под управлением Windows Server 2008/2012 выполните следующие действия:

1. Откройте утилиту Server Manager (Управление сервером) -> вкладка Роли -> Добавить роль
2. На странице выбора ролей сервера выберите Службы терминала (Службы удаленных рабочих столов)
3. В окне выбора служб ролей выберите Шлюз TS (Шлюз служб удаленных рабочих столов) и нажмите Далее
4. На странице выбора сертификата аутентификации сервера для шифрования SSL выберите опцию Выбрать сертификат для SSL-шифрования позже. Этот выбор обусловлен тем, что соответствующий сертификат шлюза TS еще не сгенерирован.

На появившейся странице создания политик авторизации для шлюза выберите опцию Позже

На странице выбора служб ролей должна быть отмечена служба Сервер сетевой политики (Network Policy Server)

Установите требуемые службы ролей, которые будут отмечены системой по умолчанию.

Создание сертификата для шлюза служб удаленных рабочих столов

Для инициирования SSL-подключений от клиентов RDP, для шлюза должен быть создан соответствующий сертификат:

1. В меню Администрирование выберите оснастку IIS Manager
2. В левой части появившегося окна выберите необходимый сервер, а затем пункт Сертификаты сервера -> Создать сертификат домена

На странице Определенные свойства имени укажите требуемые сведения. Обратите внимание на поле Общее имя – оно должно соответствовать имени, указанному в настройках клиентов служб RDP.

На следующей странице Интерактивный центр сертификации выбираем имя Enterprise CA, от имени которого должен быть выдан сертификат, и вводим значение параметра Сетевое имя.

Теперь сведения о созданном сертификате отображаются в окне Сертификаты сервера. При двойном клике на этом сертификате можно увидеть информацию об объекте назначения и о наличии закрытого ключа для данного сертификата (без которого сертификат не используется).

Настройка шлюза TS на использование сертификата

После создания сертификата, необходимо настроить шлюз терминалов на его использование:

1. Откройте меню «Администрирование», выберите «Службы терминалов (удаленных рабочих столов)», выберите Шлюз терминальных серверов.
2. Слева выберите сервер, которой будет выполнять роль шлюза. Будет отображена информация о шагах, необходимых для завершения конфигурации.

Выберите опцию «Показать или изменить свойства сертификата».

Во вкладке «SSL Сертификат» проверьте активность опции «Выбрать существующий сертификат для SSL шифрования» и выберите Просмотр сертификатов для отображения оснастки для установки сертификатов. Выберите и установите ранее сгенерированный сертификат.

После указания сертификата следует настроить политики авторизации подключений и авторизации ресурсов. Политика авторизации подключения (CAP — Сonnection Authorization Policy) позволяет контролировать полномочия клиентов при их подключении к терминалам через шлюз:

Откройте меню «Политики авторизации соединений», находящуюся во вкладке «Политики» — > «Создать новую политику» -> Мастер(Wizard), на вкладке «Политики авторизации» -> выберите Cоздать только TS CAP. Вводим имя создаваемой политики. В нашем случае «1cloud Gateway». На вкладке «Требования» активируем требование пароля, а затем указываем группы пользователей, которым необходимо предоставить доступ в инфраструктуру терминалов – введите имя добавляемой группы и кликните «Проверить имена (Check Names)».

Разрешите перенаправление устройств для всех клиентских устройств. Вы также можете отключить перенаправление для некоторых типов уст-в. На странице Результаты параметров TS CAP проверяем выбранные ранее параметры и завершаем мастер конфигурации.

Теперь настройте политику авторизации ресурсов (Resource Authorization Policy – RAP), определящую доступные для подключения извне серверы и рабочие станции:
Для этого перейдите в меню «Политика авторизации ресурсов» панели Менеджер шлюзов серверов терминалов (удаленных рабочих столов), выберите пункт «Создать новую политику» -> Мастер -> Создать только TS RAP.

Введите имя создаваемой политики. Во вкладке Группы пользователей выберите группы, затрагиваемые создаваемой политикой. На вкладке Группа компьютеров укажите серверы и рабочие станции, к которым применяется политика RAP. В данном примере мы выбрали опцию «Разрешить пользователям подключаться к любому ресурсу (компьютеру) сети» для разрешения подключений ко всем хостам сети. Проверьте параметры TS RAP и завершите мастер конфигурации.

На этом настройку шлюза серверов терминалов (удаленных рабочих столов) можно считать завершенной.

— Защита RDP-сессии с помощью SSL/TLS

Для обеспечения безопасности подключений по RDP в случае, когда соединение с сервером осуществляется не через VPN, рекомендуется использовать SSL/TLS-туннелирование соединения.

Опцию RDP через TLS можно включить через групповую политику безопасности сервера удаленных рабочих столов (команда gpedit.msc или меню «Администрирование» -> «Компоненты Windows» -> Сервер удаленных рабочих столов (Remote Desktop Session» -> «Безопасность»), где необходимо активировать опцию запроса определенного уровня безопасности для удаленных подключений (Require use of specific security layer for remote connections). Рекомендуемое значение этой опций – SSL (TLS 1.0) only.

Также включить вышеуказанную опцию можно и через меню управления сервером удаленных рабочих столов (Remote Desktop Session Host Configuration), выбрав из списка Connections требуемое подключение и перейдя в его свойства, где выбрать уровень безопасности «Security Level». Для TLS-шифрования сессий потребуется, по крайней мере, серверный сертификат. Как правило он уже есть в системе (генерируется автоматически).

Для настройки TLS-туннелирования RDP-подключений откройте инструментов «Управление сервером удаленных рабочих столов (Remote Desktop Session Host Configuration)» через меню «Администрирование» -> Подключения к удаленным рабочим столам».

Выберите в списке подключений то, для которого требуется настроить защиту SSL/TLS и откройте его свойства (Properties). Во вкладке «Общие» (General) выберите требуемый уровень шифрования (Encryption Level). Рекомендуем использовать RDP FIPS140-1 Encryption.

Изолируйте серверные роли и отключайте неиспользуемые сервисы

Одна из основных задач предварительного планирования безопасности серверной инфраструктуры заключается в диверсификации рисков поражения критически важных сегментов инфраструктуры при успешных атаках на отдельные узлы. Чем больше ролей берет на себя каждый узел, тем более привлекательным объектом для атак он становится и тем более серьезные последствия может иметь поражение этого узла. Для минимизации таких рисков необходимо, во-первых, разграничивать критически важные роли серверов на стадии развертывания инфраструктуры (при наличии такой возможности), а во-вторых, отключать на серверах сервисы и роли, в использовании которых нет реальной необходимости.

В идеале, один сервер должен выполнять одну конкретную функцию (Контроллер домена, файловый сервер, терминальный сервер и т.д.). Но так как на практике такая диверсификация ролей редко оказывается возможной в полной мере. Тем не менее, вы можете разграничить функции машин настолько, насколько это возможно.

Для изоляции ролей необязательно использовать выделенные серверы для каждой конкретной задачи. Вы вполне можете использовать для части ролей виртуальные машины, настроив параметры их безопасности требуемым образом. На сегодняшний день технологии виртуализации позволяют не испытывать ощутимых ограничений в функциональности виртуальных хостов и могут предложить высокий уровень производительности и стабильности. Грамотно сконфигурированная виртуальная инфраструктура вполне может являться полноценной альтернативой дорогостоящей «железной» для желающих диверсифицировать риски серьезных поражений.

Мы, команда облачного сервиса 1cloud.ru, со своей стороны не ограничиваем самостоятельное создание клиентом виртуальных машин на арендуемых у нас виртуальных серверах. Если вы желаете установить виртуальную машину Windows на своем сервере, просто обратитесь в нашу техническую поддержку с запросом соответствующей опции.

Обзор Windows Server Core

Windows Server Core представляет собой дистрибутив Windows Server 2008/2012 без предустановленного графического окружения (UI). Этот дистрибутив не использует многие системные сервисы, необходимые для функционирования графического интерфейса и, соответственно, лишен ряда уязвимостей, связанных с работой этих сервисов. Еще одно преимущество Windows Server Core – минимальная нагрузка на аппаратные ресурсы сервера. Это делает ее отличным выбором для установки на виртуальные машины.

К сожалению, на сегодняшний день для Server Core поддерживаются только некоторые функции Windows Server, ввиду чего эту систему еще нельзя назвать полноценной. Возможно, в скором будущем ситуация изменится.