ฉันมักจะอ่านความคิดเห็นว่าการเปิดพอร์ต RDP (Remote Desktop Protocol) ไว้บนอินเทอร์เน็ตนั้นไม่ปลอดภัยอย่างยิ่งและไม่ควรทำ แต่คุณต้องให้สิทธิ์การเข้าถึง RDP ผ่าน VPN หรือจากที่อยู่ IP “สีขาว” บางแห่งเท่านั้น
ฉันดูแลระบบ Windows Servers หลายแห่งสำหรับบริษัทขนาดเล็กที่ฉันได้รับมอบหมายให้เข้าถึง Windows Server จากระยะไกลสำหรับนักบัญชี นี่คือเทรนด์ยุคใหม่ - การทำงานจากที่บ้าน ฉันตระหนักได้อย่างรวดเร็วว่าการทรมานนักบัญชี VPN เป็นงานที่ไร้คุณค่า และการรวบรวม IP ทั้งหมดสำหรับรายการที่ปลอดภัยจะไม่ทำงาน เนื่องจากที่อยู่ IP ของผู้คนเป็นแบบไดนามิก
ดังนั้นฉันจึงใช้เส้นทางที่ง่ายที่สุด - ส่งต่อพอร์ต RDP ไปยังด้านนอก เพื่อให้เข้าถึงได้ ตอนนี้นักบัญชีจำเป็นต้องเรียกใช้ RDP และป้อนชื่อโฮสต์ (รวมถึงพอร์ต) ชื่อผู้ใช้ และรหัสผ่าน
ในบทความนี้ ฉันจะแบ่งปันประสบการณ์ของฉัน (เชิงบวกและไม่ค่อยเป็นบวก) และคำแนะนำ
ความเสี่ยง
คุณกำลังเสี่ยงอะไรโดยการเปิดพอร์ต RDP?
1) การเข้าถึงข้อมูลที่ละเอียดอ่อนโดยไม่ได้รับอนุญาต
หากมีคนเดารหัสผ่าน RDP พวกเขาจะสามารถรับข้อมูลที่คุณต้องการเก็บไว้เป็นส่วนตัว: สถานะบัญชี ยอดคงเหลือ ข้อมูลลูกค้า ...
2) การสูญเสียข้อมูล
เช่น อันเป็นผลมาจากไวรัสแรนซัมแวร์
หรือการกระทำโดยเจตนาของผู้โจมตี
3) การสูญเสียเวิร์กสเตชัน
พนักงานจำเป็นต้องทำงาน แต่ระบบถูกโจมตีและจำเป็นต้องติดตั้งใหม่/กู้คืน/กำหนดค่า
4) การประนีประนอมของเครือข่ายท้องถิ่น
หากผู้โจมตีสามารถเข้าถึงคอมพิวเตอร์ Windows จากคอมพิวเตอร์เครื่องนี้เขาจะสามารถเข้าถึงระบบที่ไม่สามารถเข้าถึงได้จากภายนอกจากอินเทอร์เน็ต ตัวอย่างเช่น การแชร์ไฟล์ ไปยังเครื่องพิมพ์เครือข่าย เป็นต้น
ฉันมีกรณีที่ Windows Server จับแรนซัมแวร์ได้
และแรนซัมแวร์นี้ได้เข้ารหัสไฟล์ส่วนใหญ่ในไดรฟ์ C: ก่อน จากนั้นจึงเริ่มเข้ารหัสไฟล์บน NAS ผ่านเครือข่าย เนื่องจาก NAS นั้นเป็น Synology ซึ่งมีการกำหนดค่าสแนปช็อต ฉันจึงกู้คืน NAS ได้ใน 5 นาที และติดตั้ง Windows Server ใหม่ตั้งแต่เริ่มต้น
ข้อสังเกตและข้อเสนอแนะ
ฉันตรวจสอบเซิร์ฟเวอร์ Windows โดยใช้ ซึ่งส่งบันทึกไปยัง ElasticSearch Kibana มีการแสดงภาพข้อมูลหลายรายการ และฉันก็ตั้งค่าแดชบอร์ดแบบกำหนดเองด้วย
การตรวจสอบตัวเองไม่ได้ป้องกัน แต่ช่วยกำหนดมาตรการที่จำเป็น
ต่อไปนี้เป็นข้อสังเกตบางประการ:
ก) RDP จะถูกบังคับอย่างดุร้าย
บนเซิร์ฟเวอร์เครื่องหนึ่ง ฉันติดตั้ง RDP ไม่ใช่บนพอร์ตมาตรฐาน 3389 แต่ติดตั้งบน 443 - ฉันจะปลอมตัวเป็น HTTPS มันอาจจะคุ้มค่าที่จะเปลี่ยนพอร์ตจากพอร์ตมาตรฐาน แต่มันก็ไม่ได้ผลดีนัก นี่คือสถิติจากเซิร์ฟเวอร์นี้:
จะเห็นได้ว่าในหนึ่งสัปดาห์มีการพยายามเข้าสู่ระบบผ่าน RDP ที่ไม่สำเร็จเกือบ 400 ครั้ง
จะเห็นได้ว่ามีการพยายามเข้าสู่ระบบจากที่อยู่ IP 55 รายการ (ที่อยู่ IP บางส่วนถูกบล็อกโดยฉันแล้ว)
นี่เป็นการชี้ให้เห็นข้อสรุปโดยตรงว่าคุณต้องตั้งค่า failed2ban แต่
ไม่มียูทิลิตี้ดังกล่าวสำหรับ Windows
มีโปรเจ็กต์ที่ถูกละทิ้งสองสามโปรเจ็กต์บน Github ที่ดูเหมือนจะทำเช่นนี้ แต่ฉันยังไม่ได้ลองติดตั้งด้วยซ้ำ:
นอกจากนี้ยังมีค่าสาธารณูปโภคที่ต้องเสียเงินด้วย แต่ฉันไม่ได้พิจารณา
หากคุณรู้จักยูทิลิตี้โอเพ่นซอร์สเพื่อจุดประสงค์นี้ โปรดแบ่งปันในความคิดเห็น
บันทึก: ความคิดเห็นแนะนำว่าพอร์ต 443 เป็นตัวเลือกที่ไม่ดี และควรเลือกพอร์ตสูง (32000+) จะดีกว่า เนื่องจาก 443 ได้รับการสแกนบ่อยกว่า และการจดจำ RDP บนพอร์ตนี้ก็ไม่ใช่ปัญหา
b) มีชื่อผู้ใช้บางอย่างที่ผู้โจมตีชอบ
จะเห็นได้ว่าการค้นหานั้นดำเนินการในพจนานุกรมที่มีชื่อต่างกัน
แต่นี่คือสิ่งที่ฉันสังเกตเห็น: มีความพยายามหลายครั้งที่ใช้ชื่อเซิร์ฟเวอร์เป็นข้อมูลเข้าสู่ระบบ คำแนะนำ: อย่าใช้ชื่อเดียวกันสำหรับคอมพิวเตอร์และผู้ใช้ นอกจากนี้ บางครั้งดูเหมือนว่าพวกเขากำลังพยายามแยกวิเคราะห์ชื่อเซิร์ฟเวอร์ ตัวอย่างเช่น สำหรับระบบที่ชื่อ DESKTOP-DFTHD7C ความพยายามเข้าสู่ระบบมากที่สุดคือชื่อ DFTHD7C:
ดังนั้น หากคุณมีคอมพิวเตอร์ DESKTOP-MARIA คุณอาจพยายามเข้าสู่ระบบในฐานะผู้ใช้ MARIA
อีกสิ่งหนึ่งที่ฉันสังเกตเห็นจากบันทึก: ในระบบส่วนใหญ่ ความพยายามเข้าสู่ระบบส่วนใหญ่จะใช้ชื่อ "ผู้ดูแลระบบ" และนี่ไม่ใช่โดยไม่มีเหตุผลเพราะใน Windows หลายเวอร์ชันมีผู้ใช้รายนี้อยู่ ยิ่งกว่านั้นมันไม่สามารถลบได้ สิ่งนี้ทำให้งานของผู้โจมตีง่ายขึ้น: แทนที่จะเดาชื่อและรหัสผ่าน คุณเพียงแค่เดารหัสผ่านเท่านั้น
อย่างไรก็ตาม ระบบที่จับแรนซัมแวร์ได้นั้นมีผู้ดูแลระบบและรหัสผ่าน Murmansk#9 ฉันยังไม่แน่ใจว่าระบบนั้นถูกแฮ็กได้อย่างไร เพราะฉันเริ่มติดตามหลังจากเหตุการณ์นั้นเกิดขึ้น แต่ฉันคิดว่าน่าจะมีการใช้ทรัพยากรมากเกินไป
ดังนั้นหากไม่สามารถลบผู้ใช้ที่เป็นผู้ดูแลระบบได้ คุณควรทำอย่างไร? คุณสามารถเปลี่ยนชื่อได้!
คำแนะนำจากย่อหน้านี้:
- ห้ามใช้ชื่อผู้ใช้ในชื่อคอมพิวเตอร์
- ตรวจสอบให้แน่ใจว่าไม่มีผู้ใช้ที่เป็นผู้ดูแลระบบในระบบ
- ใช้รหัสผ่านที่รัดกุม
ดังนั้นฉันจึงเฝ้าดู Windows Servers หลายตัวภายใต้การควบคุมของฉันที่ถูกบังคับอย่างดุเดือดมาประมาณสองสามปีแล้วและไม่ประสบความสำเร็จ
ฉันจะรู้ได้อย่างไรว่าไม่สำเร็จ?
เนื่องจากในภาพหน้าจอด้านบน คุณจะเห็นว่ามีบันทึกการโทร RDP ที่สำเร็จซึ่งประกอบด้วยข้อมูล:
- จากไอพีไหน
- จากคอมพิวเตอร์เครื่องใด (ชื่อโฮสต์)
- ชื่อผู้ใช้
- ข้อมูลจีโอไอพี
และฉันตรวจสอบที่นั่นเป็นประจำ - ไม่พบความผิดปกติ
อย่างไรก็ตาม หาก IP ใดถูกบังคับใช้อย่างดุร้ายเป็นพิเศษ คุณสามารถบล็อก IP แต่ละรายการ (หรือซับเน็ต) เช่นนี้ใน PowerShell:
New-NetFirewallRule -Direction Inbound -DisplayName "fail2ban" -Name "fail2ban" -RemoteAddress ("185.143.0.0/16", "185.153.0.0/16", "193.188.0.0/16") -Action Blockอย่างไรก็ตาม Elastic นอกเหนือจาก Winlogbeat ก็มีเช่นกัน ซึ่งสามารถตรวจสอบไฟล์และกระบวนการในระบบได้ นอกจากนี้ยังมีแอปพลิเคชัน SIEM (ข้อมูลความปลอดภัยและการจัดการเหตุการณ์) ใน Kibana ฉันลองทั้งสองอย่างแล้ว แต่ไม่เห็นประโยชน์มากนัก ดูเหมือนว่า Auditbeat จะมีประโยชน์มากกว่าสำหรับระบบ Linux และ SIEM ยังไม่ได้แสดงสิ่งที่เข้าใจให้ฉันฟังเลย
คำแนะนำสุดท้าย:
- ทำการสำรองข้อมูลอัตโนมัติเป็นประจำ
- ติดตั้งการอัปเดตความปลอดภัยในเวลาที่เหมาะสม
โบนัส: รายชื่อผู้ใช้ 50 รายที่ใช้บ่อยที่สุดในการพยายามเข้าสู่ระบบ RDP
"ชื่อผู้ใช้: จากมากไปน้อย"
นับ
dfthd7c (ชื่อโฮสต์)
842941
winsrv1 (ชื่อโฮสต์)
266525
ADMINISTRATOR
180678
ผู้บริหาร
163842
ผู้บริหาร
53541
ไมเคิล
23101
เซิร์ฟเวอร์
21983
สตีฟ
21936
จอห์น
21927
พอล
21913
การต้อนรับ
21909
ไมค์
21899
สำนักงาน
21888
สแกนเนอร์
21887
การสแกน
21867
เดวิด
21865
คริส
21860
เจ้าของ
21855
ผู้จัดการ
21852
administrateur
21841
ไบรอัน
21839
ผู้บริหาร
21837
เครื่องหมาย
21824
บุคลากร
21806
ADMIN
12748
ROOT
7772
ผู้ดูแลระบบ
7325
การสนับสนุน
5577
ฝ่ายสนับสนุน
5418
USER
4558
ผู้ดูแลระบบ
2832
ทดสอบ
1928
MySql
1664
ผู้ดูแลระบบ
1652
เกสต์
1322
ผู้ใช้ 1
1179
สแกนเนอร์
1121
SCAN
1032
ผู้ดูแลระบบ
842
ผู้ดูแลระบบ1
525
การสำรองข้อมูล
518
MySqlAdmin
518
การรับ
490
ผู้ใช้ 2
466
TEMP
452
SQLADMIN
450
ผู้ใช้ 3
441
1
422
MANAGER
418
OWNER
410
ที่มา: will.com