Как защитить windows server от брутфорс атаки

Возникла идея написать простой 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:psblocked_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:psblock_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 AUTHORITYSYSTEM"
$Action= New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "C:PSblock_rdp_attack.ps1"
Register-ScheduledTask -TaskName "BlockRDPBruteForce_PS" -Trigger $Trigger -User $User -Action $Action -RunLevel Highest –Force

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

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

$Last_n_Hours = [DateTime]::Now.AddHours(-5)

{$_.Count -gt 5}

$log = "C:blocked_ip_rdp.txt"

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

В среде администраторов бытует мнение, что выставлять RDP без VPN «наружу» нельзя. На сегодняшний день это не так, современные реализации протокола используют даже по умолчанию SSL-защиту и проверку подлинности на уровне сети (NLA), если использовать поддерживаемые версии ОС и своевременно устанавливать обновления, то RDP будет достаточно надежным для использования без дополнительной защиты.

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

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

• NEW — новый пакет, не принадлежащий ни одному соединению
• ESTABLISHED — пакет, принадлежащий уже установленному соединению
• RELATED — пакет нового соединения, порождённого уже существующим соединением, многие протоколы, например, FTP открывают дополнительные соединения для передачи данных
• INVALID — все что не относится к первым трем состояниям, это пакет, не принадлежащий ни одному соединению и не являющийся первым пакетом нового соединения.

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

Современные решения предусматривают проверку подлинности на уровне сети (NLA) и клиент сначала должен пройти процесс аутентификации, прежде чем он сможет подключиться к компьютеру, RDP-сессия при этом не создается. Пакет с запросом аутентификации будет иметь состояние NEW, при неудачной аутентификации каждый новый запрос будет создавать еще один пакет с состоянием NEW.

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

Таким образом успешное RDP соединение предусматривает получение двух пакетов с состоянием NEW, каждая попытка аутентификации еще одного. Это дает возможность достаточно легко отличать легальных пользователей от ботов и злоумышленников. Фактически если в течении короткого промежутка времени мы получили более 2 пакетов в состоянии NEW — то это однозначно свидетельствует, что на той стороне ошиблись при вводе учетных данных.

Так как человеку свойственно ошибаться, то оставим легальным пользователям право на ошибку: три неверных попытки и одна правильная — итого пять пакетов NEW в течении короткого времени, злоумышленник за это время успеет пять раз попробовать ввести учетные данные. Какой промежуток времени взять? Одной-двух минут в целом будет достаточно, даже при ручных попытках ввода. Но не следует устанавливать слишком большой интервал, так как пользователь может случайно отключиться — подключиться снова и попасть под блокировку. Брутфорсом же занимаются преимущественно боты и даже минуты им с лихвой хватит чтобы выйти за пределы лимитов.

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

Для этой цели мы будем использовать добавление адреса-источника в Address List и таблицу Mangle. Почему именно Mangle, ведь действие add src to address list доступно и в Filter? Один из основных принципов построения брандмауэра — это читабельность правил конфигурации. В Filter мы ожидаем увидеть действия, производимые с пакетами на основании тех или иных условий. А вот Mangle предназначена для маркировки пакетов и соединений, и, хотя, добавление в списки не совсем маркировка, логически более верным будет разместить эти правила здесь.

Итак, переходим в IP — Firewall — Mangle и создаем следующее новое правило: Chain — forward, Protocol — tcp, Dst. Port — 3389, Connection State — new.

На закладке Action добавляем действие add src to address list и укажем имя списка rdp_stage1 и время действия записи — 1 минута.

В терминале можете выполнить:

/ip firewall mangle
add action=add-src-to-address-list address-list=rdp_stage1 address-list-timeout=1m chain=forward connection-state=new dst-port=3389 protocol=tcp

Что мы сейчас сделали? Для каждого транзитного пакета на порт 3389 с состоянием NEW мы помещаем его адрес-источник в список rdp_stage1 на 1 минуту. Получив еще один такой пакет, мы должны проверить, нет ли его уже в указанном списке, а если есть, то поместить в список rdp_stage2, для этого создаем еще одно аналогичное правило, но с дополнительным условием, на закладке Advanced указываем Src. Address List — rdp_stage1, а на закладке Action в качестве списка указываем rdp_stage2.

