InTrust สามารถช่วยลดอัตราการพยายามอนุญาตที่ล้มเหลวผ่าน RDP ได้อย่างไร

InTrust สามารถช่วยลดอัตราการพยายามอนุญาตที่ล้มเหลวผ่าน RDP ได้อย่างไร

ใครก็ตามที่ได้พยายามเรียกใช้เครื่องเสมือนในระบบคลาวด์จะทราบดีว่าหากเปิดพอร์ต RDP มาตรฐานไว้ จะถูกโจมตีเกือบจะในทันทีด้วยความพยายามรหัสผ่านดุร้ายจากที่อยู่ IP ต่างๆ ทั่วโลก

ในบทความนี้ฉันจะแสดงวิธีการ อินทรัสต์ คุณสามารถกำหนดค่าการตอบกลับอัตโนมัติต่อรหัสผ่านแบบ Brute Force ได้โดยการเพิ่มกฎใหม่ลงในไฟร์วอลล์ อินทรัสต์คือ แพลตฟอร์ม CLM สำหรับการรวบรวม วิเคราะห์ และจัดเก็บข้อมูลที่ไม่มีโครงสร้าง ซึ่งมีการตอบสนองที่กำหนดไว้ล่วงหน้าหลายร้อยรายการต่อการโจมตีประเภทต่างๆ

ใน Quest InTrust คุณสามารถกำหนดค่าการดำเนินการตอบสนองเมื่อมีการทริกเกอร์กฎ จากตัวแทนการรวบรวมบันทึก InTrust จะได้รับข้อความเกี่ยวกับการพยายามอนุญาตบนเวิร์กสเตชันหรือเซิร์ฟเวอร์ไม่สำเร็จ หากต้องการกำหนดค่าการเพิ่มที่อยู่ IP ใหม่ลงในไฟร์วอลล์ คุณจะต้องคัดลอกกฎที่กำหนดเองที่มีอยู่เพื่อตรวจหาการให้สิทธิ์ที่ล้มเหลวหลายรายการ และเปิดสำเนากฎนั้นเพื่อแก้ไข:

InTrust สามารถช่วยลดอัตราการพยายามอนุญาตที่ล้มเหลวผ่าน RDP ได้อย่างไร

เหตุการณ์ในบันทึกของ Windows ใช้สิ่งที่เรียกว่า InsertionString ดูการแข่งขันสำหรับรหัสเหตุการณ์ 4625 (นี่คือการเข้าสู่ระบบไม่สำเร็จ) และคุณจะเห็นว่าฟิลด์ที่เราสนใจถูกเก็บไว้ใน InsertionString14 (ชื่อเวิร์กสเตชัน) และ InsertionString20 (ที่อยู่เครือข่ายต้นทาง) เมื่อถูกโจมตีจากอินเทอร์เน็ตฟิลด์ชื่อเวิร์กสเตชันจะเป็นไปได้มากที่สุด ว่างเปล่า ดังนั้นสถานที่นี้จึงมีความสำคัญแทนค่าจากที่อยู่เครือข่ายต้นทาง

นี่คือลักษณะของข้อความของเหตุการณ์ 4625:

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.

นอกจากนี้ เราจะเพิ่มค่าที่อยู่เครือข่ายต้นทางให้กับข้อความเหตุการณ์

InTrust สามารถช่วยลดอัตราการพยายามอนุญาตที่ล้มเหลวผ่าน RDP ได้อย่างไร

จากนั้นคุณต้องเพิ่มสคริปต์ที่จะบล็อกที่อยู่ IP ใน Windows 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
}

ตอนนี้คุณสามารถเปลี่ยนชื่อกฎและคำอธิบายเพื่อหลีกเลี่ยงความสับสนในภายหลังได้

InTrust สามารถช่วยลดอัตราการพยายามอนุญาตที่ล้มเหลวผ่าน RDP ได้อย่างไร

ตอนนี้ คุณต้องเพิ่มสคริปต์นี้เป็นการดำเนินการตอบสนองต่อกฎ เปิดใช้งานกฎ และตรวจสอบให้แน่ใจว่ากฎที่เกี่ยวข้องถูกเปิดใช้งานในนโยบายการตรวจสอบแบบเรียลไทม์ ต้องเปิดใช้งานเอเจนต์เพื่อรันสคริปต์ตอบกลับและต้องมีการระบุพารามิเตอร์ที่ถูกต้อง

InTrust สามารถช่วยลดอัตราการพยายามอนุญาตที่ล้มเหลวผ่าน RDP ได้อย่างไร

หลังจากการตั้งค่าเสร็จสิ้น จำนวนการอนุญาตที่ไม่สำเร็จลดลง 80% กำไร? อะไรจะดีขนาดนี้!

InTrust สามารถช่วยลดอัตราการพยายามอนุญาตที่ล้มเหลวผ่าน RDP ได้อย่างไร

บางครั้งการเพิ่มขึ้นเล็กน้อยเกิดขึ้นอีกครั้ง แต่นี่เกิดจากการเกิดขึ้นของแหล่งการโจมตีใหม่ จากนั้นทุกอย่างก็เริ่มลดลงอีกครั้ง

ตลอดระยะเวลาการทำงานหนึ่งสัปดาห์ มีการเพิ่มที่อยู่ IP 66 รายการลงในกฎไฟร์วอลล์

InTrust สามารถช่วยลดอัตราการพยายามอนุญาตที่ล้มเหลวผ่าน RDP ได้อย่างไร

ด้านล่างนี้คือตารางที่มีชื่อผู้ใช้ทั่วไป 10 ชื่อที่ใช้สำหรับการพยายามอนุญาต

Имяпользователя

จำนวน

เป็นเปอร์เซ็นต์

ผู้บริหาร

1220235

40.78

ผู้ดูแลระบบ

672109

22.46

ผู้ใช้งาน

219870

7.35

คอนโตโซ

126088

4.21

contoso.com

73048

2.44

ผู้บริหาร

55319

1.85

เซิร์ฟเวอร์

39403

1.32

sgazlabdc01.contoso.com

32177

1.08

administrateur

32377

1.08

sgazlabdc01

31259

1.04

บอกเราในความคิดเห็นว่าคุณตอบสนองต่อภัยคุกคามความปลอดภัยของข้อมูลอย่างไร ใช้ระบบอะไรและสะดวกแค่ไหน?

หากคุณสนใจที่จะเห็นการทำงานของ InTrust ฝากคำขอไว้ ในแบบฟอร์มข้อเสนอแนะบนเว็บไซต์ของเราหรือเขียนถึงฉันในข้อความส่วนตัว

อ่านบทความอื่น ๆ ของเราเกี่ยวกับความปลอดภัยของข้อมูล:

เราตรวจพบการโจมตีของแรนซัมแวร์ เข้าถึงตัวควบคุมโดเมน และพยายามต้านทานการโจมตีเหล่านี้

สิ่งที่มีประโยชน์จากบันทึกของเวิร์กสเตชันที่ใช้ Windows OS (บทความยอดนิยม)

การติดตามวงจรชีวิตผู้ใช้โดยไม่ต้องใช้คีมและเทปพันสายไฟ

แล้วใครเป็นคนทำ? เราทำการตรวจสอบความปลอดภัยของข้อมูลโดยอัตโนมัติ

วิธีลดต้นทุนการเป็นเจ้าของระบบ SIEM และเหตุผลที่คุณต้องการ Central Log Management (CLM)

ที่มา: will.com

เพิ่มความคิดเห็น