Fail2ban Advanced MLOps Workflow | SiamCafe Blog

Fail2ban Advanced MLOps Workflow คืออะไร

Fail2ban Advanced MLOps Workflow คือแนวทางการผนวกระบบป้องกันการบุกรุกอย่าง Fail2ban เข้าไปในกระบวนการทำงานแบบ MLOps ขององค์กร

โดยไม่ได้มองว่าเรื่องความปลอดภัยเป็นงานแยกส่วนที่ทีม DevOps จัดการเพียงลำพังอีกต่อไป แต่ให้กลายเป็นส่วนหนึ่งของ pipeline ทั้งหมด ตั้งแต่การเทรนโมเดล การดีพลอย จนถึงการมอนิเตอร์ระบบใน production หลักคิดง่าย ๆ คือ ถ้าโมเดลและบริการของเราวิ่งอยู่บนเซิร์ฟเวอร์ที่โดนแฮ็ก ทุกอย่างที่เหลือก็ไร้ความหมาย ดังนั้นชั้นป้องกันอย่าง Fail2ban จึงควรถูกจัดการด้วยแนวคิดแบบเดียวกับโค้ดและโมเดลของเรา

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

ในสถาปัตยกรรมแบบ defense-in-depth Fail2ban ทำหน้าที่เป็นชั้นป้องกันระดับแอปพลิเคชัน ทำงานร่วมกับ firewall, ระบบตรวจจับการบุกรุก และระบบตรวจสอบความถูกต้องของไฟล์ ไม่มีเครื่องมือใดเครื่องมือเดียวที่ป้องกันทุกภัยได้ ดังนั้นการออกแบบ workflow ที่ทำให้ทุกชั้นคุยกันได้ จึงเป็นหัวใจของเรื่องนี้ เช่น เมื่อ Fail2ban ตรวจพบรูปแบบการโจมตีผิดปกติ ระบบมอนิเตอร์ของ MLOps ควรได้รับแจ้งทันที เพื่อให้ทีมสามารถพิจารณาว่าเหตุการณ์นั้นกระทบโมเดลหรืองานเทรนที่กำลังวิ่งอยู่หรือไม่ ซึ่งจะนำไปสู่การป้องกัน การตรวจจับ และการตอบสนองที่เป็นระบบเดียวกัน

งาน MLOps ในปัจจุบันมักวิ่งบนเซิร์ฟเวอร์ที่เปิดพอร์ตหลายจุด เพราะต้องรับข้อมูลจากหลายแหล่ง ต้องเปิด API ให้โมเดลเรียกใช้

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

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

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

ระบบที่ดีควรประกอบด้วยสามชั้นหลัก ชั้นแรกคือชั้นป้องกันที่พอร์ตเครือข่าย ซึ่ง Fail2ban อ่านบันทึกจากบริการต่าง ๆ เช่น SSH, API เกตเวย์

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

สถาปัตยกรรมและองค์ประกอบของระบบที่ควรมี

ระบบที่ดีควรประกอบด้วยสามชั้นหลัก ชั้นแรกคือชั้นป้องกันที่พอร์ตเครือข่าย ซึ่ง Fail2ban อ่านบันทึกจากบริการต่าง ๆ เช่น SSH, API เกตเวย์ และระบบจัดการงานเทรน แล้วแบน IP ที่แสดงพฤติกรรมผิดปกติโดยอัตโนมัติ ชั้นที่สองคือชั้นมอนิเตอร์ ที่รวบรวมเหตุการณ์จาก Fail2ban ส่งไปยังแดชบอร์ดกลาง ให้ทีมเห็นภาพรวมว่าวันนี้มีการโจมตีรูปแบบใด และรูปแบบนั้นกระทบงานด้านโมเดลหรือไม่ ชั้นที่สามคือชั้นควบคุมเวอร์ชันของกฎเอง โดยเก็บไฟล์กฎของ Fail2ban ไว้ในระบบ Git เดียวกับโค้ดและไฟล์ตั้งค่าของ pipeline โมเดล ทำให้ทุกการแก้ไขมีผู้รับผิดชอบชัดเจนและย้อนดูประวัติได้

ตารางเปรียบเทียบเครื่องมือที่มักใช้ร่วมกันในระบบลักษณะนี้

เครื่องมือ	ประเภท	จุดเด่น
Fail2ban	ป้องกันการบุกรุก	บล็อก IP อัตโนมัติจากบันทึกของบริการ
Wazuh	ตรวจจับฝั่งโฮสต์	ตรวจสอบความถูกต้องของไฟล์ ตรวจจับรูทคิต
Suricata	ตรวจจับฝั่งเครือข่าย	วิเคราะห์การรับส่งข้อมูลแบบเรียลไทม์
CrowdSec	ป้องกันแบบชุมชน	ใช้รายการบล็อกจากข้อมูลผู้ใช้ทั่วโลกร่วมกัน

