Jeder, der versucht hat, eine virtuelle Maschine in der Cloud zu betreiben, ist sich bewusst, dass ein Standard-RDP-Port, wenn er offen gelassen wird, fast sofort von Wellen von Passwort-Brute-Force-Versuchen von verschiedenen IP-Adressen auf der ganzen Welt angegriffen wird.
In diesem Artikel werde ich zeigen, wie es geht Sie können eine automatische Reaktion auf Passwort-Brute-Force konfigurieren, indem Sie der Firewall eine neue Regel hinzufügen. InTrust ist zum Sammeln, Analysieren und Speichern unstrukturierter Daten, die bereits über Hunderte vordefinierte Reaktionen auf verschiedene Angriffsarten verfügen.
In Quest InTrust können Sie Reaktionsaktionen konfigurieren, wenn eine Regel ausgelöst wird. Vom Protokollerfassungsagenten erhält InTrust eine Nachricht über einen fehlgeschlagenen Autorisierungsversuch auf einer Workstation oder einem Server. Um das Hinzufügen neuer IP-Adressen zur Firewall zu konfigurieren, müssen Sie eine vorhandene benutzerdefinierte Regel zur Erkennung mehrerer fehlgeschlagener Autorisierungen kopieren und eine Kopie davon zur Bearbeitung öffnen:
Ereignisse in Windows-Protokollen verwenden etwas namens InsertionString. (Dies ist eine fehlgeschlagene Anmeldung am System) und Sie werden sehen, dass die Felder, die uns interessieren, in InsertionString14 (Workstation-Name) und InsertionString20 (Quellnetzwerkadresse) gespeichert sind. Bei einem Angriff aus dem Internet wird dies höchstwahrscheinlich im Feld Workstation-Name der Fall sein leer sein, daher ist es wichtig, dass diese Stelle durch den Wert der Quellnetzwerkadresse ersetzt wird.
So sieht der Text des Ereignisses 4625 aus:
An account failed to log on.
Subject:
Security ID: S-1-5-21-1135140816-2109348461-2107143693-500
Account Name: ALebovsky
Account Domain: LOGISTICS
Logon ID: 0x2a88a
Logon Type: 2
Account For Which Logon Failed:
Security ID: S-1-0-0
Account Name: Paul
Account Domain: LOGISTICS
Failure Information:
Failure Reason: Account locked out.
Status: 0xc0000234
Sub Status: 0x0
Process Information:
Caller Process ID: 0x3f8
Caller Process Name: C:WindowsSystem32svchost.exe
Network Information:
Workstation Name: DCC1
Source Network Address: ::1
Source Port: 0
Detailed Authentication Information:
Logon Process: seclogo
Authentication Package: Negotiate
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
This 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.
Darüber hinaus fügen wir dem Ereignistext den Wert der Quellnetzwerkadresse hinzu.
Anschließend müssen Sie ein Skript hinzufügen, das die IP-Adresse in der Windows-Firewall blockiert. Nachfolgend finden Sie ein Beispiel, das hierfür verwendet werden kann.
Skript zum Einrichten einer Firewall
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-Object
if (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
}
Jetzt können Sie den Namen und die Beschreibung der Regel ändern, um spätere Verwirrung zu vermeiden.
Jetzt müssen Sie dieses Skript als Antwortaktion zur Regel hinzufügen, die Regel aktivieren und sicherstellen, dass die entsprechende Regel in der Echtzeitüberwachungsrichtlinie aktiviert ist. Der Agent muss für die Ausführung eines Antwortskripts aktiviert sein und den richtigen Parameter angeben.
Nach Abschluss der Einstellungen sank die Anzahl der fehlgeschlagenen Autorisierungen um 80 %. Profitieren? Was für ein tolles!
Manchmal kommt es erneut zu einem kleinen Anstieg, der jedoch auf das Aufkommen neuer Angriffsquellen zurückzuführen ist. Dann beginnt alles wieder zu verfallen.
Im Laufe einer Woche Arbeit wurden 66 IP-Adressen zur Firewall-Regel hinzugefügt.
Nachfolgend finden Sie eine Tabelle mit 10 gängigen Benutzernamen, die für Autorisierungsversuche verwendet wurden.
Benutzername
Anzahl
In Prozent
Administratoren.
1220235
40.78
Administrator
672109
22.46
Benutzer
219870
7.35
contoso
126088
4.21
contoso.com
73048
2.44
Verwalter
55319
1.85
Server
39403
1.32
sgazlabdc01.contoso.com
32177
1.08
administrateur
32377
1.08
sgazlabdc01
31259
1.04
Sagen Sie uns in den Kommentaren, wie Sie auf Bedrohungen der Informationssicherheit reagieren. Welches System verwenden Sie und wie praktisch ist es?
Wenn Sie daran interessiert sind, InTrust in Aktion zu sehen, im Feedback-Formular auf unserer Website oder schreiben Sie mir eine persönliche Nachricht.
Lesen Sie unsere anderen Artikel zum Thema Informationssicherheit:
(beliebter Artikel)
Source: habr.com