Это же действие в терминале:

/ip firewall mangle
add action=add-src-to-address-list address-list=rdp_stage2 address-list-timeout=1m chain=forward connection-state=new dst-port=3389 protocol=tcp src-address-list=rdp_stage1

Затем создаем еще одно правило, где указываем Src. Address List — rdp_stage2, а список на закладке Action — rdp_stage3, и еще два, пока не заполним список rdp_stage5.

/ip firewall mangle
add action=add-src-to-address-list address-list=rdp_stage3 address-list-timeout=1m chain=forward connection-state=new dst-port=3389 protocol=tcp src-address-list=rdp_stage2
add action=add-src-to-address-list address-list=rdp_stage4 address-list-timeout=1m chain=forward connection-state=new dst-port=3389 protocol=tcp src-address-list=rdp_stage3
add action=add-src-to-address-list address-list=rdp_stage5 address-list-timeout=1m chain=forward connection-state=new dst-port=3389 protocol=tcp src-address-list=rdp_stage4

И, наконец, последнее правило, с условием Src. Address List — rdp_stage5 и действием Action — add src to address list, Address List — rdp_drop и таймаутом, скажем, 30 минут.

Или в терминале:

/ip firewall mangle
add action=add-src-to-address-list address-list=rdp_drop address-list-timeout=30m chain=forward connection-state=new dst-port=3389 protocol=tcp src-address-list=rdp_stage5

Как это все работает? Адрес-источник первого NEW пакета мы помещаем в список rdp_stage1 на одну минуту, если с этого адреса снова придет новый пакет, то адрес источник попадет в список rdp_stage2, тоже на минуту, если в течении этой минуты снова придет новый пакет — то он будет помещен в rdp_stage3 и т.д. Шестой пакет с состоянием NEW попадет в список rdp_drop на полчаса. Время блокировки вы можете выбирать самостоятельно, в зависимости от текущих условий, но следует избегать больших значений, если пользователь таки попадет под блокировку, а администратор случайно не на связи, то полчаса гораздо лучше, чем сутки.

Следующий момент, после того как вы добавили все эти правила, их следует разместить в обратном порядке, от последнего к первому. Почему? Потому что действие add src to address list не является терминальным и пакет продолжает свое движение по цепочке. И если правила оставить в том порядке, в котором они был добавлены то получится следующее: первое правило добавит новый пакет в список rdp_stage1, второе проверит, нет ли его в этом списке, а оно там есть, и добавит в rdp_stage2. Далее вы поняли, адрес источник с первого же пакета добавится последовательно во все списки включая rdp_drop. Поэтому проверять списки надо в обратном порядке, от rdp_stage5 к rdp_stage1.

Если вы работаете в терминале, то правильная последовательность действий будет выглядеть так:

/ip firewall mangle
add action=add-src-to-address-list address-list=rdp_drop address-list-timeout=30m chain=forward connection-state=new dst-port=3389 protocol=tcp src-address-list=rdp_stage5
add action=add-src-to-address-list address-list=rdp_stage5 address-list-timeout=1m chain=forward connection-state=new dst-port=3389 protocol=tcp src-address-list=rdp_stage4
add action=add-src-to-address-list address-list=rdp_stage4 address-list-timeout=1m chain=forward connection-state=new dst-port=3389 protocol=tcp src-address-list=rdp_stage3
add action=add-src-to-address-list address-list=rdp_stage3 address-list-timeout=1m chain=forward connection-state=new dst-port=3389 protocol=tcp src-address-list=rdp_stage2
add action=add-src-to-address-list address-list=rdp_stage2 address-list-timeout=1m chain=forward connection-state=new dst-port=3389 protocol=tcp src-address-list=rdp_stage1
add action=add-src-to-address-list address-list=rdp_stage1 address-list-timeout=1m chain=forward connection-state=new dst-port=3389 protocol=tcp

Теперь проверим работу наших правил, выполним подключение к RDP одновременно контролируя IP — Firewall — Address Lists. Если все прошло нормально, то мы увидим наш адрес-источник в списках rdp_stage1 и rdp_stage2.

