Как защитить rdp windows 10

С распространением 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.

Спасибо за прочтение и уделенное время!

Надеюсь, данный материал был полезен. Будьте бдительны и следите за актуальными уязвимостями, чтобы снизить риски атак на вашу корпоративную инфраструктуру. Благодарю за прочтение!

Возникла идея написать простой PowerShell скрипт для автоматической блокировки в брандмауэре Windows IP адресов, с которых фиксируются попытки подбора паролей через RDP (или длительные RDP атаки). Идея заключается в следующем: скрипт PowerShell анализирует журнал событий системы, и, если с конкретного IP адреса за последние 2 часа зафиксировано более 5 неудачных попыток авторизации через RDP, такой IP адрес автоматически добавляется в блокирующее правило встроенного брандмауэра Windows.

Итак, имеется небольшая сеть с доменом, для доступа внутрь на один из компьютеров на интернет-шлюзе с Linux через NAT проброшен RDP порт (снаружи отвечает порт TCP 13211, а внутрь перенаправляется стандартный 3389). Периодически на компьютере происходит блокировка известных учетных записей доменной политикой паролей из-за неудачных попыток авторизоваться на компьютере через RDP. Наша задача автоматически блокировать IP адреса, через которых идет подбор паролей в RDP .

Сначала создадим на компьютере правило брандмауэра, которое блокирует входящее RDP подключение с указанных IP адресов:

New-NetFirewallRule -DisplayName "BlockRDPBruteForce" –RemoteAddress 1.1.1.1 -Direction Inbound -Protocol TCP –LocalPort 3389 -Action Block

В дальнейшем в это правило мы будем добавлять IP адреса, с которых фиксируется попытки подбора паролей по RDP.

Можно сделать дополнительное разрешающее правило, чтобы скрипт не блокировал нужные IP адреса или подсети.

Теперь нужно собрать из журналов компьютера список IP адресов, с которых за последние 2 часа фиксировалось более 5 неудачных попыток авторизации. Для этого в журнале Security нужно выбрать события с EventID 4625 (неудачный вход — An account failed to log on и LogonType = 3, см. статью Анализ RDP логов в Windows). В найденных событиях нужно найти IP адрес подключающегося пользователя и проверить, что этот IP адрес встречался в логах более 5 раз.

Я использую такой код для выбора IP адресов атакующих из событий за последние 2 часа (можете изменить время):

$Last_n_Hours = [DateTime]::Now.AddHours(-2)
$badRDPlogons = Get-EventLog -LogName 'Security' -after $Last_n_Hours -InstanceId 4625 | ?{$_.Message -match 'logon type:\s+(3)\s'} | Select-Object @{n='IpAddress';e={$_.ReplacementStrings[-2]} }
$getip = $badRDPlogons | group-object -property IpAddress | where {$_.Count -gt 5} | Select -property Name

Можете вывести список найденных адресов IP: $getip

Теперь все обнаруженные IP адреса атакующего нужно добавить в правило брандмауэра BlockRDPBruteForce, которое мы создали ранее. Для управления брандмауэром Windows мы будем использовать встроенный модуль встроенный PowerShell модуль NetSecurity. Сначала получим список текущих заблокированных IP адресов и добавим к нему новые.



$log = "C:\ps\blocked_ip.txt"
$current_ips = (Get-NetFirewallRule -DisplayName "BlockRDPBruteForce" | Get-NetFirewallAddressFilter ).RemoteAddress
foreach ($ip in $getip)
{
$current_ips += $ip.name
(Get-Date).ToString() + ' ' + $ip.name + ' IP заблокирован за ' + ($badRDPlogons | where {$_.IpAddress -eq $ip.name}).count + ' попыток за 2 часа'>> $log # запись события блокировки IP адреса в лог файл
}
Set-NetFirewallRule -DisplayName "BlockRDPBruteForce" -RemoteAddress $current_ips


Проверяем, что в блокирующее правило Windows Defender Firewall добавились новые IP адреса.

Вам осталось скопировать данный PowerShell код в файл c:\ps\block_rdp_attack.ps1 и добавить его в задание планировщика, для запуска по расписанию. Например, каждые 2 часа.

Вы можете создать задание планировщика с помощью PowerShell скрипта или вручную:

$repeat = (New-TimeSpan -Hours 2)
$duration = ([timeSpan]::maxvalue)
$Trigger= New-ScheduledTaskTrigger -Once -At (Get-Date).Date -RepetitionInterval $repeat -RepetitionDuration $duration
$User= "NT AUTHORITY\SYSTEM"
$Action= New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "C:\PS\block_rdp_attack.ps1"