ก่อนจะพูดถึง workflow ระดับสูง รากฐานต้องแน่นก่อน การตั้งค่าพื้นฐานที่ผมถือว่าขาดไม่ได้มีดังนี้ ประการแรกตั้งค่า firewall

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

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

การติดตั้งและการตั้งค่าพื้นฐานที่ต้องทำให้ครบ

ก่อนจะพูดถึง workflow ระดับสูง รากฐานต้องแน่นก่อน การตั้งค่าพื้นฐานที่ผมถือว่าขาดไม่ได้มีดังนี้ ประการแรกตั้งค่า firewall ให้ปิดพอร์ตที่ไม่จำเป็นทั้งหมด เปิดเฉพาะพอร์ตที่บริการใช้จริง ประการที่สองปรับแต่งบริการ SSH ให้เข้มงวด เช่น ปิดการเข้าสู่ระบบด้วยรหัสผ่าน ใช้กุญแจแทน และปิดการเข้าสู่ระบบด้วยบัญชีผู้ดูแลระบบโดยตรง ประการที่สามติดตั้ง Fail2ban และตั้งค่าให้ครอบคลุมบริการที่สำคัญ ไม่ใช่แค่ SSH เท่านั้น

ตัวอย่างคำสั่งพื้นฐานที่ผมใช้เมื่อตั้งเซิร์ฟเวอร์ใหม่

sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow 22/tcp comment 'SSH' sudo ufw allow 443/tcp comment 'HTTPS' sudo ufw --force enable

sudo tee /etc/ssh/sshd_config.d/hardening.conf > /dev/null <<'EOF' PermitRootLogin no PasswordAuthentication no MaxAuthTries 3 EOF sudo systemctl restart ssh

sudo apt-get install -y fail2ban

เมื่อรากฐานพร้อมแล้ว ขั้นต่อไปคือการทำให้ทุกอย่างทำงานร่วมกันเป็นระบบเดียว แนวทางที่ผมใช้คือเก็บไฟล์กฎทั้งหมดของ Fail2ban

ไว้ในระบบควบคุมเวอร์ชันเดียวกับโค้ดโมเดล เมื่อมีการแก้ไขกฎ ระบบจะดีพลอยผ่าน pipeline อัตโนมัติพร้อมทดสอบก่อนว่ากฎใหม่ไม่บล็อกการรับส่งข้อมูลปกติของระบบเทรน ทำให้การปรับกลยุทธ์ป้องกันมีความเร็วเท่ากับการอัปเดตโค้ด ไม่ต้องรอเข้าเครื่องทีละเครื่องแบบเก่า ๆ sudo fail2ban-client status sshd

ข้อควรระวังสำคัญคือกฎของ Fail2ban ที่เข้มงวดเกินไปอาจบล็อกทีมงานเอง โดยเฉพาะเวลาทีมเทรนโมเดลรันงานแบบกระจายที่เครื่องต้องคุยกันถี่ ๆ ผมจึงแนะนำให้เพิ่มที่อยู่ IP ภายในองค์กรไว้ในรายการยกเว้นเสมอ และกำหนดเวลาแบนไม่นานเกินจนแก้ปัญหาไม่ทัน สำหรับบริการที่ใช้กับงานโมเดล เช่น API ที่รับข้อมูลเข้าเทรน ควรเขียนกฎเฉพาะที่อ่านบันทึกของบริการนั้น เพราะรูปแบบการโจมตีต่อ API ต่างจาก SSH มาก และควรตรวจสอบสถานะเป็นประจำด้วยคำสั่งให้รายงานจำนวนการแบนรายวัน เพื่อดูว่ากฎที่ใช้ได้ผลจริงหรือไม่ ถ้าไม่มีการแบนเลยเป็นเวลาหลายวัน อาจแปลว่ากฎผิดหรือบันทึกที่อ่านผิดตำแหน่ง

การประยุกต์ใช้งานจริงร่วมกับ MLOps และระบบอัตโนมัติ

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

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