Теперь попробуем три раза ошибиться и на четвертый зайти:

Как видим, практика полностью совпадает с теорией, следовательно, можно переходить к блокировкам, не опасаясь, что пострадают легальные пользователи. Блокировать мы будем в таблице Raw, почему? Raw содержит «сырые» данные о пакетах, до того, как они будут переданы Connection Tracking, а так как определение состояния пакета достаточно ресурсозатратная операция, то отсекая лишний трафик в Raw мы снижаем нагрузку на процессор роутера, что важно в случае достаточно большого списка.

Переходим в IP — Firewall — Raw и создаем новое правило: Chain — prerouting, Protocol -tcp, Port — 3389.

На закладе Advanced указываем Src. Address List — rdp_drop:

И на закладке Action — действие drop.

Все тоже самое быстро делается в терминале следующей командой:

/ip firewall raw
add action=drop chain=prerouting dst-port=3389 protocol=tcp src-address-list=rdp_drop

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

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

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Инструкция
по скрипту и сам скрипт, проверялся на работоспособность в Windows
Server 2012. Остальная информация на данной странице, актуальна для
любой версии ОС.

Сами
растраты на организацию RDP
сервера для клиентов в таких фирмах – уже достижение. А тут еще нужен
производительный роутер, нужно организовать поддержку пользователей.

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

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

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

• имена
  пользователей не должны быть стандартными
• пароль
  должен быть сложным

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

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

Computer ConfigurationSecurity SettingsLocal PoliciesAccount PoliciesPassword Policy

Minimum password length = 9

Password must meet complexity requirements = Enabled

Computer ConfigurationSecurity SettingsLocal PoliciesAccount PoliciesAccount Lockout Policy

Account lockout threshold = 5

Reset account lockout counter after = 30

Account lockout duration = 30

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

Computer ConfigurationPoliciesAdministrative
TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session
HostSecurity

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 на нестандартный. Настройки
находятся в реестре:

KEY_LOCAL_MACHINESystemCurrentControlSetControlTerminal
ServerWinStationsRDP-TcpPortNumber

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

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

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

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

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

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

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

Определим
переменные:

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

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

$ban_treshold = 5

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

$ban_duration = 24

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

$ip2ban = @()

$ip2ban_str = @()

В нашем случае с
параметром групповой политики 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|?{$_.id -eq 140}

# пишем в лог

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

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

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

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

$ip2ban|%{ «#block_ip «+$_.name+»
«+$_.count >> $log_file }

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

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

