การรักษาความปลอดภัย Windows VPS โดยไม่ทำให้กลายเป็นโครงการวิจัย ให้เริ่มจากการอัปเดตแพตช์ เสริมความแข็งแกร่งให้ RDP ด้วย NLA และรายการ IP ที่อนุญาต บังคับใช้การล็อกบัญชี รักษากฎไฟร์วอลล์ขาเข้าให้รัดกุม เปิดการป้องกันแบบเรียลไทม์ของ Defender ไว้ และทดสอบการสำรองข้อมูล ไม่ว่าจะใช้สำหรับการทำงานระยะไกล เว็บไซต์ หรือแอป เป้าหมายก็เรียบง่าย นั่นคือ ลดพื้นที่การโจมตี ปกป้องตัวตน และเฝ้าดูบันทึกของคุณ
เริ่มจาก Patch: อัปเดต, ไดรเวอร์, และ Roles
ก่อนอื่นใดให้ patch ก่อนเสมอ เซิร์ฟเวอร์ที่เปิดสาธารณะโดยไม่ได้ patch คือเป้าหมายที่โจมตีได้ง่ายที่สุด และช่องโหว่เหล่านั้นมักเป็นจุดเริ่มต้นของการบุกรุก อัปเดตความปลอดภัยอย่างต่อเนื่อง ถอด Windows roles ที่ไม่ใช้ออก และวางแผนรีบูตให้เป็นตารางที่ทีมรับได้ งานน่าเบื่อเหล่านี้แหละที่กันปัญหาใหญ่ได้
- ตั้งค่า Windows Update ให้ติดตั้งอัปเดตความปลอดภัยตามรอบที่กำหนด และจัดช่วง maintenance window ให้ตรงกับเวลาทำงานที่เหมาะสมกับองค์กรคุณ
- ถอด roles และ features ที่ไม่จำเป็นออก เช่น IIS modules รุ่นเก่า หรือคอมโพเนนต์ SMB 1.0
- อัปเดตไดรเวอร์ firmware และแอปพลิเคชันตามรอบเวลาที่กำหนด แล้วรีบูตตามตาราง ไม่ใช่ทิ้งไว้สองเดือน
- หากเซิร์ฟเวอร์ VPS ใช้ IP สาธารณะ ตรวจสอบการเปิดเผย port ใน cloud portal และปิดสิ่งที่ไม่จำเป็น
เริ่มจากตรงนี้ และจดบันทึกการเปลี่ยนแปลงอย่างง่ายทุกเดือน เพื่อให้คุณตอบได้ว่ามีอะไรเปลี่ยนไปบ้างและเมื่อใด นั่นคือการปูทางสู่งานด้านตัวตนในลำดับถัดไป ซึ่งเป็นจุดที่ได้ผลลัพธ์มากที่สุด
Identity พื้นฐาน: รหัสผ่านที่แข็งแกร่ง, เส้นทาง MFA
Identity คือประตูหน้าของคุณ Passphrase ยาวและการยืนยันตัวตนสองชั้นสกัดการโจมตีทั่วไปได้มาก และติดตั้งได้ไม่ยากแม้บน Windows Server ขนาดเล็ก
- ใช้วลีรหัสผ่านอย่างน้อย 14 ตัวอักษร หากเซิร์ฟเวอร์เข้าร่วมโดเมน ให้เพิ่มการกรองรหัสผ่านต้องห้ามผ่านระบบจัดการตัวตนของคุณ
- เพิ่ม MFA ให้กับ Remote Desktop ผ่าน RD Gateway, VPN หรือผู้ให้บริการข้อมูลรับรองจากภายนอก
- ใช้บัญชี admin แยกที่มีชื่อระบุชัดเจน และทำงานประจำวันด้วยบัญชีผู้ใช้มาตรฐาน
- ตรวจสอบว่าใครสามารถล็อกอินผ่าน RDP ได้บ้าง ตัดบัญชีที่ไม่จำเป็นออก และยึดหลัก least privilege
ทั้งหมดนี้ไม่ใช่เคล็ดลับพิเศษ แต่คือความสม่ำเสมอ และความสม่ำเสมอนี่เองที่นำไปสู่เรื่องบัญชีผู้ใช้โดยตรง หากคุณทำสิ่งนี้ให้ลูกค้า ให้ใส่รายการตรวจสอบเหล่านี้ไว้ในเอกสารส่งมอบ เพื่อให้ผู้ดูแลคนถัดไปทำตามแผนเดิม
ปิดบัญชี 'Administrator' เริ่มต้น และเปิดใช้การล็อกบัญชี
ผู้โจมตีมักทุ่มโจมตีที่ชื่อ Administrator ในตัวระบบ ให้ปิดบัญชีนั้น สร้างบัญชี admin ที่มีชื่อระบุชัดเจนแทน และตั้งค่า account lockout เพื่อทำให้การโจมตีแบบ brute force ช้าลงจนแทบหยุดนิ่ง
- สร้างและทดสอบบัญชีผู้ดูแลที่ตั้งชื่อแยกต่างหาก จากนั้นปิดใช้งานบัญชี Administrator ที่มีมาให้ หากจำเป็นต้องเก็บไว้ ให้เปลี่ยนชื่อและปกป้องไว้เป็นบัญชีสำรองฉุกเฉิน
- ตั้งค่า Account Lockout ที่ 10 ครั้ง, ล็อกบัญชี 15 นาที และรีเซ็ตตัวนับหลัง 15 นาที เพื่อความสมดุลในทางปฏิบัติ
- จัดทำขั้นตอนปลดล็อกบัญชีที่รวดเร็วและชัดเจน เพื่อไม่ให้ฝ่าย support ติดขัดเมื่อใครพิมพ์รหัสผ่านผิด
สำหรับการตั้งค่าพื้นฐานและข้อแลกเปลี่ยน โปรดดู เอกสารอ้างอิงเกณฑ์การล็อกบัญชีของ Microsoft.
การเปลี่ยนแปลงเล็ก ๆ แบบนี้ให้ผลตอบแทนเร็วมากบน VM ที่เปิดสู่สาธารณะ เมื่อปิดประตูเริ่มต้นและตั้งการล็อกบัญชีไว้แล้ว ชั้นถัดไปคือพื้นผิวของ RDP
การเสริมความปลอดภัย RDP: NLA, Port Noise และ IP Allowlists
Remote Desktop เป็นเป้าหมายโปรดของผู้โจมตี ดังนั้นต้องล็อกให้แน่น เปิดใช้ Network Level Authentication ลดพื้นที่เสี่ยงด้วย Allowlists และลดสัญญาณรบกวนจากบอทบนพอร์ต 3389 การเปลี่ยนพอร์ตเพียงอย่างเดียวไม่ใช่มาตรการด้านความปลอดภัย มันแค่ทำให้สแกนเนอร์เงียบลงเท่านั้น
- กำหนดให้เซิร์ฟเวอร์ต้องใช้ NLA เสมอ ไคลเอนต์รุ่นเก่าที่ไม่รองรับไม่ควรเชื่อมต่อเข้ามา
- อนุญาตเฉพาะ IP ต้นทางที่กำหนดสำหรับ TCP 3389 หรือพอร์ตใหม่ และที่ดียิ่งกว่าคือวาง RDP ไว้หลัง VPN หรือ RD Gateway
- เปลี่ยนพอร์ตค่าเริ่มต้นของ RDP เพื่อลดสัญญาณรบกวนจากสแกนเนอร์ แต่อย่าถือว่านี่คือมาตรการด้านความปลอดภัยในตัวเอง
- ปิดการใช้งาน Drive และ Clipboard Redirection หากไม่จำเป็น รวมถึงตั้งค่า Idle Timeout และบังคับให้ยืนยันตัวตนใหม่
การล็อก RDP ช่วยตัดการโจมตีอัตโนมัติได้เกือบทั้งหมด และรายการที่อนุญาตคือสิ่งที่ทำงานหนักที่สุด การจำกัดช่วง IP ต้นทาง หรือ การใช้รายการอนุญาตและการจำกัดพื้นที่ทางภูมิศาสตร์สำหรับ RDP เมื่อผู้ใช้ของคุณอยู่ในภูมิภาคเดียวกันทั้งหมด จะช่วยกันไม่ให้ทราฟฟิกสุ่มเข้าถึงหน้าจอเข้าสู่ระบบได้เลย ซึ่งเข้ากันได้ดีกับกฎไฟร์วอลล์ที่สมเหตุสมผล
กฎ Firewall ที่ Actually ช่วยได้จริง
กฎไฟร์วอลล์ของโฮสต์ควรเรียบง่าย คือปฏิเสธโดยค่าเริ่มต้น แล้วจึงเปิดเฉพาะสิ่งที่คุณใช้จริง ผูกกฎ RDP ไว้กับ IP ต้นทางที่รู้จัก บันทึกทราฟฟิกที่ถูกตัดทิ้ง และกันโปรโตคอลรุ่นเก่าออกไป
- เริ่มต้นด้วยการปฏิเสธ Inbound ทั้งหมดโดยค่าเริ่มต้น แล้วเปิดเฉพาะพอร์ตและโปรโตคอลที่จำเป็น
- กำหนดขอบเขตกฎ RDP ให้เฉพาะ IP ที่รู้จัก ไม่ใช่ 0.0.0.0/0 และบันทึก Traffic ที่ถูกบล็อกไว้ตรวจสอบ
- ใช้ TLS 1.2 ขึ้นไปเท่านั้น และปิดการใช้งาน SMBv1 ทั้งหมด
- ให้ทราฟฟิกขาออกอนุญาตโดยค่าเริ่มต้นไว้ก่อน เว้นแต่คุณจะมีนโยบายควบคุมขาออกที่จัดการอย่างเป็นระบบ และเพิ่มการบล็อกขาออกแบบเจาะจงเฉพาะจุดที่มีความจำเป็นชัดเจนเท่านั้น
กฎที่คุ้มค่ากับการมีอยู่มักเป็นกฎที่ครอบคลุมพอร์ตที่ไม่มีใครตั้งใจเปิด ตัวอย่างมาตรฐานคือ Windows RPC บน TCP 135 และการจำกัดให้เข้าถึงได้เฉพาะจากแหล่งที่เชื่อถือได้ที่ไฟร์วอลล์ของโฮสต์ ก็คือการใช้หลักปฏิเสธโดยปริยายเดียวกันทีละพอร์ต เบื้องหลังพอร์ตเหล่านั้นคือตัวบริการเอง
ทำความสะอาดบริการ: ลบสิ่งที่ไม่ได้ใช้ออก
บริการที่ไม่จำเป็นเพิ่มช่องทางให้ถูกโจมตี ปิดสิ่งที่ไม่ต้องการ แล้วกลับมาตรวจสอบอีกครั้งในหนึ่งเดือนเพื่อดูว่ามีอะไรแอบกลับมาหรือไม่
- หยุดและปิดการใช้งาน Print Spooler หากเซิร์ฟเวอร์ไม่ได้ทำหน้าที่เป็น print host
- ปิดการใช้งาน Remote Registry และโปรโตคอลเก่าที่ไม่ได้ใช้
- ถอนการติดตั้ง role สำหรับเว็บ ไฟล์ หรือ FTP ที่ไม่เกี่ยวข้องกับงานของคุณ
- ตรวจสอบรายการที่เริ่มทำงานอัตโนมัติและงานตามกำหนดเวลา และสืบหาที่มาของสิ่งที่คุณไม่รู้จักก่อนจะปิดใช้งาน
เมื่อจัดบ้านเรียบร้อยแล้ว ให้เพิ่มการป้องกันพื้นฐานด้วย Defender และการตั้งค่า EDR แบบเบา ๆ ใช้แรงไม่มาก แต่เป็นสิ่งที่เห็นผลในการใช้งานประจำวัน
Defender, EDR และการสแกนตามกำหนดเวลา
Microsoft Defender Antivirus ให้พื้นฐานการป้องกันในตัวที่แข็งแรงบน Windows Server รุ่นปัจจุบัน เปิดการป้องกันแบบเรียลไทม์และการป้องกันผ่านคลาวด์ไว้ และใช้การสแกนแบบเร็วสำหรับตารางเวลาปกติ
- หากเซิร์ฟเวอร์ถูกเชื่อมเข้ากับ Defender for Endpoint แล้ว ให้เปิดใช้ Tamper Protection จากที่นั่น
- เปิดการป้องกันแบบ real-time และผ่านคลาวด์ไว้ตลอดเวลา และตั้งค่า quick scan รายสัปดาห์ในช่วงที่มีโหลดน้อย
- ให้รันการสแกนแบบเต็มเฉพาะเมื่อมีการตรวจสอบกรณีเฉพาะ หรือเมื่อเครื่องมือด้านความปลอดภัยของคุณร้องขอเท่านั้น
การตั้งค่าเหล่านี้ให้ความคุ้มครองในระดับการใช้งานประจำวัน ซึ่งเป็นเพียงพื้นฐาน ไม่ใช่โปรแกรมตรวจจับและตอบสนองแบบมีผู้ดูแล และจะได้ผลดีที่สุดเมื่อใช้ควบคู่กับการสำรองข้อมูลที่คุณกู้คืนได้จริง
Backup, Snapshot และการทดสอบการกู้คืน
Windows VPS ที่กู้คืนไม่ได้คือจุดล้มเหลวเพียงจุดเดียวที่อันตรายที่สุด ถ่าย snapshot รายวัน เก็บ backup ไว้นอกเครื่อง และทดสอบการกู้คืนเพื่อให้รู้ว่าแผนใช้งานได้จริง
- Snapshot อัตโนมัติรายวัน พร้อมเก็บข้อมูลย้อนหลัง 7 ถึง 14 วัน หรือนานกว่านั้นสำหรับงานที่ต้องปฏิบัติตามข้อกำหนด
- Backup นอกเครื่องไปยังผู้ให้บริการ region หรือ bucket ที่ใช้ credentials ต่างออกไป
- ทดสอบการกู้คืนรายเดือน พร้อมบันทึกขั้นตอนและรายชื่อผู้ติดต่อสำหรับประเมินเวลาในการกู้คืน
พฤติกรรมของสแนปช็อตและการกู้คืนเป็นเรื่องของแพลตฟอร์มพอ ๆ กับเรื่องของนโยบาย และควรตรวจสอบไว้ก่อนถึงวันที่คุณต้องใช้จริง หากคุณกำลังติดตั้งเซิร์ฟเวอร์ใหม่ Windows VPS offers one-click images for Server 2022, 2019, 2016, and 2012 R2.
ข้อควรระวังข้อเดียวตรงนี้สำคัญกว่าเนื้อหาที่เหลือทั้งย่อหน้า Server 2012 ยังอยู่ในรายการอิมเมจเพื่อความเข้ากันได้กับแอปพลิเคชันรุ่นเก่า แต่ไม่ใช่อิมเมจพื้นฐานสำหรับการติดตั้งที่เสริมความแข็งแกร่ง ประกาศวงจรชีวิตของ Server 2012 จาก Microsoft ระบุวันสิ้นสุดการสนับสนุนไว้ที่ 10 ตุลาคม 2023 และการอัปเดตความปลอดภัยแบบขยายเวลาที่ต้องเสียค่าใช้จ่ายจะสิ้นสุดโดยสมบูรณ์ในวันที่ 13 ตุลาคม 2026 ส่วน Server 2016 ก็ใกล้สิ้นสุดการสนับสนุนในเดือนมกราคม 2027 ดังนั้นหากคุณกำลังสร้างระบบใหม่และวางไว้บน IP สาธารณะ ให้เริ่มที่ Server 2019 หรือ 2022
การตรวจสอบและบันทึก: RDP, Security, PowerShell
คุณไม่จำเป็นต้องมี SIEM เพื่อให้ได้ประโยชน์จากบันทึกของ Windows เริ่มจากการเข้าสู่ระบบที่ล้มเหลว เซสชัน RDP ที่สำเร็จ และการบันทึกคำสั่ง PowerShell สัญญาณสามอย่างนี้ให้พื้นฐานการเฝ้าระวังที่ใช้งานได้จริงบนเซิร์ฟเวอร์ขนาดเล็ก
- เปิดการตรวจสอบสำหรับการล็อกอินที่ล้มเหลว และติดตาม Event ID 4625 ที่พุ่งสูงขึ้น.
- ติดตามการเข้าสู่ระบบ RDP ที่สำเร็จด้วย Event ID 4624 โดยกรองเฉพาะ Logon Type 10 (RemoteInteractive) ใช้ 4634 สำหรับการสิ้นสุดเซสชัน และ 4647 สำหรับการออกจากระบบที่ผู้ใช้เป็นผู้เริ่ม
- เปิดใช้การบันทึกคำสั่ง PowerShell ผ่านนโยบาย เพื่อให้อินพุตและเอาต์พุตของ PowerShell มีร่องรอยให้ตรวจสอบ
เมื่อมองเห็นภาพได้แล้ว ให้พิมพ์สรุปการเสริมความแข็งแกร่งแบบหน้าเดียวเก็บไว้ใกล้ตัว จุดนี้คือจุดเริ่มต้นของงานปฏิบัติการประจำวัน เพราะการแจ้งเตือนคือสิ่งที่ผลักดันรอบการอัปเดตแพตช์และการทำความสะอาดครั้งถัดไป
ตาราง Hardening ของ Windows VPS
สรุปย่อที่ดูได้รวดเร็วก่อนเข้า maintenance window หรือหลังการติดตั้งใหม่.
| การควบคุม | การตั้งค่า | เหตุใดจึงสำคัญ |
|---|---|---|
| อัปเดต Windows | ติดตั้งอัปเดตความปลอดภัยอัตโนมัติ | ปิดช่องโหว่สาธารณะได้รวดเร็ว |
| บัญชี Admin | ปิดการใช้งานบัญชีในตัว, ใช้บัญชี admin ที่ตั้งชื่อเอง | กำจัดเป้าหมายที่ผู้โจมตีรู้จักอยู่แล้ว |
| การล็อกบัญชี | พยายาม 10 ครั้ง, ล็อก 15 นาที | ชะลอการโจมตีแบบ brute force |
| NLA | เปิดใช้งาน | บล็อกการเชื่อมต่อ RDP ที่ยังไม่ผ่านการยืนยันตัวตน |
| พอร์ต RDP | ไม่ใช่ค่าเริ่มต้น | ลดสัญญาณรบกวนจาก port scanner |
| รายการ IP ที่อนุญาต | จำกัดขอบเขตการเข้าถึง RDP | ลดพื้นที่เสี่ยง |
| ผนังไฟ | ปฏิเสธการเชื่อมต่อขาเข้าทั้งหมดเป็นค่าเริ่มต้น | เปิดเฉพาะพอร์ตที่จำเป็น |
| SMBv1 | ปิดใช้งาน | กำจัดความเสี่ยงจากโปรโตคอลเก่า |
| Defender | การป้องกันแบบเรียลไทม์ และ Tamper Protection เมื่อใช้ MDE | การป้องกัน malware ขั้นพื้นฐาน |
| การสำรองข้อมูล | สำรองข้อมูลรายวัน + ทดสอบการกู้คืน | ตาข่ายนิรภัยสำหรับการกู้คืนระบบ |
ตารางนี้คือภาพรวมที่มองเห็นได้ในทันที ส่วนถัดไปจะเปรียบเทียบแนวคิดเดียวกันบน Linux ซึ่งช่วยให้ทีมเรียนรู้ข้ามแพลตฟอร์มได้
แถม: เปรียบเทียบกับการ Hardening แบบ Linux
บางทีมใช้หลายแพลตฟอร์มผสมกัน แต่หลักการสำคัญยังเหมือนกันทั้งสองฝั่ง ไม่ว่าจะเป็นการ patch ตามตารางเวลา การตั้งชื่อบัญชี admin ให้ชัดเจน การใช้ SSH หรือ RDP ที่แข็งแกร่ง และ firewall แบบ deny-by-default ถ้า stack ของคุณมีเครื่อง Linux ด้วย แผน Windows นี้ก็สอดคล้องกับ การตั้งค่า Linux VPS อย่างปลอดภัย เป็น baseline ที่ดี ทำให้ playbook ของคุณดูคุ้นเคยในทุกระบบ
มุมมองข้ามแพลตฟอร์มนี้ช่วยให้คุณเลือกแนวทางที่เหมาะกับแต่ละกรณีการใช้งานได้จริง และยังเป็นสิ่งที่คุณส่งต่อให้เพื่อนร่วมงานที่ทำงานกับคีย์ SSH และ iptables ทั้งวันแต่ไม่เคยเปิด Group Policy เลย
เลือกตามการใช้งาน
รายการควบคุมควรตรงกับ workload ของคุณ ตารางสั้นๆ นี้ช่วย map มาตรการต่างๆ เข้ากับ setup ที่พบบ่อย
- เครื่องสำหรับนักพัฒนาคนเดียว: บังคับใช้ NLA อนุญาตเฉพาะช่วง IP ที่คุณใช้อยู่ และจะเปลี่ยนพอร์ต RDP เพื่อลดเสียงรบกวนจากสแกนเนอร์ก็ได้ พร้อมทั้งรันการสแกนแบบเร็วทุกสัปดาห์ เก็บสแนปช็อตรายวันและทดสอบเดือนละครั้ง
- เซิร์ฟเวอร์แอปของธุรกิจขนาดเล็กสำหรับ ERP หรือระบบบัญชี: วาง RDP ไว้หลัง VPN หรือ RD Gateway จำกัดสิทธิ์ผู้ดูแล ปิดโปรโตคอลรุ่นเก่า และเพิ่มการแจ้งเตือนเมื่อเหตุการณ์ 4625 พุ่งสูง
- ฟาร์มรีโมตเดสก์ท็อปสำหรับทีมเล็ก: รวมศูนย์การเข้าถึงผ่านเกตเวย์ เพิ่ม MFA ใช้วลีรหัสผ่านที่ไม่ซ้ำกันและเปลี่ยนเมื่อสงสัยว่าถูกเจาะ และคุมกฎไฟร์วอลล์ให้รัดกุมทั้งขาเข้าและขาออก
ติดตั้ง Windows VPS พร้อมตั้งค่าทันทีและ RDP ผู้ดูแลระบบเต็มรูปแบบ
ซื้อ Windows VPSคำถามที่พบบ่อย
แค่เปลี่ยน port ของ RDP พอไหม?
ไม่พอ การเปลี่ยนพอร์ตช่วยลดการสแกนแบบสุ่มเท่านั้น คุณยังต้องมี NLA การล็อกบัญชี และรายการ IP ที่อนุญาต หรือไม่ก็ VPN และเกตเวย์ ให้มองการเปลี่ยนพอร์ตเป็นการลดเสียงรบกวน ไม่ใช่เกราะป้องกัน
ต้องใช้ VPN กับ RDP ไหม?
หาก RDP เปิดออกสู่อินเทอร์เน็ต ให้ใช้ VPN หรือ RD Gateway เพื่อลดการเปิดเผย และจับคู่กับ MFA และรายการ IP ที่อนุญาตบนไฟร์วอลล์ ก็จะได้การตั้งค่าที่เรียบง่ายแต่แข็งแรง ซึ่งทีมเล็ก ๆ ส่วนใหญ่ดูแลได้
ควร patch Windows VPS บ่อยแค่ไหน?
หากผู้ให้บริการมีช่วงเวลาบำรุงรักษา ให้ทำตามนั้น จากนั้นติดตั้งอัปเดตความปลอดภัยของระบบปฏิบัติการและแอปพลิเคชันไม่นานหลังจากปล่อยออกมา เส้นทางการโจมตีมักเริ่มจากการเปิดสู่สาธารณะและช่องโหว่ที่รู้จักกันดี จึงไม่ควรปล่อยให้การอัปเดตล่าช้า และหากเซิร์ฟเวอร์เก็บข้อมูลลูกค้า ให้กำหนดรอบการอัปเดตไว้เป็นนโยบายลายลักษณ์อักษรเพื่อให้ปฏิบัติได้จริง
NLA คืออะไร และทำไมต้องเปิด?
Network Level Authentication กำหนดให้ต้องเข้าสู่ระบบก่อนที่เซสชัน RDP จะเริ่ม จึงปิดกั้นเส้นทางโค้ดที่ยังไม่ผ่านการยืนยันตัวตนและช่วยประหยัดทรัพยากร Microsoft แนะนำให้ใช้ NLA ในสภาพแวดล้อมส่วนใหญ่ ให้ตรวจสอบว่าเปิดใช้อยู่และเปิดทิ้งไว้
ควรตรวจสอบอะไรบ้างบนเซิร์ฟเวอร์ขนาดเล็ก?
เริ่มจากการเข้าสู่ระบบล้มเหลว 4625, เหตุการณ์ 4624 ที่เป็น Logon Type 10 สำหรับการเข้าสู่ระบบ RDP ที่สำเร็จ, 4634 สำหรับการสิ้นสุดเซสชัน, 4647 สำหรับการออกจากระบบที่ผู้ใช้เริ่มเอง และการบันทึกคำสั่ง PowerShell จากนั้นเพิ่มการตรวจทานรายสัปดาห์และกฎแจ้งเตือนง่าย ๆ เมื่อมีการพุ่งสูงผิดปกติ เท่านี้ก็เพียงพอสำหรับเครื่องขนาดเล็กโดยไม่ต้องซื้อแพลตฟอร์มเต็มรูปแบบ