การโจมตีแบบ brute-force ผ่าน RDP เป็นอย่างไรในทางปฏิบัติ
คุณมักจะสังเกตเห็น RDP การโจมตีแบบ Brute Force ในลักษณะเดียวกัน: การเข้าสู่ระบบที่ล้มเหลวซ้ำแล้วซ้ำเล่าต่อเซิร์ฟเวอร์ Windows ที่สามารถเข้าถึงได้จากอินเทอร์เน็ต มักจะตามมาด้วยการล็อกบัญชี บันทึกความปลอดภัยที่มีเสียงดัง และผู้ใช้ที่วิตกกังวลซึ่งไม่สามารถเชื่อมต่อได้ หลายๆ การโจมตีเหล่านี้ไม่ได้ “มุ่งเป้า” ในความหมายของมนุษย์ RDP ที่เปิดเผยต่ออินเทอร์เน็ตจะถูกสแกนอย่างต่อเนื่อง และเครื่องมืออัตโนมัติจะพยายามใช้ชื่อผู้ใช้และรหัสผ่านจนกว่าจะพบข้อมูลรับรองที่อ่อนแอหรือสร้างความยุ่งเหยิง
ใน MITRE ATT&CK นี้จะถูกแมพไปยัง เทคนิค T1110 (การโจมตีแบบ Brute Force) ซึ่งรวมถึงรูปแบบที่เกี่ยวข้องเช่นการเดารหัสผ่านและการพ่นรหัสผ่าน ในแง่ของการปฏิบัติจริง การโจมตีแบบ brute force ผ่าน RDP คือการพยายามเข้าสู่ระบบระยะไกลซ้ำ ๆ (มักจะเป็นแบบอัตโนมัติ) ที่พยายามใช้รหัสผ่านหลายรหัสหรือหลายบัญชีต่อบริการ RDP ที่เปิดเผยจนกว่าจะพบข้อมูลรับรองหรือบัญชีถูกขัดจังหวะ
อาการทั่วไป ได้แก่:
- การเพิ่มขึ้นอย่างกะทันหันของการเข้าสู่ระบบที่ล้มเหลวในบันทึกความปลอดภัยของ Windows
- หลายครั้งที่พยายามเข้าถึงชื่อบัญชีทั่วไป (ผู้ดูแลระบบ, ผู้ดูแล, ทดสอบ, ชื่อสไตล์บริการ)
- ความล้มเหลวที่มาจากที่อยู่ IP ภายนอกหลายแห่ง ซึ่งบางครั้งมีการเปลี่ยนแปลงบ่อยครั้ง
- ผู้ใช้ร้องเรียนเกี่ยวกับการล็อกบัญชีหรือประสิทธิภาพการเข้าสู่ระบบที่ช้า
- การใช้ CPU หรือการตรวจสอบสิทธิ์ที่สูงขึ้นในช่วงที่มีการใช้งาน (บริการที่เกี่ยวข้องกับ LSASS และ RDP อาจได้รับผลกระทบ)
มันช่วยให้ตั้งชื่อสิ่งที่คุณเห็น “Brute force” มักหมายถึงการใช้รหัสผ่านจำนวนมากกับบัญชีเดียว “Password spraying” หมายถึงการใช้รหัสผ่านทั่วไปไม่กี่ตัวกับหลายบัญชีเพื่อหลีกเลี่ยงการล็อกเอาต์ “Credential stuffing” หมายถึงการทดสอบคู่ชื่อผู้ใช้และรหัสผ่านที่ถูกขโมยจากที่อื่น ทั้งสามอย่างนี้แสดงให้เห็นถึงความล้มเหลวในการเข้าสู่ระบบระยะไกลซ้ำแล้วซ้ำเล่าและสมควรได้รับการตอบสนองแรกที่เหมือนกัน: ลดการเปิดเผยและชะลอความพยายามลง
การวินิจฉัยอย่างรวดเร็ว: ยืนยันว่าเป็นการโจมตีแบบ brute force RDP (และไม่ใช่การกำหนดค่าผิด)
ก่อนที่คุณจะเปลี่ยนนโยบายและเสี่ยงที่จะล็อกผู้ใช้ที่ถูกต้องตามกฎหมายออกไป ให้ยืนยันว่าสิ่งใดกำลังล้มเหลว มาจากที่ไหน และในปริมาณเท่าใด คำแนะนำการแก้ไขปัญหาของ Microsoft สำหรับ Azure VMs ที่ถูกโจมตีด้วยการโจมตีแบบ brute-force ใช้จุดเริ่มต้นเดียวกันแม้จะอยู่นอก Azure: มองหาจำนวนการลงชื่อเข้าใช้ที่ล้มเหลวสูงและเชื่อมโยงกับที่อยู่ IP ภายนอก
- ตรวจสอบบันทึกความปลอดภัยของ Windows สำหรับการพยายามเข้าสู่ระบบที่ล้มเหลวในช่วงเวลาที่ผู้ใช้รายงานปัญหา รหัสเหตุการณ์ 4625 เป็นตัวบ่งชี้ทั่วไปที่ควรตรวจสอบ
- มองหาลักษณะ: ชื่อบัญชีที่ซ้ำกัน, บัญชีที่แตกต่างกันมากมาย, หรือที่อยู่ IP แหล่งเดียวกันที่เข้าถึงผู้ใช้หลายคน.
- เชื่อมโยงการลงชื่อเข้าใช้ที่ล้มเหลวกับการลงชื่อเข้าใช้ที่สำเร็จในภายหลัง การลงชื่อเข้าใช้ที่สำเร็จมักจะถูกบันทึกเป็น Event ID 4624 ขึ้นอยู่กับนโยบายการตรวจสอบของคุณ
- ยืนยันการเปิดเผย: TCP 3389 (หรือตำแหน่ง RDP ที่กำหนดเองของคุณ) สามารถเข้าถึงได้จากอินเทอร์เน็ตผ่านกฎไฟร์วอลล์, NAT, การส่งต่อพอร์ต, หรือกลุ่มความปลอดภัยในคลาวด์หรือไม่?
- ตรวจสอบว่าคุณไม่ได้เห็น "สัญญาณเตือนเท็จ" จากแหล่งที่ถูกต้อง (เกตเวย์ RDS, คอนเซนเทรเตอร์ VPN, เครื่องมือการจัดการระยะไกล หรือสแกนเนอร์ภายใน) ที่ปรากฏเป็นความล้มเหลวซ้ำเนื่องจากรหัสผ่านที่บันทึกไว้ผิด.
หากคุณเห็น Event ID 4625 ในปริมาณมากจากที่อยู่ IP ภายนอกหลายแห่งในช่วงเวลาสั้น ๆ คุณอาจกำลังเผชิญกับการเดาหรือการพ่นที่ใช้งานอยู่มากกว่าการที่ผู้ใช้คนเดียวพิมพ์รหัสผ่านผิด
หยุดการไหลออกใน 15 ถึง 30 นาที (การดำเนินการควบคุมที่ได้ผล)
เมื่อการโจมตีแบบ brute-force กำลังทำงานอยู่ ความสำคัญคือการฟื้นฟูการควบคุมและรักษาเส้นทางการดูแลระบบที่ปลอดภัยให้พร้อมใช้งาน วิธีที่เร็วที่สุดในการลดความเสี่ยงจากการโจมตีแบบ brute-force ผ่าน RDP คือการหยุดการเปิดเผย RDP โดยตรงต่ออินเทอร์เน็ตและจำกัดการเข้าถึงจากภายนอกไปยังชุดของที่อยู่ IP ที่เชื่อถือได้หรือเส้นทางการเข้าถึงที่ปลอดภัย (เกตเวย์, VPN, หรือ bastion) คำแนะนำของ Microsoft Learn สำหรับเหตุการณ์ Azure เสริมแนวทางการควบคุมนี้: จำกัดการเข้าถึงจากภายนอกก่อน จากนั้นปรับปรุงเส้นทางการเข้าถึง
- สร้างวิธีที่ปลอดภัยในการกลับเข้ามาก่อนที่คุณจะเปลี่ยนแปลงอะไร. หากคุณถูกล็อกเอาไว้แล้ว ให้ใช้การเข้าถึงแบบนอกแบนด์ของคุณ (คอนโซลไฮเปอร์ไวเซอร์, iLO/iDRAC, คอนโซลซีเรียลคลาวด์, บาสเตียน หรือ VPN) เพื่อให้คุณสามารถจัดการโฮสต์ได้หลังจากการเปลี่ยนแปลงไฟร์วอลล์
- ลบการเปิดเผยอินเทอร์เน็ตโดยตรงของ RDP. ปิดการส่งต่อพอร์ตสาธารณะหรือทำให้กฎการเข้ามาเข้มงวดขึ้นเพื่อให้ RDP ไม่เปิดให้ “แหล่งใด ๆ” หากคุณไม่สามารถลบออกได้ทันที ให้จำกัดการเข้าถึงจากภายนอกไปยังรายการอนุญาตที่สั้น (ที่อยู่ IP ของสำนักงานของคุณ, เครือข่ายการจัดการของคุณ, ที่อยู่ IP ออกคงที่ของ MSP ของคุณ)
- บน Azure หรือคลาวด์ที่คล้ายกัน ให้รัดเขตแดนทันที จำกัดกฎการเข้าถึงใน NSG ของคุณหรือเทียบเท่า หากคุณมีตัวเลือก ให้ย้ายไปยังรูปแบบที่ได้รับการรับรองจาก Microsoft เช่น Azure Bastion, VPN Gateway หรือแนวคิดการเข้าถึงตามเวลาที่กำหนดเพื่อลดช่วงเวลาที่เปิดเผย
- ยืนยัน การตรวจสอบระดับเครือข่าย (NLA) เปิดใช้งานแล้ว NLA บังคับการตรวจสอบสิทธิ์ก่อนที่จะมีการสร้างเซสชันเดสก์ท็อประยะไกลเต็มรูปแบบ ซึ่งช่วยลดการเปิดเผยต่อความเสี่ยงก่อนการตรวจสอบสิทธิ์บางประการและลดการใช้ทรัพยากรที่ไม่จำเป็นในระหว่างการเดา.
- ตรวจสอบผู้ที่สามารถเข้าสู่ระบบผ่าน RDP ตรวจสอบความเป็นสมาชิกของผู้ดูแลระบบท้องถิ่นและผู้ใช้ Remote Desktop และลบกลุ่มที่กว้างขวางใด ๆ ที่ไม่จำเป็นต้องลงชื่อเข้าใช้ระยะไกลแบบโต้ตอบ
- ปกป้องบัญชีที่มีสิทธิพิเศษทันที หากคุณสงสัยว่ารหัสผ่านอาจจะอ่อนแอหรือรั่วไหล ให้เปลี่ยนข้อมูลประจำตัวสำหรับบัญชีที่มีสิทธิพิเศษในลักษณะที่ควบคุมได้ และตรวจสอบหาผู้ดูแลระบบท้องถิ่นใหม่ที่ไม่คาดคิดหรือบัญชีที่เพิ่งเปิดใช้งานใหม่
- ทำให้การเข้าถึงมีเสถียรภาพสำหรับผู้ใช้จริง หากผู้ใช้ถูกล็อกออก การแก้ไขมักจะเป็นการลดการเปิดเผยและการควบคุมที่ดีขึ้น ไม่ใช่การลดความปลอดภัย หลีกเลี่ยงการเร่งการเปลี่ยนแปลงการล็อกเอาต์ที่อาจสร้างการหยุดชะงักที่กว้างขึ้น
เมื่อคุณควบคุมการจราจรได้แล้ว คุณสามารถทำการเปลี่ยนแปลงระยะยาวได้อย่างปลอดภัย หากคุณต้องการวิธีการที่มีเครื่องมือช่วยหลังจากที่คุณกลับมาควบคุมได้ TSplus Advanced Security สามารถช่วยในการดำเนินการบล็อกการโจมตีแบบ brute-force และการจำกัดการเข้าถึงบนเซิร์ฟเวอร์ Windows แต่การควบคุมยังคงเริ่มต้นด้วยการลดการเปิดเผย.
ลดพื้นผิวการโจมตี: สถาปัตยกรรมการเข้าถึงที่ลดความเสี่ยงจากการโจมตีแบบ brute-force
หากคุณจะเรียนรู้เพียงบทเรียนเดียวจากการโจมตี RDP ที่เกิดขึ้นซ้ำแล้วซ้ำเล่า ให้เป็นบทเรียนนี้: สถาปัตยกรรมดีกว่าการปรับแต่ง การวางจุดเข้าถึงที่ควบคุมได้ไว้ข้างหน้าผู้ให้บริการเซสชันจะเปลี่ยนสิ่งที่ผู้โจมตีสามารถเข้าถึงได้และสิ่งที่คุณสามารถบังคับใช้ได้ คำแนะนำจากบล็อกความปลอดภัยของ Microsoft สำหรับการนำ Remote Desktop มาใช้ เน้นการลดการเปิดเผยโดยตรง และ เอกสาร Microsoft Learn RD Gateway เป็นวิธีการให้การเข้าถึงที่ปลอดภัยผ่าน TLS โดยมีการกำหนดค่าประกาศนียบัตรที่เหมาะสม
วิธีที่เชื่อถือได้ที่สุดในการลดการพยายามโจมตีแบบ brute-force ผ่าน RDP คือการหลีกเลี่ยงการเปิดเผย RDP โดยตรงและแทนที่นั้นให้เข้าถึงผ่านจุดเข้าที่ควบคุมได้ เช่น RD Gateway VPN หรือป้อมปราการ โดยเฉพาะอย่างยิ่งที่มีการตรวจสอบสิทธิ์ที่เข้มงวด
| รูปแบบการเข้าถึง | การเปิดเผยและความเสี่ยงจากการโจมตีแบบ brute-force | ความซับซ้อนในการดำเนินงาน | เมื่อมันเหมาะสม | หมายเหตุ |
|---|---|---|---|---|
| การเชื่อมต่อ RDP โดยตรงจากอินเทอร์เน็ต | ความเสี่ยงสูงสุดและเสียงรบกวนสูงสุด การสแกนและการเดาอย่างต่อเนื่อง | ตั้งค่าได้ต่ำ ป้องกันได้สูง | เฉพาะสำหรับการเข้าถึงในกรณีฉุกเฉินระยะสั้นที่มีข้อจำกัดอย่างเข้มงวด | การเปลี่ยนพอร์ตอาจลดการสแกนแบบโอกาส แต่ไม่ได้ให้การป้องกันที่แข็งแกร่งเพียงพอด้วยตัวมันเอง |
| การเชื่อมต่อ RDP โดยตรงด้วยการอนุญาต IP | การเปิดเผยที่ต่ำกว่าหากรายการอนุญาตมีขนาดเล็กและเสถียร | ปานกลาง ต้องการการดูแลรายการอนุญาตและจัดการการเปลี่ยนแปลงการเดินทาง/ISP | ทีมผู้ดูแลระบบขนาดเล็กที่มี IP สำนักงานที่กำหนดหรือการออกจาก MSP ที่กำหนด | ทำงานได้ดีที่สุดเมื่อจับคู่กับการควบคุมการพิสูจน์ตัวตนที่เข้มงวดและการตรวจสอบ |
| RD Gateway อยู่ด้านหน้าของ RDS/RDP | ลดการเปิดเผยโดยตรงของโฮสต์เซสชันและอุโมงค์ผ่าน TLS. | ปานกลางถึงสูง ใบรับรอง ความพร้อมใช้งาน และการออกแบบนโยบายมีความสำคัญ | สภาพแวดล้อมที่เน้น Windows ที่ใช้รูปแบบ RDS อยู่แล้ว | คำแนะนำการวางแผน RDS ของ Microsoft Learn ครอบคลุมข้อกำหนดของเกตเวย์ การอนุญาตของ Microsoft ยังคงเป็นความรับผิดชอบของคุณและควรได้รับการตรวจสอบกับ Microsoft หรือพันธมิตรด้านการอนุญาตที่มีคุณสมบัติ |
| VPN สำหรับการเข้าถึงระยะไกล | เมื่อทำอย่างถูกต้องจะลบ RDP ออกจากการเปิดเผยต่อสาธารณะ | ขนาดกลาง การติดตั้งไคลเอนต์ การจัดเส้นทาง และการรวม MFA แตกต่างกัน | ผู้ดูแลระบบและพนักงานที่ต้องการการเข้าถึงเครือข่ายที่กว้างขึ้น ไม่ใช่แค่แอปเดียว | จำกัดผู้ใช้ VPN ให้ตรงตามความต้องการ จากนั้นยังคงรักษาความปลอดภัย RDP ภายในเครือข่าย |
| บาสตียงหรือโฮสต์กระโดด | การลดการเปิดเผยที่แข็งแกร่ง RDP สามารถเข้าถึงได้จากบริบทของป้อมปราการเท่านั้น | ขนาดกลาง ต้องการการควบคุมที่เข้มงวดของป้อมปราการเอง | เซิร์ฟเวอร์ที่โฮสต์ในคลาวด์ สภาพแวดล้อมที่มีการควบคุม และการเข้าถึงเฉพาะผู้ดูแลระบบ | มักจะทำงานได้ดีร่วมกับหน้าต่างการเข้าถึงตามเวลาจริงและการควบคุมตามเงื่อนไขขึ้นอยู่กับแพลตฟอร์ม |
| เผยแพร่แอปพลิเคชัน/เดสก์ท็อปผ่านพอร์ทัลเว็บ (HTTPS) | สามารถลดหรือกำจัดความจำเป็นในการเปิดเผย RDP ดิบต่อสาธารณะ ขึ้นอยู่กับการออกแบบ | ต่ำถึงปานกลาง มุ่งเน้นการให้บริการสิ่งที่ผู้ใช้ต้องการ ไม่ใช่การเข้าถึงเครือข่ายทั้งหมด | SMBs ที่จัดส่งชุดแอปพลิเคชัน Windows หรือเดสก์ท็อประยะไกลให้กับผู้ใช้และพันธมิตร | หากเป้าหมายของคุณคือการให้ผู้ใช้เข้าถึงแอปพลิเคชัน Windows โดยไม่ต้องเปิด RDP ดิบให้กับอินเทอร์เน็ต TSplus Remote Access ควรค่าแก่การประเมินสำหรับการเผยแพร่แอปและเดสก์ท็อปผ่านพอร์ทัลเว็บที่ปลอดภัย |
หากคุณต้องการให้มีการเข้าถึง RDP บางส่วน ควรจัดการให้เป็นส่วนติดต่อผู้ดูแลระบบที่ได้รับการป้องกัน ไม่ใช่จุดเข้าทำงานระยะไกลทั่วไป หากคุณกำลังมุ่งหน้าไปยัง แอปพลิเคชันและการเผยแพร่เดสก์ท็อปผ่านพอร์ทัลเว็บที่ปลอดภัย คู่มือเริ่มต้นอย่างรวดเร็วสามารถช่วยให้คุณเริ่มต้นได้ ท่าทีด้านความปลอดภัยของคุณจะดีขึ้นอย่างมากเมื่อผู้ใช้ส่วนใหญ่ไม่เชื่อมต่อกับ TCP 3389 เลย
เสริมความปลอดภัยในการพิสูจน์ตัวตนสำหรับ RDP โดยไม่ล็อกผู้ใช้จริงออก
การต้านทานการโจมตีแบบ brute-force ที่ดีคือการสร้างสมดุลระหว่างการชะลอผู้โจมตีและการรักษาการเข้าถึงที่ถูกต้องให้เชื่อถือได้ การต้านทานการโจมตีแบบ brute-force ที่มีประสิทธิภาพจะรวม NLA และข้อมูลประจำตัวที่แข็งแกร่งเข้ากับนโยบายการจำกัดอัตราหรือการล็อกที่ชะลอความล้มเหลวที่เกิดขึ้นซ้ำในขณะที่ปรับให้หลีกเลี่ยงการปฏิเสธบริการที่เกิดจากผู้โจมตี NIST SP 800-63B พูดคุยเกี่ยวกับการจำกัดและการจัดการกับความพยายามในการตรวจสอบสิทธิ์ที่ล้มเหลวซ้ำ ๆ เป็นการควบคุมหลัก เนื่องจากช่วยลดความเป็นไปได้ในการเดาอย่างรวดเร็ว
เริ่มต้นด้วย NLA และการดูแลบัญชี
NLA เป็นมาตรฐานสำหรับ RDP เพราะต้องการการตรวจสอบสิทธิ์ก่อนที่เซสชันจะถูกสร้างขึ้นอย่างสมบูรณ์ มันจะไม่หยุดการโจมตีด้วยการเดารหัสผ่านด้วยตัวเอง แต่จะลดการเปิดเผยและทรัพยากรที่สูญเปล่าเมื่อเปรียบเทียบกับการปล่อยให้เซสชันที่ไม่ได้รับการตรวจสอบดำเนินต่อไป
จากนั้นให้จัดการกับพื้นฐานของตัวตนที่การโจมตีแบบ brute force ใช้ประโยชน์จาก: ลบสิทธิ์ผู้ดูแลระบบที่ไม่จำเป็น, บังคับใช้สิทธิ์ขั้นต่ำ, และทำความสะอาดบัญชีที่ไม่ใช้งาน หากคุณมีบัญชีผู้ดูแลระบบท้องถิ่นที่ชัดเจนหรือแชร์กัน ให้หมุนเวียนพวกเขา, จำกัดสถานที่ที่พวกเขาสามารถลงชื่อเข้าใช้, และพิจารณาการเปลี่ยนชื่อหรือปิดการใช้งานบัญชีที่ไม่จำเป็นต้องเข้าสู่ระบบแบบโต้ตอบ รักษาผู้ใช้ Remote Desktop และผู้ดูแลระบบท้องถิ่นให้เข้มงวด โดยเฉพาะอย่างยิ่งในเซิร์ฟเวอร์ที่โฮสต์ข้อมูลที่ละเอียดอ่อน
การล็อกเอาต์และการจำกัด: ทำไมการปรับแต่งจึงสำคัญ
การตั้งค่านโยบายการล็อกบัญชี Windows มักถูกใช้เพื่อลดความสำเร็จของการโจมตีแบบ brute-force และ เอกสาร Microsoft Learn อธิบายคำศัพท์สำคัญ เกณฑ์การล็อกเอาต์, ระยะเวลาการล็อกเอาต์, และตัวนับการรีเซ็ต การแลกเปลี่ยนคือความพร้อมใช้งาน ผู้โจมตีสามารถกระตุ้นการล็อกเอาต์สำหรับผู้ใช้จริง (หรือฝ่ายสนับสนุนและผู้ดูแลระบบของคุณ) ได้โดยเจตหากเกณฑ์ของคุณต่ำเกินไปและการเปิดเผยของคุณกว้างเกินไป
ใช้ปัจจัยการตัดสินใจเหล่านี้เมื่อคุณปรับการล็อกเอาต์และการจำกัดการใช้งาน:
- บริการมีความเสี่ยงแค่ไหน? หาก RDP สามารถเข้าถึงได้จากอินเทอร์เน็ตทั้งหมด การล็อกเอาต์มีแนวโน้มที่จะถูกใช้เป็นอาวุธมากขึ้น ลดการเปิดเผยก่อน จากนั้นปรับแต่งการล็อกเอาต์
- ผู้ใช้ยืนยันตัวตนได้อย่างไร? เกตเวย์, VPN หรือบาสเตียนสามารถลดความจำเป็นในการล็อคเอาท์ที่รุนแรงบนโฮสต์เซสชันได้เพราะแหล่งที่มาที่ไม่รู้จักมีน้อยลงที่จะเข้าถึงมันได้.
- การล็อกเอาต์มีค่าใช้จ่ายเท่าไหร่? หากการล็อกเอาต์แปลว่าเกิดการหยุดชะงักสำหรับทีมสนับสนุนการผลิต คุณอาจต้องการการจำกัดอัตราและการห้ามตาม IP มากกว่าการล็อกบัญชีที่เข้มงวด
- บัญชีที่แชร์มีพฤติกรรมอย่างไร? การใช้ข้อมูลประจำตัวร่วมกันจะเพิ่มผลกระทบจากการล็อกเอาต์ ควรกำจัดบัญชีที่ใช้ร่วมกันเมื่อเป็นไปได้
กรณีพิเศษ: ผู้ดูแลระบบท้องถิ่นที่ติดตั้งไว้ในตัว
หลายสภาพแวดล้อมยังคงมีบัญชีผู้ดูแลระบบท้องถิ่นที่สร้างขึ้นในเซิร์ฟเวอร์และเวิร์กสเตชัน และพฤติกรรมการล็อกเอาต์ของมันเป็นจุดที่ทำให้เกิดความสับสนบ่อยครั้ง Microsoft Support KB5020282 ให้ข้อมูลเกี่ยวกับการล็อกบัญชีสำหรับผู้ดูแลระบบท้องถิ่นที่มีอยู่แล้ว รวมถึงวิธีที่การล็อกบัญชีสามารถนำไปใช้กับการเข้าสู่ระบบเครือข่าย เช่น RDP ขึ้นอยู่กับการกำหนดค่าและเวอร์ชัน อย่าคิดว่าผู้ดูแลระบบที่มีอยู่จะทำงานเหมือนกับบัญชีผู้ใช้ปกติ และทดสอบในลักษณะที่ควบคุมได้ก่อนที่คุณจะพึ่งพาพฤติกรรมการล็อกบัญชีเป็นการควบคุมหลัก
สำหรับทีมที่ต้องการชั้นการเสริมความแข็งแกร่งที่ใช้งานได้จริง TSplus Advanced Security รวมถึงการป้องกันการโจมตีแบบ brute-force ที่ออกแบบมาเพื่อหยุดยั้งความพยายามที่ไม่ได้รับอนุญาตซ้ำ ๆ ที่ระดับโฮสต์ ควรเสริม ไม่ใช่แทนที่ นโยบายการตรวจสอบสิทธิ์ Windows ที่เข้มงวดและการปรับแต่งการล็อกเอาต์อย่างรอบคอบ
การควบคุมเครือข่ายที่ช่วย (และสิ่งที่ผู้คนประเมินค่าสูงเกินไป)
การควบคุมเครือข่ายมักเป็นการปรับปรุงที่รวดเร็วที่สุดที่คุณสามารถทำได้ แต่มีคุณค่าที่แตกต่างกันในโลกจริง คำแนะนำของ Microsoft สำหรับปัญหา brute-force ของ RDP (รวมถึงในสถานการณ์ Azure) มักให้ความสำคัญกับการจำกัดการเชื่อมต่อขาเข้ามากกว่าการเปลี่ยนแปลงที่ดูดี
มูลค่าสูง: การอนุญาต IP. หากคุณสามารถจำกัด RDP ให้เฉพาะที่อยู่ที่รู้จัก (ที่อยู่ IP ออกจากสำนักงาน, ช่วง VPN, ซับเน็ตของบาสตัน, ที่อยู่ IP คงที่ของ MSP) คุณจะกำจัดการจราจรที่เป็นการโจมตีแบบ brute-force ส่วนใหญ่ได้ทันที นอกจากนี้ยังทำให้การตรวจสอบของคุณมีความหมายมากขึ้นเพราะความล้มเหลวที่เหลืออยู่จะมาจากแหล่งที่มาที่น้อยลง
ใช้ประโยชน์ด้วยความระมัดระวัง: การควบคุมตามภูมิศาสตร์และชื่อเสียง การบล็อกภูมิศาสตร์และชื่อเสียงของ IP สามารถลดเสียงรบกวนได้ แต่ก็อาจบล็อกผู้ใช้ที่ถูกต้องตามกฎหมายที่เดินทาง เชื่อมต่อจากเครือข่ายโรมมิ่ง หรือเข้ามาผ่าน CGNAT ผู้โจมตีสามารถใช้ VPN และพร็อกซี่ได้เช่นกัน ดังนั้นควรถือว่าการควบคุมภูมิศาสตร์เป็นการลดความเสี่ยง ไม่ใช่การรับประกัน
ประเมินสูงเกินไป: การเปลี่ยนพอร์ต RDP. การอนุญาต IP ช่วยลดการเปิดเผย RDP brute-force อย่างมีนัยสำคัญ ในขณะที่การเปลี่ยนพอร์ต RDP จะช่วยลดการสแกนที่เกิดขึ้นโดยบังเอิญและไม่ควรพึ่งพาเป็นการป้องกันหลัก การเปลี่ยนพอร์ตสามารถซื้อเวลาในระหว่างเหตุการณ์ แต่ไม่สามารถแก้ไขปัญหาการพ่นรหัสผ่านจากผู้กระทำที่มุ่งมั่นซึ่งสามารถค้นพบพอร์ตได้
ในสภาพแวดล้อมที่ทีมต้องการการบังคับใช้ที่ง่ายกว่าการดูแลชุดกฎที่ซับซ้อนด้วยตนเอง TSplus Advanced Security จะเพิ่ม การป้องกันทางภูมิศาสตร์และการควบคุมตาม IP ซึ่งสามารถนำไปใช้ได้อย่างสม่ำเสมอทั่วทั้งเซิร์ฟเวอร์
การตรวจสอบและการตรวจจับ: ควรบันทึก ออกการแจ้งเตือน และตรวจสอบอะไร
การโจมตีแบบ Brute force เป็นหนึ่งในปัญหาที่ดูชัดเจนเมื่อมองย้อนกลับไปและมีค่าใช้จ่ายสูงเมื่อคุณสังเกตเห็นมันช้า เป้าหมายของการตรวจสอบไม่ใช่การนับการเข้าสู่ระบบที่ล้มเหลวทุกครั้งตลอดไป แต่คือการตรวจจับรูปแบบที่ผิดปกติในระยะเริ่มต้นและตรวจสอบว่าความพยายามเหล่านั้นเคยกลายเป็นการเข้าสู่ระบบที่สำเร็จหรือไม่
ตรวจสอบการเพิ่มขึ้นที่ผิดปกติในล็อกออนที่ล้มเหลว (มักจะเป็น Event ID 4625) และแจ้งเตือนเกี่ยวกับรูปแบบที่บ่งชี้ถึงการพยายามใช้รหัสผ่านแบบสุ่มหรือการล็อกอินที่ประสบความสำเร็จหลังจากความล้มเหลวซ้ำแล้วซ้ำเล่า คำแนะนำในการแก้ไขปัญหาของ Microsoft เกี่ยวกับการโจมตีแบบ brute-force เน้นย้ำถึงวัตถุประสงค์เดียวกัน (4625) เนื่องจากเป็นจุดเริ่มต้นที่ใช้งานได้เมื่อผู้ดูแลระบบพยายามที่จะกู้คืนการเข้าถึงและเข้าใจขอบเขต
สำหรับการดำเนินงานประจำวัน ให้มุ่งเน้นไปที่คำถามการสอบสวนสามข้อ:
การจราจรเป็นภายนอกหรือภายใน? IP สาธารณะภายนอกที่เข้าถึงจุดเชื่อมต่อสาธารณะชี้ไปที่ปัญหาการเปิดเผย ข้อมูล IP ภายในอาจบ่งชี้ถึงจุดสิ้นสุดที่ถูกโจมตีหรือบัญชีบริการที่กำหนดค่าไม่ถูกต้อง
มันเป็นบัญชีเดียวหรือหลายบัญชี? บัญชีเดียวแนะนำการโจมตีแบบ brute force ขณะที่หลายบัญชีที่มีความพยายามต่ำแนะนำการพ่นรหัสผ่าน
บัญชีใดประสบความสำเร็จหลังจากการระเบิดหรือไม่? การเข้าสู่ระบบที่สำเร็จในเวลาไม่นานหลังจากความล้มเหลวซ้ำ ๆ เป็นการเชื่อมโยงที่มีความสำคัญสูงที่ควรตรวจสอบ โดยเฉพาะสำหรับบัญชีที่มีสิทธิพิเศษ
หากคุณยังไม่ได้รวมศูนย์บันทึก Windows ให้พิจารณาการส่งต่อเหตุการณ์ Windows หรือ SIEM ที่มีอยู่ของคุณเพื่อให้คุณสามารถแจ้งเตือนข้ามเซิร์ฟเวอร์หลายเครื่องได้อย่างสม่ำเสมอ สำหรับทีมที่ต้องการความง่าย การแจ้งเตือนและการมองเห็นประวัติในช่วงที่มีการโจมตีสูง , TSplus การตรวจสอบเซิร์ฟเวอร์ สามารถช่วยคุณติดตามสุขภาพและความพร้อมใช้งานของเซิร์ฟเวอร์ควบคู่ไปกับการบันทึกความปลอดภัยของคุณ
วิธีการบล็อกอัตโนมัติ (และวิธีหลีกเลี่ยงผลบวกเท็จ)
การตอบสนองด้วยมือไม่สามารถขยายได้เมื่อโฮสต์ของคุณอยู่ในเครือข่ายอินเทอร์เน็ต อัตโนมัติเป็นที่ที่ทีมงานหลายทีมสามารถกลับมาควบคุมได้ ตราบใดที่มันถูกออกแบบมาให้สามารถย้อนกลับได้และปกป้องการเข้าถึงที่ถูกต้องตามกฎหมาย อัตโนมัติที่ปลอดภัยที่สุดจะบล็อกการเข้าสู่ระบบที่ล้มเหลวซ้ำ ๆ ด้วยการห้ามที่มีระยะเวลาจำกัดและรายการอนุญาตที่ชัดเจน และต้องคำนึงถึงที่อยู่ IP ที่แชร์เพื่อหลีกเลี่ยงการบล็อกผู้ใช้ที่ถูกต้องตามกฎหมาย
การทำงานอัตโนมัติในทางปฏิบัติเป็นอย่างไร
วิธีการทั่วไป ได้แก่ โมดูลไฟร์วอลล์โฮสต์ที่ตรวจจับความล้มเหลวซ้ำและแบน IP ชั่วคราว, ฟีเจอร์ EDR ที่ตรวจจับพฤติกรรมการเดารหัสผ่าน, และสคริปต์ที่วิเคราะห์บันทึกความปลอดภัยและใช้กฎไฟร์วอลล์แบบไดนามิก การควบคุมที่มุ่งเน้นเกตเวย์ (RD Gateway, VPN, bastion) มักลดความจำเป็นในการบล็อกที่ระดับโฮสต์อย่างเข้มงวด เนื่องจากแหล่งที่มาไม่รู้จักมีน้อยที่จะเข้าถึงเซิร์ฟเวอร์
ที่ที่ทีมงานถูกเผา
NAT ที่ใช้ร่วมกันและ CGNAT หากผู้ใช้ที่ถูกต้องจำนวนมากมาจากที่อยู่ IP สาธารณะเดียว (สำนักงานสาขา, เครือข่ายโรงแรม, ผู้ให้บริการอินเทอร์เน็ตบางราย) การบล็อกที่อยู่ IP นั้นอาจตัดการเข้าถึงของผู้ใช้ที่ดีพร้อมกับผู้โจมตี การห้ามชั่วคราวและรายการอนุญาตที่รู้จักดีช่วยลดขอบเขตของการโจมตี
การบล็อกเส้นทางการจัดการของคุณเอง ควรอนุญาตให้ IP ของ VPN, ซับเน็ตบาสเตียน และการจัดการ MSP ก่อนที่คุณจะเปิดใช้งานการบล็อกที่เข้มงวด จัดทำเอกสารเส้นทางการเข้าถึงในกรณีฉุกเฉินที่ไม่พึ่งพาเส้นทางเครือข่ายเดียวกัน
การหยุดทำงานที่เกิดจากการล็อกเอาต์ หากการควบคุมของคุณมีเพียงการล็อกบัญชี ผู้โจมตีสามารถเปลี่ยนให้เป็นการปฏิเสธบริการได้ จับคู่กฎการล็อกบัญชีกับการลดการเปิดเผยและการควบคุมตาม IP เพื่อให้โฮสต์ไม่กลายเป็นจุดคอขวด
TSplus Advanced Security เพิ่มการป้องกันการโจมตีแบบ brute-force ที่มีประสิทธิภาพ IP และการควบคุมทางภูมิศาสตร์ และการเสริมความแข็งแกร่งที่มุ่งเน้นการป้องกันแรนซัมแวร์สำหรับเซิร์ฟเวอร์ Windows ซึ่งสามารถช่วยให้คุณลดความพยายามในการเข้าสู่ระบบ RDP ที่ซ้ำซากโดยไม่ต้องติดตั้งระบบรักษาความปลอดภัยที่มีน้ำหนักมาก
แนวทางปฏิบัติที่เหมาะสมสำหรับสภาพแวดล้อม SMB และ MSP
SMBs และ MSPs ต้องการมาตรฐานที่สามารถทำซ้ำได้ ทดสอบได้ และไม่น่าจะทำให้การดำเนินงานประจำวันหยุดชะงัก คำแนะนำด้านความปลอดภัยของ Microsoft สำหรับ Remote Desktop สนับสนุนหลักการทั่วไปเดียวกัน: ลดการเปิดเผยโดยตรง จากนั้นเสริมความแข็งแกร่งในการเข้าถึงและติดตามอย่างกระตือรือร้น
- ลดการเปิดเผย RDP ต่ออินเทอร์เน็ตโดยตรงเมื่อเป็นไปได้ และจัดเส้นทางการเข้าถึงผ่าน VPN, เกตเวย์ หรือรูปแบบป้อมปราการ
- หาก RDP ต้องยังคงเข้าถึงได้ ให้จำกัดการเข้าถึงจากภายนอกไปยัง IP ที่อนุญาตเพียงเล็กน้อยและตรวจสอบเป็นประจำ
- เปิดใช้งานการตรวจสอบระดับเครือข่าย (NLA) และกำหนดให้มีการใช้ข้อมูลรับรองที่แข็งแกร่งและไม่ซ้ำกันสำหรับผู้ใช้ที่โต้ตอบทั้งหมด
- ปรับเข้มการเข้าถึงที่มีสิทธิพิเศษ: ลดจำนวนสมาชิกผู้ดูแลระบบท้องถิ่นและตรวจสอบสมาชิกผู้ใช้ Remote Desktop.
- ตั้งค่านโยบายการล็อกบัญชีโดยเจตนา (เกณฑ์, ระยะเวลา, รีเซ็ตเคาน์เตอร์) และทดสอบเพื่อหลีกเลี่ยงการหยุดทำงานที่เกิดจากการล็อกบัญชี.
- ตรวจสอบการเข้าสู่ระบบที่ล้มเหลว (เช่น รหัสเหตุการณ์ 4625) และตรวจสอบรูปแบบความสำเร็จหลังจากความล้มเหลวอย่างรวดเร็ว
- รักษา Windows, ส่วนประกอบที่เกี่ยวข้องกับ RDP และบริการที่เชื่อมต่อกับอินเทอร์เน็ตให้มีการอัปเดตตามกำหนดเวลา
- การเข้าถึงแบบเบรกกลาสของเอกสาร รวมถึงวิธีที่คุณจะกู้คืนการเข้าถึงคอนโซลหากกฎเครือข่ายบล็อกการเข้าถึงระยะไกล
หากคุณต้องการการตรวจสอบที่มีโครงสร้าง ใช้ของเรา การตรวจสอบความปลอดภัย RDP: รายการตรวจสอบ 20 ข้อสำหรับปี 2026 .
สำหรับ MSPs ให้ทำการมาตรฐานสิ่งที่คุณสามารถทำได้ (เทมเพลต GPO, มาตรฐานไฟร์วอลล์, รายการ IP การจัดการที่อนุญาต) และเก็บรายการอนุญาตและข้อยกเว้นเฉพาะลูกค้าให้ชัดเจน หากคุณต้องการชั้นการป้องกันที่ใช้งานได้จริงในเซิร์ฟเวอร์ของลูกค้าหลายเครื่อง TSplus Advanced Security สามารถนำไปใช้เป็นส่วนหนึ่งของแพ็คเกจความปลอดภัยการเข้าถึงระยะไกลมาตรฐาน และ TSplus Remote Access สามารถสนับสนุนท่าที “ไม่เปิดเผย RDP ดิบโดยตรง” สำหรับแอปพลิเคชันและเดสก์ท็อปที่เผยแพร่
FAQ
การเปลี่ยนพอร์ต RDP เริ่มต้นจะหยุดการโจมตีแบบ brute-force หรือไม่?
การเปลี่ยนพอร์ต RDP สามารถลดเสียงการสแกนที่เกิดขึ้นโดยบังเอิญ และแนวทางการจัดการเหตุการณ์ของ Microsoft เองได้กล่าวถึงมันว่าเป็นการบรรเทาชั่วคราวในบางสถานการณ์ แต่ไม่ได้หยุดการเดาที่มุ่งเป้า ให้ถือเป็นกลยุทธ์รองและมุ่งเน้นไปที่การลดการเปิดเผย (การอนุญาตในรายการ, เกตเวย์, VPN, ฐานที่มั่น) และการเสริมความแข็งแกร่งในการตรวจสอบสิทธิ์ก่อน
นโยบายการตั้งค่า Windows ใดที่สำคัญที่สุดสำหรับการป้องกันการโจมตีแบบ brute-force ของ RDP?
เริ่มต้นด้วยการเปิดใช้งาน NLA สำหรับ RDP, การจำกัดผู้ที่มีสิทธิ์เข้าสู่ระบบผ่าน Remote Desktop, และการกำหนดนโยบายการล็อกบัญชี (เกณฑ์, ระยะเวลา, รีเซ็ตเคาน์เตอร์) ตามที่ Microsoft Learn ได้บันทึกไว้ นโยบายรหัสผ่านที่เข้มงวดและสิทธิ์ผู้ดูแลระบบที่น้อยที่สุดยังช่วยลดโอกาสที่การเดารหัสผ่านจะนำไปสู่การละเมิดที่มีความหมาย
การตั้งค่าการล็อกบัญชีสามารถทำให้การหยุดทำงานของ RDP แย่ลงในระหว่างการโจมตีได้หรือไม่?
ใช่ หาก RDP ถูกเปิดเผยอย่างกว้างขวาง ผู้โจมตีสามารถกระตุ้นการล็อกเอาต์สำหรับผู้ใช้จริงได้ ซึ่งกลายเป็นปัญหาการปฏิเสธบริการ นั่นคือเหตุผลที่ลำดับที่แนะนำคือการลดการเปิดเผยก่อน จากนั้นปรับการล็อกเอาต์และการควบคุมในลักษณะที่สมดุลระหว่างความปลอดภัยกับความพร้อมใช้งาน
การตรวจสอบระดับเครือข่าย (NLA) เพียงพอหรือไม่ในการรักษาความปลอดภัย RDP?
NLA เป็นพื้นฐานที่สำคัญ แต่ไม่สามารถป้องกันการพ่นรหัสผ่านหรือการบรรจุข้อมูลประจำตัวได้ด้วยตัวเอง คุณยังต้องการการลดการเปิดเผย การดูแลรักษาข้อมูลประจำตัวที่แข็งแกร่ง การควบคุมหรือพฤติกรรมการล็อกเอาต์ที่สมเหตุสมผล และการตรวจสอบรูปแบบการลงชื่อเข้าใช้ที่ไม่ปกติ
ฉันควรตรวจสอบอะไรเพื่อให้ตรวจจับการพยายามโจมตีแบบ brute-force RDP ได้เร็ว?
มองหาการเพิ่มขึ้นที่ผิดปกติในความล้มเหลวในการเข้าสู่ระบบ ซึ่งมักจะปรากฏเป็น Event ID 4625 โดยเฉพาะเมื่อมาจาก IP ภายนอกหลายตัวหรือเป้าหมายชื่อผู้ใช้หลายชื่อในระยะเวลาสั้น ๆ นอกจากนี้ยังควรตรวจสอบการเข้าสู่ระบบที่สำเร็จซึ่งเกิดขึ้นไม่นานหลังจากความล้มเหลวซ้ำ ๆ เพราะอาจบ่งชี้ถึงรหัสผ่านที่ถูกเดาหรือใช้ซ้ำ
สรุป: ให้ความสำคัญกับการลดการเปิดเผยข้อมูล จากนั้นเสริมความแข็งแกร่งและทำให้เป็นอัตโนมัติ
การป้องกันการโจมตีแบบ brute force ของ RDP ไม่ใช่การตั้งค่าเดียว มันเป็นวิธีการที่มีหลายชั้นซึ่งทำงานได้ดีที่สุดตามลำดับนี้: ลดหรือกำจัดการเปิดเผยโดยตรง, ทำให้การตรวจสอบความถูกต้องแข็งแกร่ง (NLA, ข้อมูลรับรองที่แข็งแกร่ง, สิทธิ์น้อยที่สุด, การล็อกหรือการจำกัดที่สมเหตุสมผล), ใช้การควบคุมเครือข่ายที่จำกัดการเข้าถึงจริง ๆ, ตรวจสอบรูปแบบที่มีความหมาย, และทำให้การบล็อกอัตโนมัติอย่างระมัดระวังเพื่อหลีกเลี่ยงผลบวกเท็จ.
บันทึกการเปลี่ยนแปลงของคุณ ทดสอบในเวลานอกเวลาทำการเมื่อเป็นไปได้ และตรวจสอบให้แน่ใจว่าทางออกฉุกเฉินของคุณยังทำงานได้หลังจากการปรับเปลี่ยนไฟร์วอลล์และการล็อกเอาต์ หากคุณต้องการทำให้การป้องกันเหล่านี้ใช้งานได้ด้วยความพยายามน้อยลง TSplus Advanced Security สามารถช่วยในการป้องกันการโจมตีแบบ brute-force และการจำกัดการเข้าถึง และ TSplus Remote Access สามารถให้โมเดลการจัดส่งที่ปลอดภัยยิ่งขึ้นสำหรับแอปพลิเคชัน Windows และเดสก์ท็อปที่เผยแพร่ผ่านพอร์ทัลเว็บ สำหรับการประเมิน คุณสามารถ ดาวน์โหลด การทดลองและการตรวจสอบ ราคา .