if($ip2ban.count -gt 0){

# очищаем лог

  get-winevent
-ListLog Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational| % {
[System.Diagnostics.Eventing.Reader.EventLogSession]::GlobalSession.ClearLog($_.LogName)
}

 
$ip2ban|%{$ip2ban_str+=$_.name.tostring()}

# создаем правило 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*

$current_frs|%{

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

  $date_frs=[datetime]::parseexact($_.displayname,
‘RDP_DYN_BAN_ddMMyyyy_HHmmss’,$null)

# если разница в
часах больше 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 минут — помогает, хотя это и не полноценное решение.

Есть интересное и бесплатное программное решение: Cyberarms Intrusion Detection and Defense Software (IDDS) Есть инструкция: «Устанавливаем и настраиваем Cyberarms Intrusion Detection and Defense Software (IDDS)».

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

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

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

Для любителей держать открытым RPD в Интернет, рекомендую ознакомиться: https://www.ptsecurity.com/ru-ru/about/news/zloumyshlenniki-mogut-poluchit-dostup-k-kazhdomu-desyatomu-otkrytomu-udalennomu-rabochemu-stolu/

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

Для блокировок IP, ознакомьтесь с решением IPBan:

• Оф. сайт: https://www.digitalruby.com/ipban/
• Github: https://github.com/DigitalRuby/IPBan
• Инструкция: «Защита RDP подключения от брутфорса при помощи IPBan.»

Добавлено 27.01.2021

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

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

Заявка на получение ключа активации (бесплатная триал версия на 30-ть дней): https://www.esetnod32.ru/download/business/trial/?from=esa#download-business-trial

Загрузка последнего дистрибутива ESET Secure Authentication: https://www.esetnod32.ru/download/business/commercial/access/

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

https://www.eset.com/ua/business/secure-authentication/

Ссылка на загрузку: https://www.eset.com/ua/business/secure-authentication/download/

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

Добавлено 19.02.2021

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

• Пять шагов для защиты от вирусов-шифровальщиков.
• Как защититься от всевозможных вирусов-шифровальщиков?
• Простой, эффективный и бесплатный способ защиты от вирусов-шифровальщиков.
• Защита главной загрузочной записи (MBR).
• Отключаем SMB в ОС Windows 7/10 и в Windows 2008 R2.
• Нужен ли вам «IT-аудит безопасности»?
• «Защита RDP подключения от брутфорса при помощи IPBan.» 
• «Устанавливаем и настраиваем Cyberarms Intrusion Detection and Defense Software (IDDS).»  

Добавлено 04.07.2021

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

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

Резервное
копирование данных, защита данных от потерь, организация удаленного
офиса для сотрудников, настройка бухгалтерии в облаке, VDS/VPS, опытная и
отзывчивая поддержка, обслуживание и сопровождение на базе TUCHA.UA. Данное предложение
актуально для коммерческих и государственных структур.
Узнать больше… Услуги предоставляются данной компанией по СНГ и за пределами (Европа, США).

Добавлено 21.10.2021

На сайте winitpro в обсуждении статьи, один из пользователей, поделился своим рабочим скриптом, который:

• не зависит от языка системы и кодировок
• сохраняет логи
• проверяет на повторяющиеся IP адреса и отсекает их

Скрин на комментарий:

Сам скрипт:

$Attempts = 5 # За сколько попыток блокировать
$Hours = 1 # За какое время считать попытки
$RDPPort = «3389» # Блокируемый порт, стандартный — 3389
$NameRule = «BlockRDPBruteForce» # Название правила брандмауэра
$log = «blocked_ip_rdp.txt» # Лог-файл (можно указать вместе с путём к файлу)

# Проверяем наличие правила в брандмауэре и создаём его, если отсутствует
if($null -eq (Get-NetFirewallRule -DisplayName $NameRule -ErrorAction SilentlyContinue)){New-NetFirewallRule -DisplayName «$NameRule» –RemoteAddress 1.1.1.1 -Direction Inbound -Protocol TCP –LocalPort $RDPPort -Action Block}
# Получаем список системных сообщений с неудачными попытками за указанное время
$badRDPlogons = Get-WinEvent -FilterHashTable @{LogName=’Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational’;ID=’140′;StartTime=([DateTime]::Now.AddHours(-$Hours))}
# Получаем новые IP адреса с неудачными попытками авторизации за указанное время
$getip = $badRDPlogons.Properties | group-object -property value | where {$_.Count -gt $Attempts} | Select -property Name
# Получаем список IP из текущего правила брандмауэра
$current_ips = (Get-NetFirewallRule -DisplayName «$NameRule» | Get-NetFirewallAddressFilter ).RemoteAddress -split(‘,’)
# Проверяем найденные IP среди уже заблокированных и формируем итоговый список IP
$ip = $getip | where { $getip.Name.Length -gt 1 -and !($current_ips -contains $getip.Name) }
$ip | % {
$current_ips += $ip.name
# Записываем информацию в лог-файл
‘[‘+(Get-Date).ToString() + ‘] IP ‘ + $ip.name + ‘ blocked for ‘ + ($badRDPlogons | where { $_.IpAddress -eq $ip.name }).count + ‘ unsuccessful attempts in ‘ + $Hours + ‘ hour(s).’ >> $Log}
# Обновляем правило брандмауэра
Set-NetFirewallRule -DisplayName «$NameRule» -RemoteAddress $current_ips

Ссылка на источник скрипта, приведена выше. Смотрите внимательно комментарии к статье по ссылке.

Добавить 15.05.2022

Полезная заметка добавлена: Настройка двухфакторной аутентификации (2FA) в Windows с помощью MultiOTP.