Iedereen die heeft geprobeerd een virtuele machine in de cloud te laten draaien, is zich er terdege van bewust dat een standaard RDP-poort, als hij open blijft, vrijwel onmiddellijk zal worden aangevallen door golven van wachtwoord-brute force-pogingen van verschillende IP-adressen over de hele wereld.
In dit artikel laat ik zien hoe U kunt een automatisch antwoord op brute force van wachtwoorden configureren door een nieuwe regel aan de firewall toe te voegen. InTrust is voor het verzamelen, analyseren en opslaan van ongestructureerde gegevens, die al honderden vooraf gedefinieerde reacties op verschillende soorten aanvallen kennen.
In Quest InTrust kunt u responsacties configureren wanneer een regel wordt geactiveerd. Van de logcollector ontvangt InTrust een bericht over een mislukte autorisatiepoging op een werkstation of server. Om het toevoegen van nieuwe IP-adressen aan de firewall te configureren, moet u een bestaande aangepaste regel voor het detecteren van meerdere mislukte autorisaties kopiëren en een kopie ervan openen om te bewerken:
Gebeurtenissen in Windows-logboeken gebruiken iets dat InsertionString wordt genoemd. (dit is een mislukte aanmelding bij het systeem) en u zult zien dat de velden waarin wij geïnteresseerd zijn, zijn opgeslagen in InsertionString14 (werkstationnaam) en InsertionString20 (bronnetwerkadres). Bij aanvallen vanaf internet zal het veld Werkstationnaam hoogstwaarschijnlijk leeg zijn, dus deze plaats is belangrijk. Vervang de waarde uit het bronnetwerkadres.
Zo ziet de tekst van gebeurtenis 4625 eruit:
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.
Daarnaast voegen we de waarde Bronnetwerkadres toe aan de gebeurtenistekst.
Vervolgens moet u een script toevoegen dat het IP-adres in de Windows Firewall blokkeert. Hieronder staat een voorbeeld dat hiervoor gebruikt kan worden.
Script voor het instellen van een 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
}
Nu kunt u de regelnaam en -beschrijving wijzigen om later verwarring te voorkomen.
Nu moet u dit script als reactieactie aan de regel toevoegen, de regel inschakelen en ervoor zorgen dat de overeenkomstige regel is ingeschakeld in het realtime monitoringbeleid. De agent moet zijn ingeschakeld om een responsscript uit te voeren en de juiste parameter moet zijn opgegeven.
Nadat de instellingen waren voltooid, daalde het aantal mislukte autorisaties met 80%. Winst? Wat een geweldig!
Soms treedt er weer een kleine stijging op, maar dit komt door de opkomst van nieuwe aanvalsbronnen. Dan begint alles weer te dalen.
In de loop van een werkweek werden 66 IP-adressen aan de firewallregel toegevoegd.
Hieronder vindt u een tabel met tien veelvoorkomende gebruikersnamen die zijn gebruikt voor autorisatiepogingen.
Gebruikersnaam
Aantal
In procenten
administrateur
1220235
40.78
beheerder
672109
22.46
gebruiker
219870
7.35
verwrongen
126088
4.21
contoso.com
73048
2.44
administrateur
55319
1.85
server
39403
1.32
sgazlabdc01.contoso.com
32177
1.08
administrateur
32377
1.08
sgazlabdc01
31259
1.04
Vertel ons in de reacties hoe u reageert op bedreigingen voor de informatiebeveiliging. Welk systeem gebruiken jullie en hoe handig is het?
Als u InTrust in actie wilt zien, in het feedbackformulier op onze website of schrijf mij in een persoonlijk bericht.
Lees onze andere artikelen over informatiebeveiliging:
(populair artikel)
Bron: www.habr.com