จากมุมมองของผมในฐานะคนที่ดูแลระบบสัญญาณเทรดที่ต้องพร้อมใช้งานตลอดเวลา ช่วงเวลาหยุดทำงานเพียงไม่กี่นาทีอาจแปลว่าสัญญาณหลุดและสูญเสียโอกาสการเทรดจริง ๆ การมีระบบป้องกันที่ทำงานอัตโนมัติ ลดภาระการเฝ้าระวังด้วยมืออย่างมหาศาล ทีมสามารถใช้เวลาไปพัฒนาโมเดลต่อได้ โดยไม่ต้องกังวลว่าเซิร์ฟเวอร์จะถูกเจาะเมื่อไม่มีใครดูอยู่ ในปี 2026 ที่การโจมตีด้วยระบบอัตโนมัติเพิ่มขึ้นทุกปี การป้องกันแบบอัตโนมัติเท่านั้นที่จะตามทันครับ

แนวปฏิบัติที่ดีและข้อผิดพลาดที่พบบ่อย

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

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

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

คำถามที่พบบ่อย

Fail2ban Advanced MLOps Workflow ต่างจากการตั้งค่า Fail2ban แบบธรรมดาอย่างไร?

ความแตกต่างสำคัญอยู่ที่การมองความปลอดภัยเป็นส่วนหนึ่งของ pipeline ทั้งหมด ไม่ใช่งานแยกส่วนที่ทีม DevOps จัดการเพียงลำพัง ในแนวทาง MLOps กฎทุกข้อของ Fail2ban จะถูกเก็บในระบบควบคุมเวอร์ชัน (Git) เดียวกับโค้ดและไฟล์ตั้งค่าของ pipeline โมเดล มีการทดสอบก่อนใช้งานจริง มีการบันทึกผล และตรวจสอบย้อนหลังได้เหมือนกับการจัดการโมเดล จากประสบการณ์จริงกว่าสิบสามปี เซิร์ฟเวอร์ที่ตั้งค่า Fail2ban แบบธรรมดาแต่ไม่มี workflow ที่ดี มักถูกปล่อยทิ้งจนกฎล้าสมัย หรือกฎที่เข้มงวดเกินไปกลับไปบล็อก IP ของทีมงานเอง การผนวกเข้ากับ MLOps จึงช่วยให้ทุกการแก้ไขมีผู้รับผิดชอบชัดเจน ตรวจสอบได้ และทำงานร่วมกับระบบมอนิเตอร์ของ MLOps ได้อย่างเป็นระบบ

ทำไมเซิร์ฟเวอร์เทรนโมเดลจึงเป็นเป้าหมายของผู้ไม่หวังดี?

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

ระบบที่ดีตามแนวทางนี้ควรมีองค์ประกอบอะไรบ้าง?

ระบบที่ดีควรประกอบด้วยสามชั้นหลัก ชั้นแรกคือชั้นป้องกันที่พอร์ตเครือข่าย โดย Fail2ban จะอ่านบันทึกจากบริการต่าง ๆ เช่น SSH, API เกตเวย์ และระบบจัดการงานเทรน แล้วแบน IP ที่แสดงพฤติกรรมผิดปกติโดยอัตโนมัติ ชั้นที่สองคือชั้นมอนิเตอร์ ที่รวบรวมเหตุการณ์จาก Fail2ban ส่งไปยังแดชบอร์ดกลาง เพื่อให้ทีมเห็นภาพรวมว่าวันนั้นมีการโจมตีรูปแบบใด และรูปแบบนั้นกระทบงานด้านโมเดลหรือไม่ ชั้นที่สามคือชั้นควบคุมเวอร์ชันของกฎเอง โดยเก็บไฟล์กฎของ Fail2ban ไว้ใน Git เดียวกับโค้ดและไฟล์ตั้งค่า pipeline โมเดล ทั้งหมดนี้ทำงานภายใต้แนวคิด defense-in-depth ที่ไม่พึ่งเครื่องมือใดเครื่องมือเดียว แต่ให้ทุกชั้นคุยกันได้และตอบสนองร่วมกัน

มีเครื่องมืออะไรบ้างที่นิยมใช้ร่วมกับ Fail2ban ในระบบลักษณะนี้?

เครื่องมือที่มักใช้ร่วมกันมีหลายตัว แต่ละตัวทำหน้าที่ต่างกันในสถาปัตยกรรมแบบ defense-in-depth ได้แก่ Wazuh ซึ่งเป็นเครื่องมือตรวจจับฝั่งโฮสต์ ทำหน้าที่ตรวจสอบความถูกต้องของไฟล์และตรวจจับรูทคิต, Suricata เป็นเครื่องมือตรวจจับ

แนะนำเพิ่มเติม

🎯 เปิดบัญชี XM Forex → สมัคร

📱 แอป iCafeFX → ดาวน์โหลด

📊 สัญญาณฟรี → รับสัญญาณ

📚 คู่มือเทรด → SiamCafeBook

🤝 สมัคร Partner XM → pipaffiliates.com/c?c=72816&l=th&p=6