Настройка RDP (защита от перебора паролей).

Нужна профессиональная помощь в настройке сервера? Есть вопросы? Качественная и надежная IT-помощь по доступным ценам:

Сейчас есть множество безопасных, доступных по цене, простые и удобные решений, которые позволяют организовать VPN для удаленной работы. Например, VPN клиент Pulse Secure, позволяет буквально в два клика, организовать безопасный RDP доступ. Просто запустил — ввел пароль — готово. Либо, создать свой VPN на базе облачных решений.

Итак, небольшая фирма с RDP сервером наружу.

Первый признак работы сканеров – большое количество неудачных событий 4625 ( An account failed to log on ) в которых указаны различные распространенные имена пользователей.

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

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

Как минимум нужно настроить в групповой локальной или доменной политике следующие параметры:

Computer Configuration\Security Settings\Local Policies\Account Policies\Password Policy

Minimum password length = 9

Password must meet complexity requirements = Enabled

Computer Configuration\Security Settings\Local Policies\Account Policies\Account Lockout Policy

Account lockout threshold = 5

Reset account lockout counter after = 30

Account lockout duration = 30

Так же необходимо выставить параметры безопасности на уровне RDP :

Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security

Require secure RPC communication = Enabled

Require use of specific security layer for remote (RDP) connections = SSL

Require user authentication for remote connections by using Network Level Authentication = Enabled

Set client connection encryption level = High

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

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

Признаком данной ситуации станут события 5817 «Netlogon has failed an additional 129 authentication requests in the last 30 minutes. The requests timed out before they could be sent to domain controller \\server.ourdomain.local in domain OURDOMAIN.»

Первый «метод защиты» – изменение стандартного RDP -порта 3389 на нестандартный. Настройки находятся в реестре:

для применения нужен рестарт сервера.

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

Второй шаг, сделать на уровне маршрутизатора блокировку IP если с него создано некое количество сессий за единицу времени (если это возможно на вашем роутере).

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

На линуксе существует утилита fail 2 ban парсящая логи и блокирующая на уровне firewall адреса с которых происходит много неуспешных попыток входа.

Не то чтобы утилита, но вариант решения (это больше концепт идеи, чем рабочий вариант): fail2ban в виде скрипта.
Правда тема старая, решение костыльное (использования IPSec не по назначению). А ещё оно на VBScript :). Но решение вполне рабочее (было по крайней мере) :). Помню что проверял его на сервере и оно работало.

Можно использовать что-то подобное под Windows Server используя Powershell .

# количество неуспешных попыток за единицу времени при которых IP блокируется

# с единицей времени определимся ниже

$ ban _ treshold = 5

# продолжительность блокировки в часах

$ ban _ duration = 24

# инициализируем массивы в которых будут добавляться IP для блокировки

В нашем случае с параметром групповой политики Require use of specific security layer for remote ( RDP ) connections = SSL и включенным NLA события 4625 не будут содержать IP источника. И для Server 2008, чтобы видеть в событиях 4625 источник перебора прийдется ставить менее защишенный security layer = RDP .

Server 2012 более продвинутый, можно использовать настройки SSL+NLA и при этом ориентироваться на события 140 ( A connection from the client computer with an IP address of xxx.xxx.xxx.xxx failed because the user name or password is not correct. ) в Applications and Services Logs. Не путайте с NTFS событиями 140 ( The system failed to flush data to the transaction log. ) появляющимися в логе System.

$evt140 = Get-WinEvent -ProviderName Microsoft-Windows-RemoteDesktopServices-RdpCoreTS|?

«— Get-WinEvent $ban_date_str» >> $log_file

# группируем события по IP , фильтруем по количеству, определенному в ban _ treshold и записываем в массив

$ip2ban = $evt140.properties.value|Group-Object|?<$_.count -ge $ban_treshold>|select name,count

# пишем в лог IP определенные для блокировки и для информации количество попыток

Самое важное – список IP для блокировки (он у вас должен быть). Теперь нужно очистить лог от событий, чтобы не анализировать их при последующих запусках скрипта и создать правила для firewall .

# проверяем что список IP не пустой

if($ip2ban.count -gt 0)<

get-winevent -ListLog Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational| %

# создаем правило firewall

New-NetFirewallRule -DisplayName «RDP_DYN_BAN_$ban_date_str» -Enabled «True» -Profile Any -Direction Inbound -Action Block -RemoteAddress $ip2ban_str -Protocol TCP

# пишем в лог имя созданного правила

«— New-NetFirewallRule RDP_DYN_BAN_$ban_date_str» >> $log_file

Как только правила начинают накапливаться, чтобы их не стало сильно много, нужно удалять правила, которые старше ban _ duration .

$current_frs = Get-NetFirewallRule -DisplayName RDP_DYN_BAN*

# переводим строковое имя правила в datetime

# если разница в часах больше ban _ duration удаляем правило

if( ((get-date) — $date_frs).totalhours -ge $ban_duration )<

«— Remove-NetFirewallRule -Displayname «+$_.displayname >> $log_file

$_| Remove — NetFirewallRule — Confirm :$ false

Осталось настроить запуск скрипта в планировщике, например, каждый час или 30 минут. Это и будет единицей времени для ban _ treshold определенной нами в скрипте.

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

VPN — единственно правильный вариант защиты от подбора паролей через RDP. Сейчас есть очень простые и удобные VPN клиенты, буквально запустил — ввел пароль — готово. Pulse Secure, является готовым решением для организации VPN без лишних хлопот. Если совсем никак не получается реализовать VPN — ставить блокировку учетной записи при неправильном вводе пароля, например 5 раз на 30 минут — помогает, хотя это и не полноценное решение.

Работает не только с RDP, но и может отслеживать:

• FTP
• RRAS — Routing and Remote Access
• Kerberos pre-authentication
• AD Credential Validation
• Windows Base
• FileMaker
• SMTP
• SQL Server

И как вариант, можно рассмотреть RdpGuard, что достаточно актуально будет для облачных виртуальных серверов.

Дополнительная информация и вариант решения для защиты от перебора паролей RDP с блокировкой IP правилами Windows Firewall : https://winitpro.ru/index.php/2019/10/02/blokirovka-rdp-atak-firewall-powershell/

Имел возможность реализовать защиту RDP соединения, при помощи готового решение для реализации двухфакторной аутентификации с защитой RDP от ESET (ESET Secure Authentication для защиты локального или удаленного входа в систему через протокол RDP).

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

Ссылка на решение ESET Secure Authentication, для пользователей Украины.

Есть простое и понятное видео, которое сам использовал при настройке ESET Secure Authentication.

Есть ряд базовых советов, по защите от атак шифровальщиков и неизвестных угроз:

Бизнес-предложение для фирм, предприятий, частных лиц и организаций (облачные решения).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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