С распространением COVID-19 организации перевели сотрудников на удаленный режим работы, что напрямую повлияло на кибербезопасность организаций и привело к изменению вектора угроз.
В 2020 году увеличилось использование сторонних сервисов для обмена данными, работа сотрудников на домашних компьютерах в потенциально незащищенных сетях Wi-Fi. Увеличилось количество людей, использующих инструменты удаленного доступа. Это стало одной из главных проблем для сотрудников ИБ.
Одним из наиболее популярных протоколов прикладного уровня, позволяющим получать удаленный доступ к рабочей станции или серверу под управлением ОС Windows, является проприетарный протокол Microsoft — RDP (англ. Remote Desktop Protocol — Протокол удаленного рабочего стола). Во время карантина в сети Интернет появилось большое количество компьютеров и серверов, к которым можно подключиться удаленно. Наблюдался рост активности злоумышленников, которые хотели воспользоваться текущим положением вещей и атаковать корпоративные ресурсы, доступные для сотрудников, отправленных на удаленную работу. На рисунке 1 представлена статистика атак на RDP. По графику видно, что количество атак на RDP значительно увеличилось с начала пандемии.
Таким образом, протокол RDP становится всё более востребованным в том числе и для злоумышленников. В данной статье описаны основные виды атак на RDP, уязвимости и способы их эксплуатации, а также предложены некоторые рекомендации по повышению уровня защищенности RDP.
1. Предварительный сбор информации о RDP
В этом разделе рассмотрены инструменты и методы, которые связаны с поиском и проверкой защищённости удаленных рабочих столов, работу которых обеспечивает служба RDP.
По умолчанию RDP сервер прослушивает TCP-порт 3389 и UDP-порт 3389, поэтому компьютеры с включённым удалённым рабочим столом можно искать с помощью утилиты Nmap командой вида:
sudo nmap – p 3398 -sU -sS СЕТЬ
Например, на рисунке 2 продемонстрирован результат работы команды nmap:
sudo nmap –p 3389 -sU -sS –open 192.168.0.0/24
Для сбора баннеров достаточно добавить опции -sV --script=banner
sudo nmap -p 3389 -sU -sS -sV --script=banner 192.168.0.0/24
1.1 Сбор дополнительной информации о RDP
У Nmap также имеется перечень скриптов для сбора дополнительной информации о RDP:
sudo nmap -p 3389 -sU -sS --script rdp-enum-encryption, rdp-ntlm-info, rdp-vuln-ms12-020 192.168.0.1
Ниже описан каждый из них отдельно:
1.1.1 rdp-enum-encryption
Определяет, какой уровень безопасности и уровень шифрования поддерживаются службой RDP. Это происходит путём циклического перебора существующих протоколов и шифров. При запуске в режиме отладки сценарий также возвращает отказавшие протоколы и шифры, а также обнаруженные ошибки.
Этот скрипт перечисляет информацию от удалённых служб RDP с включённой аутентификацией CredSSP (NLA).
1.1.3 rdp-vuln-ms12-020
Проверяет, является ли машина уязвимой для уязвимости MS12-020 RDP.
Также доступность RDP проверяется модулем Metasploitauxiliary(scanner/rdp/rdp_scanner), пример использования Metasploit для проверки доступности RDP приведен на рисунке 4
1.1.4 rdp-sec-check
Утилита rdp-sec-check используется для получения характеристик настроек безопасности службы RDP
Пример запуска: rdp-sec-check
Вывод команды продемонстрирован на рисунке 5
Результат после строки [+] Summary of security issues (перечень проблем безопасности) говорит о том, что не используется NLA (англ. Network Level Authentication — Аутентификация на уровне сети), следовательно, возможна атака DoS (англ. Denial [ЗДС1] [ЛОВ2] of Service – отказ в обслуживании). Далее сказано, что SSL поддерживается, но не является обязательным, потенциально это может привести к атаке MiTM (англ. Man in the Middle – атака «человек по середине»).
Помимо приведенных выше способов доступность службы RDP проверяется обычными утилитами:
в Windows: mstsc
в Linux: freerdp:
xfreerdp /f /u:ИМЯ-ПОЛЬЗОВАТЕЛЯ /p:ПАРОЛЬ /v:ХОСТ[:ПОРТ]
Далее перейдем с основным видам атак на RDP и уязвимостям.
2 Виды атак на RDP
2.1 BruteForce RDP
По статистике основным способом получения доступа по RDP является слабая парольная политика, поэтому, давайте рассмотрим основные способы перебора данных учетных записей RDP. Удобными являются утилиты ncrack, hydra, patator:
пример использования утилиты hydra:
ncrack -vv --user -P pwds.txt rdp://
пример использования hydra:
hydra -V -f -L -P rdp://
пример использования patator :
patator rdp_login host=192.168.0.101 user=FILE0 password=FILE1 0=user.txt 1=passwords.txt -x ignore:fgrep='ERRCONNECT_LOGON_FAILURE'
Также утилита crowbar может использоваться для осуществления перебора данных учетных записей RDP. Пример использования данной утилиты продемонстрирован на рисунке 6.
./crowbar.py –server -b rdp -u -C
Ниже показан пример перебора учетных записей к RDP с помощью данной утилиты.
Перед проверкой нужно удостовериться, что разрешено удаленное подключение к данному компьютеру. Как показано на рисунке 7 необходимо установить пункт «разрешить удаленные подключения к этому компьютеру» в свойствах системы.
Чтобы снизить возможность перебора данных учетных записей рекомендуется в настройках локальной политики безопасности выставить количество неудачных подключений, после которых будет происходить блокировка учетной записи. Для начала, как показано на рисунке 8, установили пороговое значение равное 3.
В результате, при попытке перебора данных учетных записей доступа к RDP, утилита не показывает каких-либо результатов.
В случае, если же выставлено значение «0», как показано на рисунке 10, то злоумышленник может неограниченно пытаться получать доступ к RDP.
На рисунке 11 продемонстрировано получение данных учетных записей RDP.
Зная данные учетных записей можно осуществить подключение через утилиту xfreerdp, доступную в Kali Linux. Пример на рисунке 12.
После чего получил доступ к удаленной машине.
2.2 MitM атака на RDP с помощью утилиты Seth
С помощью seth выполняется атака MitM, в результате которой извлекаются учётные данные из RDP подключений.
При организации атаки «человек посередине» злоумышленник выдавал себя за правильный режим аутентификации, а пользователь, который не знал о переключении, по незнанию предоставлял правильные учетные данные. Далее рассмотрен пример использования этой утилиты.
Установка зависимостей:
git clone https://github.com/SySS-Research/Seth.git
cd Seth
pip install -r requirements.txt
apt install dsniff
Для проведения атаки злоумышленнику требуется локальный IP-адрес, целевой IP-адрес и сетевой интерфейс, который будет использоваться. В данном случае это eth0. На рисунке 14 продемонстрирован пример запуска утилиты с необходимыми параметрами.
Использование:
/usr/share/seth/seth.sh
Далее после запуска утилиты злоумышленником цель открыла диалоговое окно «Подключение к удаленному рабочему столу» и пыталась подключиться к машине и пользователю по своему выбору. Пользователь запрашивает учетные данные для подключения в качестве исходного запроса проверки подлинности безопасности.
Далее всплывает окно диспетчера сертификатов. На рисунке 16 видно, что существует конфликт между именем сервера и доверенным центром сертификации. Это похоже на окно с запросом на сохранение сертификата. Допускаем, что наша цель нажала «Да» в окне, представленном на рисунке 16.
Как только соединение было установлено, злоумышленник в окне терминала увидел перехваченные данные. На рисунке 17 продемонстрирован захват хэша NTLM, а также пароль, введенный пользователем.
2.3 BlueKeep (CVE-2019-0708)
С 2019 года было обнаружено несколько серьезных RCE (англ. Remote Code Execution – Удаленное Выполнение Кода), связанных с RDP. Их эксплуатация приводит к отказу в обслуживании, а также к удаленному исполнению кода на целевой системе. Уязвимость CVE-2019-0708, получившую название BlueKeep, обнаружили не в самом протоколе RDP, а в реализации службы удаленных рабочих столов. В результате эксплуатации уязвимости неаутентифицированный пользователь может удаленно исполнить произвольный код на целевой системе. Уязвимости подвержены старые версии Windows: начиная с Windows XP (Windows Server 2003) и заканчивая Windows 7 (Windows Server 2008 R2). Для ее успешной эксплуатации необходимы лишь сетевой доступ к компьютеру с уязвимой версией Windows и запущенная служба RDP. Для этого злоумышленник отправляет специально сформированный запрос к службе по RDP для удаленного выполнения произвольного кода на целевой системе. Информация о BlueKeep опубликована в мае 2019 года, но уязвимыми до сих пор остаются достаточное количество RDP-серверов. Уязвимости CVE-2019-1181/1182/1222/1226 практически аналогичны BlueKeep. Однако если предыдущей уязвимости были подвержены лишь старые версии Windows, то теперь под угрозой оказались и все новые версии ОС. Для эксплуатации уязвимостей злоумышленнику также достаточно отправить специально сформированный запрос к службе удаленных рабочих столов целевых систем, используя протокол RDP, что позволит выполнить произвольный код. Эти уязвимости опубликованы в августе 2019 года.
Пример эксплуатации и проверки с помощью модуля metasploit:
auxiliary(scanner/rdp/cve_2019_0708_bluekeep)
CVE-2019-0708 — это уязвимость типа use-after-free драйвера termdd.sys, который используется в Microsoft RDP. Для лучшего понимания, рассмотрим схему образования связи RDP:
Протокол удаленного рабочего стола (RDP) обеспечивает соединение между клиентом и конечной точкой (endpoint прим.), определяя данные, передаваемые между ними в виртуальных каналах. Виртуальные каналы — это двунаправленные каналы данных, расширяющие RDP. Windows Server 2000 определил 32 статических виртуальных канала (SVCs) с RDP 5.1, но из-за ограничений на количество каналов дополнительно определил динамические виртуальные каналы (DVCs), которые содержатся в рамках выделенного SVC. SVC создаются в начале сеанса и остаются до завершения сеанса, в отличие от DVC, которые создаются и удаляются по запросу.
Эту привязку 32 SVC исправляет патч CVE-2019-0708 в функциях _IcaBindVirtualChannels и _IcaRebindVirtualChannels в драйвере RDP termdd.sys. Как видно на рисунке 19, соединения RDP Connection Sequence инициируются, а каналы настраиваются до начала действия безопасности. Блок «RDP security commencement», как видно на схеме, выполняется после инициализации и базовых настройки канала, что позволяет CVE-2019-0708 выполнять функцию червей, поскольку данная уязвимость может самостоятельно распространяться по сети после обнаружения открытого порта 3389.
Уязвимость связана с тем, что имя SVC «MS_T120» привязывается в качестве канала по умолчанию к номеру 31 во время последовательности инициализации конференции GCC протокола RDP. Это имя канала используется корпорацией Microsoft для внутренних целей, и нет очевидных законных вариантов использования клиентом запроса на подключение через SVC с именем «MS_T120».
На рисунке 20 показаны легитимные запросы канала во время последовательности инициализации конференции GCC без канала MS_T120.
Пока конференция GCC инициализируется клиент предоставляет имя канала, которое не занесено сервером в белый список, что означает, что злоумышленник может настроить другой SVC с именем «MS_T120» на канале, отличном от 31. Использование MS_T120 на другом канале приводит к повреждению памяти кучи (англ. Heap Memory Corruption) и RCE.
На рисунке 21 показан аномальный запрос канала во время последовательности инициализации конференции GCC с каналом «MS_T120» на канале номер 4.
Компоненты, участвующие в управлении каналом MS_T120, выделены на рисунке 22. Эталонный канал MS_T120 создается в rdpwsx.dll, а пул кучи выделяется в rdpwp.sys. Повреждение кучи происходит в termdd.sys, когда эталонный канал MS_T120 обрабатывается в контексте индекса канала, отличного от 31.
Исправление Microsoft, показанное на рисунке 23, теперь добавляет проверку запроса на подключение клиента с использованием имени канала «MS_T120» и обеспечивает его привязку только к каналу 31 (1Fh) в функциях _IcaBindVirtualChannels и _IcaRebindVirtualChannels в termdd.sys.
Данная часть материала взята с сайта https://cve-2019-0708.info/understanding-the-wormable-rdp-vulnerability-cve-2019-0708.php
2.3.1 BlueGate
Еще одна уязвимость — BlueGate (CVE-2020-0609/0610) — была найдена в компоненте Windows Remote Desktop Gateway в Windows Server (2012, 2012 R2, 2016 и 2019). Она также позволяет злоумышленникам посредством RDP и специально созданных запросов осуществлять удаленное выполнение кода на целевой системе. BlueGate опубликована в начале 2020 года.
Шлюз удаленных рабочих столов (RDG), ранее известный как шлюз служб терминалов, — это компонент Windows Server, обеспечивающий маршрутизацию для удаленного рабочего стола (RDP). Вместо того, чтобы пользователи подключались напрямую к серверу RDP, пользователи подключаются и аутентифицируются на шлюзе. После успешной аутентификации шлюз будет перенаправлять RDP-трафик на адрес, указанный пользователем, фактически выступая в роли прокси. Идея состоит в том, что только шлюз должен быть открыт для сети Интернет, оставляя RDP-серверы в безопасности за брандмауэром. В связи с тем, что RDP представляет собой гораздо большую поверхность атаки, правильная настройка с использованием RDG может уменьшить поверхность атаки организации.
В обновлении безопасности от января 2020 года Microsoft устранила две уязвимости в RDG. Обе ошибки, CVE-2020-0609 и CVE-2020-0610, позволяют выполнять удаленное выполнение кода до аутентификации.
Для того, чтобы разобраться в технических аспектах уязвимостей начнем с просмотра различий между пропатченой и исходной версиями уязвимой библиотеки DLL.
Была изменена только одна функция. RDG поддерживает три различных протокола: HTTP, HTTPS и UDP. Обновленная функция отвечает за обработку последнего. Для удобства на рисунке 24 рассмотрена функция в виде псевдокода, в котором ненужный код был удален.
Протокол RDG UDP позволяет разбивать большие сообщения на несколько отдельных пакетов UDP. Из-за того, что UDP не требует установления соединения, пакеты могут приходить не по порядку. Работа этой функции заключается в повторной сборке сообщений, гарантируя, что каждая часть находится в правильном месте. Каждый пакет содержит заголовок, содержащий следующие поля:
fragment_id: позиция пакета в последовательности
num_fragments: общее количество пакетов в последовательности
fragment_length: длина данных пакета
Обработчик сообщений использует заголовки пакетов, чтобы гарантировать повторную сборку сообщения в правильном порядке и отсутствие утерянных частей. Однако реализация этой функции содержит некоторые ошибки, которые можно использовать.
CVE-2020-0609
memcpy_s копирует каждый фрагмент по смещению в пределах буфера повторной сборки, который выделяется в куче. Смещение для каждого фрагмента вычисляется путем умножения идентификатора фрагмента на 1000. Однако проверка границ не учитывает смещение. Предположим, что размер буфера равен 1000, и мы отправляем сообщение с двумя фрагментами.
1-й фрагмент (fragment_id=0) имеет длину 1. this->bytes_written равен 0, поэтому проверка границ проходит.
1 байт записывается в буфер по смещению 0, а bytes_written увеличивается на 1. Второй фрагмент (fragment_id=1) имеет длину 998. проверка границ проходит.
998 байт записываются в буфер по смещению 1000 (fragment_id*1000), что приводит к записи 998 байт после конца буфера.
Следует отметить, что пакеты не обязательно отправлять по порядку (помните, это UDP). Таким образом, если первый пакет, который мы отправляем, имеет fragment_id=65535 (максимум), он будет записан со смещением 65535*1000, т.е. полные 65534000 байт после конца буфера. Управляя fragment_id, можно записать до 999 байт в диапазоне от 1 до 65534000 после окончания буфера. Эта уязвимость гораздо более гибкая, чем типичное линейное переполнение кучи. Это позволяет нам контролировать не только размер записываемых данных, но и смещение до места их записи. Благодаря дополнительному контролю легче выполнять более точную запись, избегая ненужного повреждения данных.
CVE-2020-0610
Объект класса поддерживает массив 32-битных целых чисел без знака (по одному для каждого фрагмента). Как только фрагмент получен, соответствующий элемент массива устанавливается с 0 на 1. Как только каждый элемент устанавливается на 1, повторная сборка сообщения завершена, и сообщение может быть обработано. В массиве есть место только для 64 записей, но идентификатор фрагмента может находиться в диапазоне от 0 до 65535. Единственная проверка заключается в том, что fragment_id меньше, чем num_fragments (которое также можно установить равным 65535). Следовательно, установка для fragment_id любого значения от 65 до 65535 позволит нам записать 1 (TRUE) за пределами массива. Хотя возможность установить единственное значение в 1 может показаться неправдоподобным для превращения в RCE, даже самые незначительные изменения могут оказать огромное влияние на поведение программы.
Если по какой-либо причине вы не можете установить патч, все же можно предотвратить использование этих уязвимостей. RDG поддерживает протоколы HTTP, HTTPS и UDP, но уязвимости существуют только в коде, отвечающем за обработку UDP. Простого отключения использования UDP или брандмауэра порта UDP (обычно порта 3391) достаточно для предотвращения эксплуатации. Отключение протокола UDP продемонстрировано на рисунке 27.
2.4 Session Hijacking
Перехват сеанса — это тип атаки, при котором злоумышленник может получить доступ к активному сеансу, который не доступен злоумышленнику напрямую. Чтобы продемонстрировать атаку такого типа, нужно создать сценарий. На рисунке 28 представлен демонстрационный стенд на Windows с включенной службой удаленного рабочего стола и работающей с двумя активными пользователями: raj и aarti. Одним из наиболее важных факторов для выполнения атаки перехвата сеанса является то, что другой сеанс, который мы пытаемся перехватить, должен быть активным.
Пусть мы вошли под пользователем raj, используя учетные данные, которые удалось извлечь на предыдущих этапах проникновения, описанных в разделе 3.2.
Теперь нам нужно снова запустить Mimikatz после входа в систему как пользователь raj. Необходимо перечислить все активные сеансы. Мы используем команду сеансов из модуля ts. На рисунке 30 видим, что существует сеанс 3 для пользователя aarti, который активен.
Использовали команду elevate для повышения уровня из модуля токена, чтобы выдавать текущий токен за NT AuthoritySYSTEM и предоставить возможность подключения к другим сеансам. Вернувшись к выходным данным сеанса, мы увидели, что у пользователя aarti есть сеанс 3. Нам нужно подключиться к этому конкретному сеансу с помощью удаленной команды модуля ts. Пример подключения продемонстрирован на рисунке 31.
Как видно на рисунке 32, удалось получить сеанс удаленного рабочего стола для пользователя aarti, имея изначально доступ к пользователю raj. Таким образом session hijacking успешно реализована в службе удаленного доступа RDP.
3 Рекомендации по повышению уровня защищенности RDP
Около 80% взломов связано не с уязвимостями протокола RDP, а с ненадежными паролями. Поэтому в компаниях должна быть принята и закреплена в инфраструктуре политика использования сложных для подбора паролей и обязательной двухфакторной аутентификацией. Пароли пользователям желательно хранить в специальных защищенных менеджерах паролей. Решения по безопасности также должны быть дополнительно защищены паролем, чтобы нельзя было их отключить изнутри при атаке.
3.1 Журналы событий в Windows
Прежде чем переходить к смягчению последствий атак на RDP, нам сначала нужно уметь обнаружить следы атаки. Как и все службы в Windows, удаленный рабочий стол также создает различные журналы, содержащие информацию о пользователях, которые вошли в систему, или время, когда они вошли в систему и вышли из нее, с указанием имени устройства и, в некоторых случаях, IP-адреса подключающегося пользователя.
Существуют различные типы журналов, касающихся службы удаленного рабочего стола. Например: журналы аутентификации, входа в систему, выхода из системы, подключения сеансов. При подключении к клиенту аутентификация может быть успешной или неудачной. Для этих случаев есть различные EventID для распознавания. Журналы аутентификации находятся внутри раздела безопасности. Рассмотрим некоторые из них:
EventID 4624: процесс аутентификации прошел успешно
EventID 4625: процесс аутентификации завершился сбоем
Есть события Logon и Logoff. Вход в систему произойдет после успешной аутентификации. Logoff будет отслеживать, когда пользователь был отключен от системы. Эти конкретные журналы будут расположены по следующему адресу:
Applications and Services Logs > Microsoft > Windows > TerminalServices-LocalSessionManager > Operational.
Event ID 21: Remote Desktop Logon
Event ID 23: Remote Desktop Logoff
Наконец, есть журналы подключения к сеансу. В этой категории больше всего событий, потому что существуют разные причины отключения, и пользователю должно быть понятно на основе конкретного идентификатора события. Эти журналы расположены по следующему адресу:
Applications and Services Logs > Microsoft > Windows > TerminalServices-LocalSessionManager > Operational.
EventID 24: сеанс удаленного рабочего стола отключен
EventID 25: сеанс удаленного рабочего стола переподключен
3.2 Установка ограничения времени активного сеанса
Для смягчения последствий мы также можем установить определенное ограничение по времени для отключенных сеансов, бездействующих служб удаленного рабочего стола, которые могут забивать использование памяти, и других. Эти политики можно найти по адресу:
Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits.
3.3 Network Level Authentication
NLA обеспечивает более надежную защиту от подмены ключей, требуя аутентификацию до установления сессии и во время сессии. В последние годы именно NLA затрудняла эксплуатацию серьезных уязвимостей в протоколе.
3.4 Ряд других полезных практик:
-
Если RDP не используется, то выключите его и отключите на брандмауэре сети внешние соединения с локальными машинами на порту 3389 (TCP/UDP) или любом другом порту RDP.
-
Использовать VPN (англ. Virtual Private Network – виртуальная частная сеть).
-
Используйте нестандартные ключи, например, PKI (Public Key Infrastructure), а соединения RDP стройте с помощью TLS (Transport Layer Security).
-
Постоянно обновляйте все ПО на устройствах сотрудников до актуальных версий. Помните, что 80-90% эксплойтов создано после выхода патча на уязвимость. Узнав, что была уязвимость, атакующие ищут ее именно в старых версиях софта. Это является хорошей практикой корпоративной ИТ-политики. Кроме того, любые незащищенные или устаревшие компьютеры нужно изолировать.
-
По возможности используйте шифрование на устройствах, которые используются для решения рабочих задач (например, шифрование диска).
-
Сделайте резервные копии ключевых данных. Резервные копии должны быть доступны только администратору или пользователю резервного копирования. Права на папки к файлам резервного копирования также должны быть максимально ограничены.
-
Блокировать учетные записи с пустым паролем.
-
Использовать двухфакторную аутентификацию.
-
Настроить политику блокировки при неудачных попытках ввода пароля. Рекомендуется установить значение блокировки равное 3.
-
Ограничить кол-во пользователей, которые могут войти в систему с помощью RDP.
Спасибо за прочтение и уделенное время!
Надеюсь, данный материал был полезен. Будьте бдительны и следите за актуальными уязвимостями, чтобы снизить риски атак на вашу корпоративную инфраструктуру. Благодарю за прочтение!
Часто возникает вопрос – насколько безопасно подключаться через удаленный рабочий стол Windows?
Сеансы удаленного рабочего стола работаю по зашифрованному каналу, не позволяя никому просматривать сеанс путем прослушивания в сети. Однако, есть уязвимость в методе, используемом для шифрования сеансов в более ранних версиях RDP. Эта уязвимость может позволить неавторизованный доступ к вашему сеансу с помощью “Man-in-the-middle attack”.
Удаленный рабочий стол можно защитить с помощью SSL/TLS в Windows Vista, Windows 7, Windows 8, Windows 10 и Windows Server 2003/2008/2012/2016.
Хотя, удаленный рабочий стол более безопасен, чем инструменты удаленного администрирования, такие как VNC, которые не шифруют весь сеанс, каждый раз, когда доступ администратора к системе предоставляется удаленно, возникает риск. Следующие советы помогут защитить удаленный доступ к рабочим столам и серверам, которые вы поддерживаете.
Основные советы по безопасности для удаленного рабочего стола
Используйте надежные пароли
Надежные пароли для любых учетных записей с доступом к удаленному рабочему столу следует рассматривать как обязательный шаг перед включением удаленного рабочего стола.
Парольные фразы должны:
- Содержать восемь символов или более
- Содержать символы из двух из следующих трех классов символов
- По алфавиту (пример: az, AZ)
- Числовой (пример: 0-9)
- Пунктуация и другие символы (пример: ,! @ # $% ^ & * () _ + | ~ – = `{} []:”; ‘<>?,. /)
Парольные фразу не должны:
- Производное от имени пользователя
- Слово, найденное в словаре (русском или иностранном)
- Слово из словаря, написанное задом наперед
- Словарное слово, перед котором или за которым следует любой другой одиночный символ (пример: password1, 1password)
Не используйте легко угадываемые пароли. Некоторые примеры паролей, которые легко угадать:
- Имена членов семьи, домашних животных, друзей и т.д.
- Компьютерные термины и названия, команды, сайты, компании, оборудование, программное обеспечение.
- Дни рождения и другая личная информация, такая как адреса и номера телефонов.
- Шаблоны слов и чисел, такие как aaabbb, qwerty, 123321 и т.д.
- Пароли никогда не следует записывать или хранить в сети.
- Следует регулярно менять пароли, не реже одного раза в шесть месяцев. Также следует менять свой пароль каждый раз, когда вы подозреваете, что учетная запись была взломана.
- Попробуйте использовать разные пароли для каждой системы, как минимум, не используйте тот же пароль для любой из ваших учетных записей.
Обновите программное обеспечение
Одним из преимуществ использования удаленного рабочего стола по сравнению с сторонними инструментами удаленного администрирования является то, что компоненты автоматически обновляются с использованием последних исправлений безопасности в стандартном цикле исправлений Microsoft.
- Убедитесь, что используете последние версии клиентского и серверного программного обеспечения, включив и проверив автоматические обновления Microsoft.
- Если используете клиенты удаленного рабочего стола на других платформах, убедитесь, что они все еще поддерживаются и установлены последние версии.
- Более старые версии могут не поддерживать высокий уровень шифрования и могут иметь другие недостатки безопасности.
Ограничьте доступ с помощью брандмауэров
- Используйте брандмауэры, чтобы ограничить доступ к портам удаленного рабочего стола (по умолчанию TCP 3389). Использование шлюза RDP настоятельно рекомендуется для ограничения доступа RDP к рабочим столам и серверам.
- В качестве альтернативы для поддержки подключения за пределами локальный сети можно использовать VPN подключение, чтобы получить IP-адрес виртуальной сети и добавить пул сетевого адреса в правило исключения брандмауэра RDP.
Включите аутентификацию на сетевом уровне
Windows 10, Windows Server 2012 R2/2016/2019 также по умолчанию предоставляют проверку подлинности на уровне сети (NLA). Лучше оставить это на месте, так как NLA обеспечивает дополнительный уровень аутентификации перед установкой соединения. Вы должны настраивать серверы удаленного рабочего стола только для разрешения подключений без NLA, если вы используете клиенты удаленного рабочего стола на других платформах, которые его не поддерживают.
- NLA должен быть включен по умолчанию в Windows 10, Windows Server 2012 R2 / 2016/2019.
- Чтобы проверить это, вы можете посмотреть параметр групповой политики Требовать проверку подлинности пользователя для удаленных подключений с помощью проверки подлинности на уровне сети, находящейся в папке Компьютер Политики Компоненты Windows Службы удаленного рабочего стола Узел сеанса удаленного рабочего стола Безопасность. Этот параметр групповой политики должен быть включен на сервере с ролью узла сеансов удаленного рабочего стола.
Ограничьте количество пользователей, которые могут войти в систему с помощью удаленного рабочего стола
По умолчанию все администраторы могут войти в удаленный рабочий стол.
Если есть несколько учетных записей администратора на компьютере, следует ограничить удаленный доступ только для тех учетных записей, которые в нем нуждаются.
Если удаленный рабочий стол не используется для системного администрирования, удалите весь административный доступ через RDP и разрешите только учетные записи пользователей, требующие службы RDP. Для отделов, которые управляют множеством машин удаленно, удалите локальную учетную запись администратора из доступа RDP по адресу и вместо этого добавьте техническую группу.
- Нажмите Пуск -> Программы -> Администрирование -> Локальная политика безопасности.
- В разделе «Локальные политики» -> «Назначение прав пользователя» перейдите к «Разрешить вход через службы терминалов». Или «Разрешить вход через службы удаленных рабочих столов»
- Удалите группу администраторов и выйдите из группы пользователей удаленного рабочего стола.
- Используйте панель управления системой, чтобы добавить пользователей в группу «Пользователи удаленного рабочего стола».
Типичная операционная система MS будет иметь следующие настройки по умолчанию, как показано в локальной политике безопасности:
Рисунок 1 – Настройка локальной политике безопасности
Проблема в том, что «Администраторы» здесь по умолчанию, а учетная запись «Локальный администратор» находится у администраторов.
Несмотря на то, что рекомендуется использовать соглашение о паролях, чтобы избежать идентичных паролей локального администратора на локальном компьютере и строго контролировать доступ к этим паролям или соглашениям, использование учетной записи локального администратора для удаленной работы на компьютере не позволяет должным образом регистрировать и идентифицировать пользователя, использующего систему. Лучше всего переопределить локальную политику безопасности с помощью параметра групповой политики.
Рисунок 2 – Настройка групповой политики безопасности
Установите политику блокировки учетной записи
Установив на своем компьютере блокировку учетной записи на определенное количество ошибочных попыток, вы предотвратите получение доступа к вашей системе с помощью средств автоматического подбора пароля. Чтобы установить политику блокировки учетной записи:
- Зайдите в Пуск -> Программы -> Администрирование -> Локальная политика безопасности.
- В разделе «Политики учетных записей» -> «Политики блокировки учетных записей» установите значения для всех трех параметров. Разумным выбором являются три недопустимые попытки с длительностью блокировки 3 минуты.
Лучшие методы для дополнительной безопасности RDP
Не разрешайте прямой доступ RDP клиентам серверам за пределами своей сетии
Открытие RDP (порт 3389) для сетей за пределами частной сети крайне не рекомендуется и является известным вектором для многих атак. Варианты ниже перечислены способы повышения безопасности, сохраняя при этом доступ к системе по протоколу RDP.
После настройки шлюза RDP узлы должны быть настроены так, чтобы разрешать RDP-соединения только от узла шлюза или подсетей компании там, где это необходимо.
Используйте шлюзы RDP
Настоятельно рекомендуется использовать шлюз RDP. Он позволяет жестко ограничить доступ к портам удаленного рабочего стола, одновременно поддерживая удаленные подключения через один сервер-шлюз.
При использовании сервера шлюза удаленных рабочих столов все службы удаленных рабочих столов на вашем рабочем столе и рабочих станциях должны быть ограничены, чтобы разрешить доступ только из шлюза удаленных рабочих столов. Сервер шлюза удаленных рабочих столов прослушивает запросы удаленного рабочего стола через HTTPS (порт 443) и подключает клиента к службе удаленного рабочего стола на целевой машине.
- Используйте службу шлюза RDP в компании. Это лучший вариант для разрешения доступа RDP к системе, относящейся к категории UC P2 и ниже. Включает интеграцию DUO. Служба шлюза RDP предоставляется командой Windows.
- Служба выделенного шлюза. Требуется для RDP-доступа к системам UC P4 или выше. Также должен быть настроен для DUO.
Некоторые компании используют VPS, управляемый IST, в качестве шлюза удаленных рабочих столов. По приблизительной оценке, 30–100 одновременно работающих пользователей могут использовать один шлюз удаленных рабочих столов. Hа на виртуальном уровне обеспечивает достаточно отказоустойчивый и надежный доступ; однако можно реализовать чуть более сложную реализацию шлюза удаленных рабочих столов с балансировкой сетевой нагрузки.
По сути, все, что необходимо – это простое изменение на расширенной вкладке RDP-клиента:
Рисунок 3 – Подключение через шлюз удаленных рабочих столов
Измените порт для удаленного рабочего стола
Изменение порта прослушивания поможет «спрятать» удаленный рабочий стол от злоумышленников, которые сканируют сеть в поисках компьютеров, прослушивающих порт удаленного рабочего стола по умолчанию (TCP 3389). Это обеспечивает эффективную защиту от новейших червей RDP, таких как Morto.
Для этого отредактируйте следующий раздел реестра (ВНИМАНИЕ: не пытайтесь это сделать, если вы не знакомы с реестром Windows и TCP / IP): HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Control Terminal Server WinStations RDP-Tcp.
Измените порт прослушивания с 3389 на другой и не забудьте обновить все правила брандмауэра с новым портом. Хотя этот подход полезен, это безопасность посредством неизвестности, что не является самым надежным подходом к обеспечению безопасности.
Убедитесь, что вы также используете другие методы для ограничения доступа, как описано в этой статье.
Туннелируйте подключение к удаленному рабочему столу через IPSec или SSH
Если использование шлюза удаленных рабочих столов невозможно, вы можете добавить дополнительный уровень проверки подлинности и шифрования, туннелируя сеансы удаленного рабочего стола через IPSec или SSH. IPSec встроен во все операционные системы Windows, начиная с Windows 2000, но использование и управление в Windows 10 значительно улучшены . Если доступен SSH-сервер, вы можете использовать SSH-туннелирование для подключений к удаленному рабочему столу.
by | |
Setting up a secure Remote Desktop Protocol (RDP) for a Windows 10 machine is crucial for ensuring that your remote connections are safe from unauthorized access. RDP allows you to connect to another computer over a network connection, making it an essential tool for remote work and IT support. However, if not properly secured, it can become a vulnerability. In this article, we will guide you through the steps to set up a secure RDP for your Windows 10 machine.
What is Remote Desktop Protocol?
Microsoft’s Remote Desktop Protocol (RDP) enables users to access another computer over a network. RDP provides a graphical interface to the user, enabling them to access and control the remote computer as if they were sitting right in front of it.
Why Secure RDP is Important?
Using RDP without proper security measures can expose your system to various threats such as unauthorized access, data breaches, and malware attacks. Securing your RDP ensures that your remote connections are protected, maintaining the integrity and confidentiality of your data.
How to Enable RDP on Windows 10
Before we delve into securing RDP, let’s first enable it on your Windows 10 machine.
- Open Settings: Click on the Start menu and select «Settings.»
- Navigate to System: In the Settings window, click on «System.»
- Remote Desktop: Scroll down and click on «Remote Desktop.»
- Enable Remote Desktop: Toggle the switch to enable Remote Desktop. Confirm your choice if prompted.
Once RDP is enabled, you can start securing it using the following steps.
Steps to Secure RDP on Windows 10
1. Update Your System Regularly
Keeping your Windows 10 system up-to-date ensures that you have the latest security patches and updates. Microsoft frequently releases updates that address security vulnerabilities, so it’s essential to install them promptly.
2. Use Strong Passwords
Ensure that all user accounts with RDP access have strong, complex passwords. A strong password typically includes a mix of uppercase and lowercase letters, numbers, and special characters. Using birthdays or ordinary words as passwords is risky.
3. Enable Network Level Authentication (NLA)
Network Level Authentication (NLA) is a security feature that requires users to authenticate before establishing a remote desktop connection. Enabling NLA adds an extra layer of security to your RDP connections.
To enable NLA:
- Open System Properties: Press Win + R, type sysdm.cpl, and press Enter.
- Remote Tab: Click on the «Remote» tab.
- Require NLA: To require Network Level Authentication, select the option «Allow connections only from computers running Remote Desktop with Network Level Authentication.»
- Apply and OK: Click «Apply» and then «OK» to save the changes.
4. Change the Default RDP Port
By default, RDP uses port 3389. Changing the default port can help reduce the risk of automated attacks targeting this common port.
To change the RDP port:
- Open Registry Editor: Press Win + R, type regedit, and press Enter.
- Navigate to RDP Port Key: Go to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp.
- Modify Port Number: Find the «PortNumber» key, double-click it, select «Decimal,» and enter a new port number.
- To apply the changes, please restart your system.
5. Use a VPN
Using a Virtual Private Network (VPN) adds an extra layer of security by encrypting your internet connection. This ensures that your RDP traffic is secure and not easily intercepted by malicious actors.
6. Enable Two-Factor Authentication (2FA)
Two-Factor Authentication (2FA) requires users to provide two forms of identification before accessing the system. Enabling 2FA for RDP adds an extra layer of security, making it harder for unauthorized users to gain access.
7. Restrict User Access Limit
RDP access to only those who need it. Create a separate user group for RDP users and add only necessary accounts. This minimizes the number of potential entry points for attackers.
8. Use a Firewall
Configure your firewall to allow RDP connections only from specific IP addresses. This ensures that only trusted networks can establish remote desktop connections to your machine.
To configure the Windows Firewall:
- Open Windows Firewall: Press Win + R, type firewall.cpl, and press Enter.
- Advanced Settings: Click on «Advanced settings.
- Select «Inbound Rules» from the options on the left side.
- New Rule: Click on «New Rule» in the right pane.
- Port: Select «Port» and click «Next.»
- Specify Port: Select «TCP» and enter your RDP port number.
- Allow the Connection: Choose «Allow the connection» and click «Next.»
- Specify Profile: Select the network profiles (Domain, Private, Public) where the rule should apply and click «Next.»
- Name the Rule: Give your rule a name and click «Finish.»
9. Monitor RDP Access
Regularly monitor RDP access logs to detect any unusual or unauthorized attempts to access your system. Windows Event Viewer can be used to review these logs.
To access Event Viewer:
- Open Event Viewer: Press Win + R, type eventvwr.msc, and press Enter.
- Navigate to Logs: Expand «Windows Logs» and select «Security.»
- Review Logs: Look for any unusual login attempts or failed login attempts.
10. Disable RDP
When Not in Use If RDP is not needed, disable it. This strengthens security by limiting access points for attackers.
Conclusion
Securing RDP on your Windows 10 machine is essential to protect your system from unauthorized access and potential security threats. By following the steps outlined in this guide, you can ensure that your remote desktop connections are secure. Remember to update your system regularly, use strong passwords, enable NLA, change the default RDP port, use a VPN, enable 2FA, restrict user access, use a firewall, monitor access logs, and disable RDP when not in use. By taking these precautions, you can enjoy the benefits of RDP while keeping your system safe.
For more information on Windows 2019 Remote Desktop Services and other related topics, visit https://www.directdeals.com.
DirectDeals: The Leading Microsoft Partner
Thank You For Embarking On This Enlightening Adventure With Us!
To know the price of any Microsoft products reach out to us at (800) 983-2471 or simply drop us an email at support@directdeals.com. Your satisfaction is our priority, and we’re eager to help you with any further inquiries or assistance you may need.
Explore the DirectDeals online store, where we proudly offer the most competitive prices in the industry. Not only that, but our dedicated technical assistance ensures you receive the best support every step of the way.
Click here to explore our exclusive offers and seize the opportunity to unlock your business’s full potential.
Привет.
Вчера, общаясь с Иваном Никитиным, получил дельный совет осветить работу и настройку протокола RDP. Мысль дельная, дальше – подробнее.
Введение
Протокол RDP – удобное, эффективное и практичное средство для удалённого доступа как для целей администрирования, так и для повседневной работы.
Учитывая, что его реализации есть практически везде (различные платформы и ОС), и их много, нужно хорошо представлять его возможности.
По крайней мере, это будет нужно по ряду причин:
- Зачастую вместо RDP используется другое решение (VNC, Citrix ICA) по простой причине – предполагается, что “встроенный RDP минимальный и ничего не умеет”.
- Во многих решениях, связанных с модными сейчас облачными технологиями (перевод офисов на “тонкие клиенты”, да и просто организация терминальных серверов), бытует мнение что “RDP плохой потому что встроенный”.
- Есть стандартный миф про то, что “RDP нельзя без VPN наружу выставлять, ломанут” (миф имеет под собой обоснование, но уже давно не актуален).
- Ну, раз уж про мифы заговорили – бытует мнение, что “Перейдя с RDP на Citrix трафик в пару раз падает”. Ведь цитрикс – это дорого, следовательно как минимум на 157% круче.
Все эти мифы – ерунда и смесь устаревших “дельных советов”, актуальных во времена NT 4.0, а так же откровенных вымыслов, не имеющих никаких причин к существованию. Так как IT – это точная наука, надо разобраться. Хорошо настроеный протокол RDP новых версий, с учётом всех новых функциональных возможностей, является достаточно хорошим и надёжным инструментом для организации удалённого доступа.
Поэтому мы займёмся:
- Кратким упоминанием про версии RDP
- Настройкой режима защиты RDP-сессии
- Настройкой шифрования для RDP
- Привязкой к конкретному адаптеру и порту
- Меняем стандартный порт на нужный
- Делаем раздельные настройки RDP для нескольких сетевых адаптеров
- Включением NLA
- Как включается NLA со стороны RDP-сервера
- NLA и Windows XP
- Как включить CredSSP в XP
- Выбором правильного сертификата для RDP
- Блокированием подключений по RDP учётным записям с пустым паролем
- Настройка ACL для подключения по RDP
- Оптимизацией скорости RDP
- Отключаем редирект неиспользуемых устройств
- Настраиваем общую логику оптимизации визуальных данных RDP
- Оптимизацией сжатия RDP
- Настраиваем общее сжатие RDP
- Настраиваем сжатие аудиопотока RDP
- Оптимизацией соотношения потоков данных RDP
- Включением Require secure RPC communication для RDP
Приступим.
Версии протокола RDP
Протокол имеет достаточно длительную историю, начиная с NT 4.0. Исторические детали мы оставим в стороне по простой причине – на данный момент имеет смысл говорить только про версию RDP 7.0, которая есть в Windows Vista SP1 / Windows Server 2008 и бесплатно добавляема в Windows XP установкой SP3 и обновлённого клиента RDP (находится по ссылке на KB 969084). Я предполагаю, что у Вас как минимум Windows XP, и что Вы поставили/можете поставить последний Service Pack и не трачу Ваше время на обсуждение преимуществ RDP в Windows 2000 SP2 перед NT 4.0 SP5.
Настройка режима защиты RDP-сессии
В принципе, это самая простая часть задачи. Суть в следующем. В различных версиях RDP применяется два основных механизма защиты сессии – встроенный в RDP и “заворачивание” сессии в TLS. Встроенный является недостаточно безопасным, и рекомендация “RDP можно наружу только в VPN” – про него. Поэтому всегда включайте поддержку TLS. Это тот минимум, с которого Вы должны начать. Ограничениями будут разве что версия сервера не ниже Windows Server 2003 SP1 и клиент RDP 5.2 и выше, но, думается, это в конце 2011 года вполне решаемо.
Как включить RDP over TLS
Вариантов, как всегда, несколько. Первый – включение через групповую политику. Для этого надо зайти в целевой объект групповой политики (ну или локально на своей домашней рабочей станции запустить gpedit.msc) и там последовательно выбрать “Computer Configuration” -> “Administrative Templates” -> “Windows Components” -> “Remote Desktop Session Host” -> “Security” и там включить параметр Require use of specific security layer for remote connections, выбрав в нём SSL (TLS 1.0) only. Можно выбрать и более мягкий Negotiate, но я бы не рекомендовал, т.к. на данный момент это банально ниже приемлемого уровня безопасности. Как человек, создававший private cloud’ы с достаточно высоким уровнем безопасности, я могу сказать, что смысл выносить особо ценные данные в датацентр под Лондоном и ходить туда дефолтным RDP – нулевой и является поиском неприятностей.
Можно и проще – откройте оснастку Remote Desktop Session Host Configuration (найдёте в mmc или готовую в меню Administrative Tools -> Remote Desktop Connections), выберите из списка Connections нужное подключение (обычно оно одно и называется RDP-Tcp), и откройте Properties, после – вкладку General и там выбрать нужный Security Layer.
Для работы TLS необходим цифровой сертификат (как минимум – со стороны сервера). Обычно он уже есть (генерится автоматически), убедитесь в его наличии, про то, как сделать его хорошим, поговорим после. Пока надо, чтобы он просто был, иначе подключиться не получится.
Настраиваем шифрование для RDP
Для конфигурирования будет доступно 4 варианта шифрования. Рассмотрим каждый из них.
Режим RDP Low Encryption
Самый “никакой” режим. Наследие страшных времён и версий RDP 5.x. Может согласовать шифрование на базе 56ти битового DES или 40ка битового RC2, что на текущий момент является несерьёзным. Не нужен и опасен. Например, если включить его, то не включится TLS, т.к. TLS уже откажется согласовывать такие слабые шифры, которые предлагает этот вариант.
Режим RDP Client Compatible Encryption
Второй “никакой” режим. Наследие страшных времён и версий RDP 5.x. Попробует до 128 бит RC4, но сразу согласится на DES/RC2. Не нужен и опасен. Тоже не совместим с TLS.
Режим RDP High Encryption
Минимально допустимый режим. Потребует хотя бы 128ми битовый RC4. Работает со всеми серверами, начиная с Windows 2000 Server w/HEP.
Режим RDP FIPS140-1 Encryption
То, что нужно. Будет поддерживать современные симметричные алгоритмы и в явном виде не будет поддерживать RC2, RC4, одиночный DES, а также будет заставлять использовать для вычисления целостности (Message Authentication Code – MAC) алгоритм SHA-1, а не MD5. Включайте этот вариант всегда, найти сервер, который не умеет 3DES, AES или SHA-1 практически нереально.
Где делается эта настройка? Откройте оснастку Remote Desktop Session Host Configuration (найдёте в mmc или готовую в меню Administrative Tools -> Remote Desktop Connections), выберите из списка Connections нужное подключение (обычно оно одно и называется RDP-Tcp), и откройте Properties, после – вкладку General и там выберите нужный Encryption Level.
Привязываем RDP к конкретному адаптеру и порту
Для того, чтобы сервер работал безопасно и предсказуемо (например, не начинал принимать подключения с нового, свежедобавленного сетевого адаптера), необходимо в явном виде указать, на каких интерфейсах служба RDP-сервера должна принимать подключения. Плюс, достаточно часто бывает полезным переключить порт, на котором сервер слушает подключения. Конечно, можно это сделать и публикуя сервер с RDP через какой-нибудь шлюз, но можно и без этого. Такие, казалось бы, базовые действия в реальности ощутимо снизят процент дураков-скрипткиддисов, которые очередной “мощной тулзой” проверяют wellknown-порты.
Как привязать службу RDP к конкретному сетевому адаптеру или сделать несколько RDP с разными настройками для разных адаптеров
Откройте оснастку Remote Desktop Session Host Configuration (найдёте в mmc или готовую в меню Administrative Tools -> Remote Desktop Connections), выберите из списка Connections нужное подключение (обычно оно одно и называется RDP-Tcp), и откройте Properties, после – вкладку Network Interfaces. В ней Вы сможете выбрать один конкретный интерфейс, на котором надо ожидать подключения, плюс ограничить количество параллельных сессий.
Если у Вас много интерфейсов, и Вам надо, допустим, чтобы можно было подключаться через 2 из 5 доступных, то Вам надо будет привязать существующий по-умолчанию RDP-Tcp к одному адаптеру, после зайти в меню Action и там выбрать Create New Connection. Подключение может слушать либо на всех интерфейсах, либо на одном, и в случае, когда надо, чтобы оно слушало на N интерфейсах, придётся создать N подключений.
Соответственно, если у Вас есть задача “Чтобы на одном интерфейсе RDP слушал на одном порту, а на другом – на другом”, она решаема так же – отвязываете дефолтный RDP-Tcp от всех адаптеров и привязываете к конкретному, после – создаёте новое RDP-подключение и тоже привязываете к нужному сетевому интерфейсу.
Как привязать службу RDP к не-дефолтному порту
Порт по умолчанию – 3389 TCP. Кстати, не забудьте разрешить его в пакетном фильтре. Ну а если хотите другой – надо зайти в ключ реестра
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
и поправить в нём значение PortNumber. Учитывайте, что отслеживание конфликтов в плане занятости портов – на Вашей совести, сам он, обнаружив, что назначенный Вами порт занят, “перепрыгнуть” никуда не сможет.
Включаем NLA – Network Level Authentication
Функция NLA появляется в NT 6.0, а позже добавляется возможность её частичного использования в предыдущей версии ОС путём установки SP3 для XP.
Суть данной функции достаточно проста. В версиях RDP до 6.0 при подключении по RDP клиенту до аутентификации надо показать окно входа – т.е. вначале показать, а потом уже он попробует зайти в систему. Это создаёт простую уязвимость – сервер можно перегрузить пачкой запросов “а дай-ка мне попробовать новую сессию начать”, и он будет вынужден на все запросы отвечать созданием сессии и ожиданием входа пользователя. Фактически, это возможность DoS. Как с этим можно бороться? Логично, что надо придумать схему, целью которой будет как можно раньше запросить у клиента учётные данные. Оптимально – чтобы было что-то типа как kerberos в домене. Это и было сделано. NLA решает две задачи:
- Клиент аутентифицируется до инициации терминальной сессии.
- Появляется возможность передать данные локального клиентского SSP на сервер, т.е. начинает работать Single Sign-On.
Реализуется это через новый провайдер безопасности – CredSSP. Почитать его техническую спецификацию можно тут, ну, а говоря проще, надо всегда включать данную функцию. Конечно, учитывая, что для её работы нужно, чтобы:
- Клиентская ОС (та, с которой идёт подключение) была Windows XP SP3 и выше.
- Серверная ОС (та, к которой будет подключение) была Windows Server 2008 и выше.
Как включается NLA со стороны RDP-сервера
Лучше всего включить NLA на всех серверах через групповую политику. Для этого надо зайти в целевой объект групповой политики и там последовательно выбрать “Computer Configuration” -> “Administrative Templates” -> “Windows Components” -> “Remote Desktop Session Host” -> “Security” и там включить параметр Require user authentication for remote connections by using Network Layer Authentication.
Можно включить и локально. Это делается путём вызова подменю Properties (стандартное подменю у Computer) и выбора там вкладки Remote, в которой будет выбор из трёх вариантов – запрещать подключения по RDP к данному хосту, разрешать подключения по любому RDP, разрешать только с NLA. Всегда включайте вариант с NLA, это в первую очередь защищает сервер.
NLA и Windows XP
В случае, если у Вас Windows XP, то Вы также можете воспользоваться данной функцией. Распространённое утверждение “Для NLA нужна как минимум виста, это Microsoft сделал чтобы апгрейдились” ложно. В Service Pack 3 добавляется реализация CredSSP, позволяющая делегировать клиентские credentials’ы, которыми обладает местный SSP, на сервер. Т.е., говоря проще, это специально сделано, чтобы с Windows XP можно было подключаться на системы с NT 6.0+. На саму Windows XP SP3 с данной функцией подключаться не получится, поддержка NLA будет частичной (поэтому RDP сервер с поддержкой подключения клиентов с использованием NLA из Windows XP сделать штатными способами не получится, Windows XP будет только NLA-совместимым клиентом).
Включать данный функционал нужно в явном виде, так как несмотря на то, что Service Pack 3 добавляет приносит новую dll криптопровайдера, он её не включает.
Как включить CredSSP в XP
Ещё раз – данная операция проводится строго после установки Service Pack 3 на Windows XP и в контексте нашего разговора нужна для того, чтобы было возможно подключение к другим серверам по RDP 6.1 с использованием NLA.
Шаг первый – расширяем перечень Security Packages.
Для этого мы откроем ключ реестра
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
и найдём в нём значение Security Packages. Нажмём правую кнопку и выберем “Modify” (не Modify Binary Data, а просто Modify). Там будет список вида “название package на каждой строке”. Нам надо добавить туда tspkg. Остальное надо оставить. Место добавления некритично.
Второй шаг – подцепляем библиотеку.
Ключ будет другим:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders
В нём надо будет найти значение SecurityProviders (заметьте, как и в предыдущем случае, это не subkey, а значение), и модифицировать его по аналогии, только добавив credssp.dll. Остальное в списке, опять же, трогать не надо.
Теперь редактор реестра можно закрыть. После этих операций систему надо будет обязательно перезагрузить, т.к. криптопровайдеры – штука такая, которая на ходу точно не подцепится, и это скорее хорошо, чем плохо.
Выбираем правильный сертификат для RDP
Если у Вас есть возможность пользоваться не-дефолтным сертификатом для RDP, то лучше пользоваться именно им. Это не повлияет на безопасность сессии как таковой, но повлияет на безопасность и удобство подключения. В сертификате, который оптимально использовать, должны быть следующие момент:
- Имя (в subject или SAN), посимвольно совпадающее с тем именем, которое вводит клиент, подключающийся к серверу.
- Нормальное расширение CDP, указывающее на рабочий CRL (желательно хотя бы на два – OCSP и статический).
- Желательный размер ключа – 2048 бит. Можно и больше, но помните об ограничениях CAPI2 в XP/2003.
- Не экспериментируйте с алгоритмами подписи/хэширования, если Вам нужны подключения со стороны XP/2003. Чуть больше информации про это в статье про настройку TLS, но вкратце – выберите SHA-1, этого вполне достаточно.
Чуть подробнее остановлюсь на выпуске специального сертификата для RDP-сервера.
Делаем всё красиво – специальный шаблон сертификата для RDP-серверов
Идеально будет, если сертификат для RDP сделать не на основе обычного шаблона (типа Web Server) и иметь в поле Application Policy (которое в сертификате будет более привычно называться Enchanced Key Usage – EKU) стандартные значения Client Authentication и Server Authentication, а добавить свой шаблон, в котором будет единственное, специальное, не добавляемое стандартными способами значение применения – Remote Desktop Authentication. Это значение Application Policy придётся создать вручную, его OID’ом будет 1.3.6.1.4.1.311.54.1.2, ну а после – уже можно сделать новый шаблон сертификата, на основании которого и выпустить сертификат, адресно “заточеный” под RDP Server.
Чтобы полностью автоматизировать эту операцию, сделайте у нового шаблона предсказуемое название – например, “RDPServerCert” – и зайдите в объект групповой политики, а там откройте Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security. Выберите параметр Server Authentication Certificate Template и включите его, а в поле значения введите название – мы сделали RDPServerCert. Теперь все доменные хосты, подпадающие под эту политику, будут в случае включения на них RDP сами идти к Certification Authority, запрашивать в случае отсутствия себе сертификат на основе указанного шаблона, и автоматически делать его дефолтным для защиты подключений по RDP. Просто, удобно, эффективно.
Блокируем подключения по RDP учётным записям с пустым паролем
Мелочь, а забывать про неё не нужно.
Для блокировки подключения учёток без паролей к RDP надо зайти в настройку объекта групповой политики: Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options и установить “Accounts: Limit local account use of blank passwords to console logon only” в Enabled. Не поленитесь проверить, что это так и есть.
Настройка ACL для подключения по RDP
По умолчанию для подключения к RDP-серверу необходимо иметь явное разрешение User Access или Guest Access.
Это разрешение есть у локальных групп Administrators и Remote Desktop Users. Лучше всего использовать для управления доступом к RDP-серверу группу Remote Desktop Users, добавляя в неё нужные доменные группы, а не отдельных пользователей. Модицифируйте содержимое вкладки Security в настройках Properties у RDP-Tcp только в крайних случаях, лучше всего – добавляя группу “имя хоста RDP Blocked”, которой явно запрещен доступ по RDP к указанному узлу.
Оптимизация скорости RDP
Оптимизация скорости RDP – достаточно обширная тема, поэтому я разделю её на части. В этой будут те способы, которые будут уменьшать нагрузку на протокол до сжатия и до оптимизации сетевого уровня.
Цветность (битовая глубина)
В RDP 7.0 и выше доступны варианты 32,16 и 8 бит. Если речь идёт о работе, то для неё будет достаточно 16 бит. Это ощутимо снизит нагрузку на канал, притом иногда больше, чем в 2 раза, что удивительно, но факт. 8 бит, конечно, тоже можно, но уж больно страшно оно будет выглядеть. 16 бит же вполне приемлемы.
Включите на сервере параметр Limit Maximum Color Depth, либо сделайте аналогичное действие в настройках RDP client.
Отключите ClearType
Когда у Вас выключен ClearType, протокол RDP передаёт не картинку, а команды по отрисовке символов. Когда включен – рендерит картинку со стороны сервера, сжимает и пересылает клиенту. Это с гарантией в разы менее эффективно, поэтому отключение ClearType значительно ускорит процесс работы и уменьшит время отклика. Сами удивитесь, насколько.
Это можно сделать как на уровне настроек клиента, так и на стороне сервера (параметр Do not allow font smoothing в разделе Remote Session Enviroment в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host).
Уберите wallpaper
Параметр Enforce removal of RD Wallpaper в разделе Remote Session Enviroment в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host резко улучшит ситуацию с перерисовкой экрана терминальной сессии. Пользователи без котиков на десктопе выживают нормально, проверено.
Включаем и настраиваем кэширование изображений
Если на клиенте есть достаточно оперативной памяти, то имеет смысл включить и настроить кэширование битмапов. Это позволит выиграть до 20-50% полосы пропускания. Для установки надо будет зайти в ключ
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\
и создать там параметры BitmapPersistCacheSize и BitmapCacheSize, оба типа DWORD 32.
Параметр BitmapPersistCacheSize обозначает размер в килобайтах дискового кэша. Значение по умолчанию – 10. Имеет смысл увеличить этот параметр хотя бы до 1000.
Параметр BitmapCacheSize обозначает размер в килобайтах кэша в RAM. Значение по умолчанию – 1500. Имеет смысл увеличить этот параметр хотя бы до 5000. Это будет всего 5 мегабайт на клиентскую сессию, при современных масштабах оперативной памяти это несущественно, и даже если приведёт к выигрышу 10% производительности, уже себя окупит. Кстати, этот же параметр можно поправить и в .rdp-файле; если сохранить своё RDP-подключение, а после открыть файл блокнотом, то среди параметров можно добавить что-то вида bitmapcachesize:i:5000, где 5000 – это 5МБ кэша.
Отключаем Desktop Composition
Desktop Composition привносит всякие “красивости” типа Aero и его друзей и ощутимо кушает полосу пропускания. Для работы это не нужно и вредно. Параметр Allow desktop composition for RDP Sessions в разделе Remote Session Enviroment в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host необходимо выставить в параметр Disabled.
Оптимизируем параметры Desktop Window Manager
Параметры, находящиеся в разделе Remote Session Enviroment в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Desktop Window Manager, будут управлять “красивым” отображением плавно выезжающих меню и подобного. Их три – Do not allow window animations, Do not allow desktop compositions и Do not allow Flip3D invocation. Все их надо переключить в режим Enabled, т.е. по сути – отключить все эти функции.
Отключаем редирект неиспользуемых устройств
Если у Вас не планируется подключение определённых классов устройств (например, COM и LPT-портов), или аудио, имеет смысл отключить возможность их перенаправления со стороны сервера. Чтобы клиенты с дефолтными настройками RDP Client не тратили время подключения на согласование неиспользуемого функционала. Это делается там же, где и остальные настройки сервера, в Properties у RDP-Tcp, вкладка Client Settings (там же, где мы делали настройки с глубиной цвета), раздел Redirection.
Настраиваем общую логику оптимизации визуальных данных RDP
Параметр, называющийся Optimize visual experience for RDP sessions, находящийся в разделе Remote Session Enviroment в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Remote Session Enviroment, будет управлять тем, как RDP будет воспринимает визуальные данные – как мультимедийные или как текстовые. Это, грубо говоря, “подсказка” алгоритму сжатия, как грамотнее себя вести. Соответственно, для работы надо будет выставить этот параметр в Text, а если хочется много красивых flash-баннеров, HTML5 и просматривать видеоклипы – лучше вариант Rich Multimedia.
Оптимизация сжатия RDP
Сжатие в RDP прошло долгий путь развития. По RDP 5.2 включительно была подсистема сжатия (“компрессор”), имеющий внутреннее название “Version 1” – самый простой и лёгкий вариант с точки зрения загрузки процессора клиента, но самый плохой с точки зрения нагрузки сети трафиком. В RDP 6.0 сделали “Version 2”, который был незначительно, но улучшен по параметру эффективности сжатия. Нам интересен “Version 3”, который работает только при подключении к серверам Windows Server 2008 и старше. Он сжимает лучше всех, а затраты процессорного времени с учётом мощностей современных компьютеров несуществены.
Выигрыш при включении V3 может, судя по тестам, достигать 60% и, в общем-то, и без тестов ощутимо заметен на глаз.
Как включить оптимальное сжатие в RDP
Это – клиентская настройка. Откройте в нужном объекте групповой политики Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Remote Session Enviroment, выберите там параметр Set compression algoritm for RDP data, включите его и выберите значение Optimize to use less network bandwidth.
Настройка сжатия звукового потока
RDP 7.0 приносит отличную возможность регулировать качество сжатия входящего звукового потока (т.е. звука, который идёт с сервера на клиента). Это достаточно полезно – например, если идёт работа на терминальном сервере, то кроме всяких служебных звуков вида “пришло сообщение в ICQ” другие особо как не планируются. Нет смысла передавать с сервера несжатый звук CD-качества, если для работы это не нужно. Соответственно, нужно настроить уровень сжатия звукового потока.
Данный параметр будет называться Limit audio playback quality и находиться в разделе Device and Resource Redirection в Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host. Вариантов будет три:
High– звук будет идти без сжатия. Вообще. То есть, он будет подпадать под общее сжатие протокола RDP, но специфическое сжатие звука (с потерей качества) производиться не будет.Medium– сжатие будет адаптироваться под канал так, чтобы не увеличивать задержку при передаче данных.Dynamic– сжатие будет динамически адаптироваться под канал так, чтобы задержка не превышала 150ms.
Выберите подходящий. Как понятно, для офисной работы лучше выбрать Dynamic.
Оптимизация соотношения потоков данных в RDP
Трафик RDP-сессии не является чем-то монолитным. Наоборот, он достаточно чётко разделён на потоки данных перенаправляемых устройств (например, копирования файла с локального хоста на терминальный сервер), аудиопоток, поток команд примитивов отрисовки (RDP старается передавать команды примитивов отрисовки, и передаёт битмапы в крайнем случае), а также потоки устройств ввода (мышка и клавиатура).
На взаимное соотношение этих потоков и логику его (соотношения) вычисления (этакий локальный QoS) можно влиять. Для этого надо со стороны сервера зайти в ключ реестра
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermDD
и создать там для начала (если их там нет) четыре ключа:
- FlowControlDisable
- FlowControlDisplayBandwidth
- FlowControlChannelBandwidth
- FlowControlChargePostCompression
Тип у всех – DWORD 32. Функционал у ключей будет следующим.
Ключ FlowControlDisable будет определять, используется ли приоритезация вообще. Если задать единицу, то приоритезация будет выключена, если нуль – включена. Включите её.
Ключи FlowControlDisplayBandwidth и FlowControlChannelBandwidth будут определять взаимное соотношение двух потоков данных:
- Поток взаимодействия с пользователем (изображение+устройства ввода)
- Прочие данные (блочные устройства, буфер обмена и всё остальное)
Сами значения этих ключей не критичны; критично то, как они соотносятся. То есть, если Вы сделаете FlowControlDisplayBandwidth равным единице, а FlowControlChannelBandwidth – четырём, то соотношение будет 1:4, и на поток взаимодействия с пользователем будет выделяться 20% полосы пропускания, а на остальное – 80%. Если сделаете 15 и 60 – результат будет идентичным, так как соотношение то же самое.
Ключ FlowControlChargePostCompression будет определять, когда считается это соотношение – до сжатия или после. Нуль – это до сжатия, единица – после.
Я рекомендую для использования вида “наш удалённый сервак далеко и к нему все по RDP подключаются и в офисе и 1С работают” ставить соотношение 1:1 и считать его после сжатия. По опыту это может реально помочь в ситуации “печать большого документа с терминального сервера на локальный принтер”. Но это не догма – пробуйте, главный инструмент – знание, как это считается и работает – у Вас уже есть.
Включаем Require secure RPC communication для RDP
Данный параметр действует аналогично настройкам для Secure RPC, которые есть в разделе Security групповой политики и действуют на всю систему, только настраивается проще. Включив этот параметр Вы сделаете обязательным для всех клиентских RPC-запросов шифрование (в зависимости от настроек системы “нижняя планка” шифрования будет разной – RC4/DES или, в случае включения FIPS-140 – 3DES/AES) и использование как минимум NTLMv2 для аутентификации удалённого вызова процедур. Всегда включайте этот параметр. Есть миф про то, что он не работает во внедоменной среде. Это не так, и усиление защиты RPC никому не помешает.
Это – серверная настройка. Откройте в нужном объекте групповой политики Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security, выберите там параметр Require secure RPC communication и включите его.
Заключение
Так как все уже давно вытащили сервера на внешние площадки за бугром, то этот материал является Я надеюсь, что данный материал будет Вам полезен для оптимизации и защиты RDP. Если я что-то пропустил – прошу в комментарии.
Защита RDP-подключения: как обеспечить безопасный удаленный доступ к компьютеру
Основные угрозы при использовании RDP
Несмотря на удобство удаленного рабочего стола, он несет в себе множество рисков:
- Атаки методом перебора паролей (Brute Force) – злоумышленники автоматически подбирают пароли, используя специальные программы.
- Эксплуатация уязвимостей в протоколе RDP – устаревшие версии могут содержать бреши в безопасности.
- Фишинговые атаки – хакеры могут получить учетные данные через поддельные сайты или электронные письма.
- DDoS-атаки – перегрузка сервера может привести к отказу в обслуживании.
Чтобы минимизировать риски, необходимо грамотно подойти к настройке RDP-сервера и использовать специализированные решения для защиты.
Как настроить RDP-подключение для безопасного удаленного доступа
1. Включение двухфакторной аутентификации
Одним из самых надежных методов защиты RDP является двухфакторная защита. Это дополнительный уровень безопасности, который требует ввода кода подтверждения из приложения или SMS.
2. Изменение стандартного порта RDP
По умолчанию RDP использует порт 3389, который легко находят злоумышленники. Изменение порта снижает вероятность атак методом подбора пароля.
3. Ограничение доступа по IP-адресу
Можно настроить RDP так, чтобы доступ к серверу был возможен только с определенных IP-адресов.
4. Использование VPN
Настройка RDP через VPN позволит скрыть сервер от посторонних глаз, обеспечивая дополнительную защиту данных.
5. Отключение учетных записей по умолчанию
Учетная запись Administrator – одна из первых целей злоумышленников. Лучше создать новую учетную запись с уникальным именем.
6. Ограничение количества попыток входа
Настройка удаленного доступа RDP должна включать ограничение попыток входа, что поможет защитить систему от атак методом перебора.
7. Обновление системы и использование антивирусного ПО
Обновление ОС Windows 10 и Windows Server помогает закрыть уязвимости, а антивирусные программы блокируют вредоносное ПО.
Как работает защита RDP с 2GC
Компания 2GC предлагает эффективное решение для защиты RDP-подключения. Продукт основан на технологии Argo Tunnel от Cloudflare, которая обеспечивает защищенное соединение без прямого открытия портов.
Преимущества 2GC:
- Защита RDP-сервера без сложных настроек.
- Автоматическое шифрование трафика для защиты данных.
- Обход DDoS-атак благодаря серверам Cloudflare.
- Удобный интерфейс – подключение осуществляется без командной строки.
- Поддержка SSH, RDP и других протоколов.
Как настроить RDP в Windows 10 через 2GC
Процесс подключения через 2GC упрощен до минимума:
- Установите утилиты Cloudflare на сервер.
- Настройте удаленный рабочий стол RDP в Windows.
- Подключитесь через клиент 2GC.
Итог
Настройка RDP в Windows 10 требует тщательного подхода к безопасности. Использование двухфакторной аутентификации, изменение стандартного порта, настройка доступа по IP и VPN значительно снижают риски.
Однако, если вам нужен простой и надежный инструмент для защиты удаленного подключения, обратите внимание на 2GC – решение, разработанное для малого и среднего бизнеса, обеспечивающее надежную защиту RDP без сложных настроек.
📌 Инвестируйте в надежные технологии и защитите свой бизнес с 2GC!