Register-ScheduledTask -TaskName "BlockRDPBruteForce_PS" -Trigger $Trigger -User $User -Action $Action -RunLevel Highest –Force

Либо вы можете запускать скрипт PowerShell при появлении события 4625 в журнале, таким образом вы будете более быстро реагировать на атаку подбора пароля по RDP.

Вы можете модифицировать данный скрипт под свои реалии и использовть для блокировки 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 и т.д.

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

Обновите программное обеспечение

Одним из преимуществ использования удаленного рабочего стола по сравнению с сторонними инструментами удаленного администрирования является то, что компоненты автоматически обновляются с использованием последних исправлений безопасности в стандартном цикле исправлений 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 по адресу и вместо этого добавьте техническую группу.

1. Нажмите Пуск -> Программы -> Администрирование -> Локальная политика безопасности.
2. В разделе «Локальные политики» -> «Назначение прав пользователя» перейдите к «Разрешить вход через службы терминалов». Или «Разрешить вход через службы удаленных рабочих столов»
3. Удалите группу администраторов и выйдите из группы пользователей удаленного рабочего стола.
4. Используйте панель управления системой, чтобы добавить пользователей в группу «Пользователи удаленного рабочего стола».

Типичная операционная система MS будет иметь следующие настройки по умолчанию, как показано в локальной политике безопасности:

Проблема в том, что «Администраторы» здесь по умолчанию, а учетная запись «Локальный администратор» находится у администраторов.

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

Установите политику блокировки учетной записи

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

1. Зайдите в Пуск -> Программы -> Администрирование -> Локальная политика безопасности.
2. В разделе «Политики учетных записей» -> «Политики блокировки учетных записей» установите значения для всех трех параметров. Разумным выбором являются три недопустимые попытки с длительностью блокировки 3 минуты.

Лучшие методы для дополнительной безопасности RDP

Не разрешайте прямой доступ RDP клиентам серверам за пределами своей сетии

Открытие RDP (порт 3389) для сетей за пределами частной сети крайне не рекомендуется и является известным вектором для многих атак. Варианты ниже перечислены способы повышения безопасности, сохраняя при этом доступ к системе по протоколу RDP.

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

Используйте шлюзы RDP

Настоятельно рекомендуется использовать шлюз RDP. Он позволяет жестко ограничить доступ к портам удаленного рабочего стола, одновременно поддерживая удаленные подключения через один сервер-шлюз.

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

1. Используйте службу шлюза RDP в компании. Это лучший вариант для разрешения доступа RDP к системе, относящейся к категории UC P2 и ниже. Включает интеграцию DUO. Служба шлюза RDP предоставляется командой Windows.
2. Служба выделенного шлюза. Требуется для RDP-доступа к системам UC P4 или выше. Также должен быть настроен для DUO.

Некоторые компании используют VPS, управляемый IST, в качестве шлюза удаленных рабочих столов. По приблизительной оценке, 30–100 одновременно работающих пользователей могут использовать один шлюз удаленных рабочих столов. Hа на виртуальном уровне обеспечивает достаточно отказоустойчивый и надежный доступ; однако можно реализовать чуть более сложную реализацию шлюза удаленных рабочих столов с балансировкой сетевой нагрузки.

По сути, все, что необходимо — это простое изменение на расширенной вкладке RDP-клиента:

Измените порт для удаленного рабочего стола

