Всем, кто пытался запустить виртуальную машину в облаке, хорошо известно, что стандартный порт RDP, если его оставить открытым, будет почти сразу атакован волнами попыток перебора пароля с различных IP-адресов по всему миру.
В этой статье я покажу как в InTrust можно настроить автоматическую реакцию на перебор пароля в виде добавления нового правила на брандмауэр. InTrust это CLM-платформа для сбора, анализа и хранения неструктурированных данных, в которой есть уже сотни предустановленных реакций на различные типы атак.
В Quest InTrust можно настроить ответные действия при срабатывании правила. С агента-сборщика логов InTrust получает сообщение о неудачной попытке авторизации на рабочей станции или сервере. Чтобы настроить добавление новых IP-адресов в брандмауэр, необходимо скопировать существующее специализированное правило обнаружения множественных неудачных авторизаций и открыть его копию для редактирования:
События в журналах Windows используют так называемые InsertionString. Посмотрите соответствия для события с кодом 4625 (это неудачный логон в систему) и увидите, что интересующие нас поля хранятся в InsertionString14 (Workstation Name) и InsertionString20 (Source Network Address), При атаке из интернета, поле с Workstation Name будет, скорее всего, пустым, поэтому важно на это место подставить значение из Source Network Address.
An account failed to log on.Subject:Security ID:S-1-5-21-1135140816-2109348461-2107143693-500Account Name:ALebovskyAccount Domain:LOGISTICSLogon ID:0x2a88aLogon Type:2Account For Which Logon Failed:Security ID:S-1-0-0Account Name:PaulAccount Domain:LOGISTICSFailure Information:Failure Reason:Account locked out.Status:0xc0000234Sub Status:0x0Process Information:Caller Process ID:0x3f8Caller Process Name:C:\Windows\System32\svchost.exeNetwork Information:Workstation Name:DCC1Source Network Address:::1Source Port:0Detailed Authentication Information:Logon Process:seclogoAuthentication Package:NegotiateTransited Services:-Package Name (NTLM only):-Key Length:0This event is generated when a logon request fails. It is generated on the computer where access was attempted.The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).The Process Information fields indicate which account and process on the system requested the logon.The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.The authentication information fields provide detailed information about this specific logon request.- Transited services indicate which intermediate services have participated in this logon request.- Package name indicates which sub-protocol was used among the NTLM protocols.- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
Дополнительно, добавим значение Source Network Address в текст события.
Затем нужно добавить скрипт, который будет блокировать IP-адрес в брандмауэре Windows. Ниже пример, который для этого можно использовать.
param( [Parameter(Mandatory = $true)] [ValidateNotNullOrEmpty()] [string] $SourceAddress)$SourceAddress = $SourceAddress.Trim()$ErrorActionPreference = 'Stop'$ruleName = 'Quest-InTrust-Block-Failed-Logons'$ruleDisplayName = 'Quest InTrust: Blocks IP addresses from failed logons'function Get-BlockedIps { (Get-NetFirewallRule -Name $ruleName -ErrorAction SilentlyContinue | get-netfirewalladdressfilter).RemoteAddress}$blockedIps = Get-BlockedIps$allIps = [array]$SourceAddress + [array]$blockedIps | Select-Object -Unique | Sort-Objectif (Get-NetFirewallRule -Name $ruleName -ErrorAction SilentlyContinue) { Set-NetFirewallRule -Name $ruleName -RemoteAddress $allIps} else { New-NetFirewallRule -Name $ruleName -DisplayName $ruleDisplayName -Direction Inbound -Action Block -RemoteAddress $allIps}
Теперь можно изменить имя правило и его описание, чтобы потом не возникло путаницы.
Теперь нужно добавить этот скрипт в качестве ответного действия к правилу, включить правило и убедиться, что соответствующее правило включено в политике мониторинга для режима реального времени. На агенте должна быть включена возможность запуска сценарий ответного действия и обязательно указан правильный параметр.
После выполненных настроек, количество неудачных авторизаций снизилось на 80%. Профит? Ещё какой!
Иногда небольшой рост возникает снова, но это из-за появления новых источников атак. Потом всё снова идёт на спад.
За неделю работы в правило брандмауэра попало 66 IP-адресов.
Ниже таблица с 10 частыми именами пользователей, которые использовались для попыток авторизаций.
Имя пользователя |
Количество |
В процентах |
administrator |
1220235 |
40.78 |
admin |
672109 |
22.46 |
user |
219870 |
7.35 |
contoso |
126088 |
4.21 |
contoso.com |
73048 |
2.44 |
administrador |
55319 |
1.85 |
server |
39403 |
1.32 |
sgazlabdc01.contoso.com |
32177 |
1.08 |
administrateur |
32377 |
1.08 |
sgazlabdc01 |
31259 |
1.04 |
Расскажите в комментариях как у вас построено реагирование на угрозы информационной безопасности. Какую систему используете, насколько она удобна.
Если интересно посмотреть InTrust в работе, оставьте заявку в форме обратной связи на нашем сайте или напишите мне в личку.
Почитайте другие наши статьи по теме информационной безопасности:
Выявляем атаку вируса-шифровальщика, получаем доступ к контроллеру домена и пробуем противостоять этим атакам
Что полезного можно вытащить из логов рабочей станции на базе ОС Windows (популярная статья)
Отслеживание жизненного цикла пользователей без плоскогубцев и изоленты
А кто это сделал? Автоматизируем аудит информационной безопасности
Как снизить стоимость владения SIEM-системой и зачем нужен Central Log Management (CLM)