Изменение порта прослушивания поможет «спрятать» удаленный рабочий стол от злоумышленников, которые сканируют сеть в поисках компьютеров, прослушивающих порт удаленного рабочего стола по умолчанию (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-туннелирование для подключений к удаленному рабочему столу.

С 2020 года, после начала пандемии и массовым «переездом» на удаленку, участились случаи взлома серверов через RDP. И вот, случилось то, с чем надеется никогда не встретиться любой системный администратор. Взломали Сервер через RDP и зашифровали все данные. Сразу оговорюсь, что речь идёт именно о взломе через MS RDP (удаленный рабочий стол). Здесь не будем даже упоминать о ситуациях, когда пользователь запускает «суперсрочное и мегаважное письмо из налоговой», которое пришло на почту от неизвестного отправителя или попало на компьютер каким-либо другим способом. Почему это произошло и как обезопасить себя от этого? Несколько действенных рекомендаций ниже.

Простые правила, которые могут помочь, если RDP смотрит прямо в Интернет:

• нестандартный порт для RDP больше не помогает (раньше этого было практически достаточно, но сегодня это задерживает злоумышленника менее, чем на минуту)
  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp PortNumber. После изменения стандартного RDP порта не забываем открыть новый порт в Фаерволе/Брандмауэре;
• никаких стандартных имен пользователей (администратор/administrator, admin, manager, buh, glavbuh и т.д.). Хорошо подойдёт связка NameLastname для пользователя и что-то сгенерированное генератором случайных символов и чисел для админа;
• стандартную учетную запись администратора блокируем и отключаем;
• пароль — обязательно генератором с использованием строчных и прописных символов, цифр и специальных символов. Длина пароля — от 16 символов;
• блокировка учетной записи при вводе неправильного пароля на 10+ минут:
  secpol.msc -> Политики учетных записей -> Политика блокировки учетной записи -> Пороговое значение блокировки (3-5 неправильных вводом пароля — достаточно).

Всё вышеперечисленное не является панацеей. Но, вышеперечисленные действия если не остановят, то задержат злоумышленника надолго.

Зачем нужен нестандартный порт

Скрипт, написанный за 1 минуту школьником может начать сканировать пул ip адресов на наличие открытого стандартного порта 3389. В случае нахождения этого открытого порта — на вас будет открыта охота.

Раньше, изменения порта, было в принципе достаточно. Но, сегодня, это не особенно помогает: скрипт, написанный за 10 минут студентом будет сканировать все порты в пуле ip адресов. И абсолютно точно укажет, какой из портов является портом для RDP.

Вывод. Смена RDP порта задержит только самого начинающего «хакера».

Как поменять порт?
win+r -> regedit

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Нужно изменить десятичное значение параметра PortNumber

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

*Чтобы подключиться через новый порт, следует указать его в строке подключения после двоеточия:
192.168.1.24:12345

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

Если злоумышленник добрался до открытого RDP порта на Вашем выделенном ip адресе, дальше дело техники. Первым делом злоумышленник получает информацию о системе и … пробует войти под учетной записью Администратор или Administrator. Если имя учетной записи присутствует — сервер уведомляет злоумышленника о том, что пароль введен неверно. Дальше простой брутфорс или перебор стандартных паролей по словарю позволит вымогателю войти в систему с привилегированными правами в систему и делать в ней, всё что угодно (как правило просто шифруются все данные и готово).

Почему это кажется простым? Смотри ниже.

Про пароли

Считается, что пароль, состоящий из 16 символов, включающий в себя Заглавные и строчные буквы, цифры и специальные символы невозможно взломать. Возможно. Но, на это потребуется 92 миллиарда лет (согласно отчёту компании по кибербезопасности Hive Systems за 2022 год).

Не стоит думать, что можно успокоится, просто установив длинный и сложный пароль. Каждые полгода время на подбор пароля уменьшается практически в два раза. Следовательно на момент написания данной статьи, пароль из 16 символов подбирается не за 92, а уже за 11.5 миллиардов лет. С развитием технологий, увеличением компьютерных мощностей, с появлением возможности использования мощностей видеокарт, ферм видеокарт и появлением майнинговых мощностей, вполне реально такие пароли через пару лет могут взламываться за пару часов.

А если ваш сервер смотрит портом RDP прямо в Интернет и работает круглосуточно, у злоумышленника есть это время.

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

Блокировка учетной записи в случае неправильного ввода пароля

Странно, что эта опция отключена по умолчанию в семействе операционных систем Windows. Простым перебором паролей можно вломиться в ОС. Поэтому отключаем.

Win+R -> secpol.msc

Локальная политика безопасности -> Политики учетных записей -> Политика блокировки учетной записи -> Пороговое значение блокировки (рекомендую установить 3-8 ошибок входа).

Теперь, в случае пятикратного неправильного ввода пароля, учетная запись будет заблокирована на 10 минут.

Что нам это даёт?

• за час злоумышленник сможет перебрать только 5*6 = примерно 30 паролей. И это при условии, что злоумышленник уже знает ваш порт RDP и имя вашей учетной записи. На подбор сложного пароля в такой ситуации нужно примерно несколько вечностей;
• в случае, если вы входите в свою учетную запись, а она почему-то заблокирована — у вас есть тревожный звоночек о том, что кто-то пытается Вас взломать. Значит пора бы предпринять дополнительные меры по защите вашего сервера.

Что следует обязательно учесть

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

Резюме

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

Есть значительно более действенные методы, которые помогут обезопасить ваши серверы. Один из наиболее действенных и простых — использование VPN. Но это уже история для отдельной статьи.

Используйте сложные пароли!

Только в случае крайней необходимости открывайте порту RDP доступ напрямую в Интернет.

Не забывайте про резервные копии!!!