วิธีใช้ Web Application Firewall ใน DirectAdmin

Web Application Firewall (WAF) ช่วยป้องกันเว็บไซต์จากการโจมตีทั่วไป เช่น SQL Injection, XSS และ CSRF โดยวิเคราะห์ Traffic ที่เข้ามาและบล็อก Request ที่น่าสงสัย

WAF คืออะไรและทำงานอย่างไร

Web Application Firewall หรือ WAF คือระบบป้องกันที่ตรวจสอบทุก HTTP Request ที่ส่งมายังเว็บไซต์ ก่อนที่ Request จะถึงตัวแอปพลิเคชัน WAF จะวิเคราะห์เนื้อหาของ Request ทั้งหมด ได้แก่ URL, HTTP Header, Query String, Cookie และ Form Data เพื่อตรวจสอบว่ามีรูปแบบการโจมตีที่รู้จักซ่อนอยู่หรือไม่

หลักการทำงานของ WAF

WAF ทำงานแบบ Reverse Proxy หรือ Inline Filter โดยวางตัวเองระหว่าง Internet กับ Web Server ทุก Request ที่เข้ามาจะผ่าน WAF ก่อน ถ้า Request ตรงกับ Rule การโจมตีที่กำหนดไว้ WAF จะบล็อกและส่ง Error Code กลับ (มักเป็น 403 Forbidden) แทนที่จะปล่อยให้ Request ผ่านไปถึงเว็บไซต์ หาก Request ปกติก็จะผ่านไปยังเซิร์ฟเวอร์ตามปกติโดยไม่มีผลต่อผู้ใช้ทั่วไป

WAF ต่างจาก Network Firewall อย่างไร

Network Firewall (เช่น iptables หรือ CSF) ทำงานระดับ IP Address และ Port — บล็อก IP ที่น่าสงสัย ปิด Port ที่ไม่ใช้งาน และจำกัดความเร็วในการเชื่อมต่อ แต่ไม่เข้าใจเนื้อหาภายใน HTTP Request WAF ทำงานระดับ Application Layer ตีความเนื้อหาของ Request ได้ เช่น ตรวจว่า Form Input มี SQL Command แฝงอยู่หรือไม่ ทั้งสองระบบต้องใช้ร่วมกันเพื่อความปลอดภัยที่สมบูรณ์

ภัยคุกคามที่ WAF ป้องกัน

• SQL Injection (SQLi) — ผู้โจมตีใส่คำสั่ง SQL ในช่องกรอกข้อมูลเพื่อเข้าถึงฐานข้อมูล
• Cross-Site Scripting (XSS) — ฝัง JavaScript อันตรายเพื่อขโมย Session Cookie ของผู้ใช้
• Path Traversal — ใช้ ../ เพื่อเข้าถึงไฟล์นอก Web Root
• Remote File Inclusion (RFI) — โหลด Script จากเซิร์ฟเวอร์ภายนอกผ่านช่องโหว่ของแอป
• Command Injection — ฝังคำสั่ง OS ในช่องกรอกข้อมูล
• Bot Scanner Traffic — โปรแกรมอัตโนมัติที่สแกนหาช่องโหว่ของเว็บ

วิธีเปิดใช้ WAF

1. ล็อกอิน DirectAdmin แล้วไปที่ Advanced Features
2. คลิก Web Application Firewall (WAF)
3. ติ๊กถูกที่ Enable WAF
4. เลือก Rule Set ที่ต้องการ (OWASP ModSecurity Core Rule Set แนะนำ)
5. คลิก Save

กฎ WAF ที่พบบ่อยใน DirectAdmin (OWASP CRS และ ModSecurity)

DirectAdmin รองรับ WAF ผ่าน ModSecurity ซึ่งเป็นโมดูล WAF มาตรฐานของ Apache ที่ใช้แพร่หลายที่สุดในโลก กฎที่นิยมใช้คือ OWASP Core Rule Set (CRS) ซึ่งดูแลโดย Open Web Application Security Project

OWASP Core Rule Set (CRS) คืออะไร

OWASP CRS คือชุดกฎมาตรฐานที่ครอบคลุมการโจมตีเว็บที่พบบ่อยที่สุดตาม OWASP Top 10 มีการอัปเดตสม่ำเสมอเพื่อรองรับรูปแบบการโจมตีใหม่ๆ เมื่อเปิดใช้งาน ModSecurity ร่วมกับ OWASP CRS จะได้รับการป้องกันที่ครอบคลุมตั้งแต่วันแรกโดยไม่ต้องเขียน Rule เอง

Rule ID และความหมาย

กฎแต่ละข้อใน ModSecurity มีหมายเลข Rule ID ซึ่งช่วยระบุการโจมตีที่ถูกตรวจพบ ตัวอย่างกฎที่พบบ่อย

• Rule 941xxx — ตรวจจับ Cross-Site Scripting (XSS) ใน Query String, Body, Header
• Rule 942xxx — ตรวจจับ SQL Injection patterns ในค่าต่างๆ ที่ส่งมา
• Rule 930xxx — ตรวจจับ Path Traversal เช่น ../etc/passwd
• Rule 920xxx — ตรวจสอบความถูกต้องของ HTTP Protocol เช่น Header ที่ผิดรูปแบบ
• Rule 913xxx — ตรวจจับ Scanner และ Bot ที่รู้จัก

Anomaly Scoring vs Traditional Blocking

OWASP CRS ใช้ระบบ Anomaly Scoring แทนการบล็อกทันทีเมื่อ Rule ตรงกัน แต่ละ Rule มี Score ถ้า Request สะสม Score เกิน Threshold (ค่าเริ่มต้นคือ 5) จึงจะถูกบล็อก วิธีนี้ลด False Positive เพราะต้องตรงกฎหลายข้อพร้อมกันจึงจะถูกบล็อก ไม่ใช่ตรงกฎข้อเดียวก็บล็อกแล้ว

Mode ของ WAF

• Detection Only — บันทึก Log แต่ไม่บล็อก เหมาะสำหรับทดสอบ
• Prevention — บล็อก Request ที่ละเมิด Rule เต็มรูปแบบ

การ Whitelist IP หรือ URL เมื่อ WAF บล็อก Request ที่ถูกต้อง

False Positive คือเหตุการณ์ที่ WAF บล็อก Request ที่ถูกต้องและไม่มีอันตราย เช่น ฟอร์มที่มี HTML Content, การอัปโหลดไฟล์, หรือ API ที่มี Parameter พิเศษ การจัดการ False Positive ต้องทำด้วยความระมัดระวัง เพราะการปิด Rule ทั้งหมดเพื่อแก้ปัญหาเดียวจะลดความปลอดภัยลงมาก

วิธี Whitelist IP Address ที่เชื่อถือได้

ถ้าพบว่า IP ของทีมงานหรือ Office ถูก WAF บล็อก สามารถเพิ่ม IP นั้นใน Whitelist ได้ ModSecurity รองรับการยกเว้น IP ด้วย Directive ใน Configuration

• ระบุ IP เดียว: SecRule REMOTE_ADDR "@ipMatch 203.0.113.10" "id:1001,phase:1,allow,nolog"
• ระบุ Subnet: SecRule REMOTE_ADDR "@ipMatch 203.0.113.0/24" "id:1002,phase:1,allow,nolog"

บน Hosting ที่ไม่มีสิทธิ์แก้ Configuration โดยตรง ให้ติดต่อ Support เพื่อขอเพิ่ม Whitelist IP ผ่านทีมงาน

วิธี Whitelist URL เฉพาะจุด

วิธีที่ปลอดภัยที่สุดคือสร้าง Exception สำหรับ URL หรือ Rule ID ที่ต้องการ แทนการปิด Rule Set ทั้งหมด ตัวอย่าง: ยกเว้น Rule 941100 สำหรับ URL /admin/editor.php ที่ต้องรับ HTML Content โดยชอบธรรม เพื่อไม่ให้กระทบ Rule เดียวกันบน URL อื่น

สัญญาณที่บอกว่าเป็น False Positive ไม่ใช่การโจมตีจริง

• Error เกิดหลังจาก Deploy Feature ใหม่ที่ใช้ HTML Editor หรือ Rich Text
• เฉพาะผู้ใช้ที่ Login อยู่ที่ได้รับผลกระทบ ผู้ใช้ทั่วไปไม่มีปัญหา
• Log แสดง Rule ที่เกี่ยวกับ XSS แต่เนื้อหาที่ส่งคือ HTML ที่ Admin พิมพ์ผ่าน CMS Editor
• เกิดเฉพาะบน URL ของฟอร์ม Admin ไม่ใช่หน้าสาธารณะ

การจัดการ Whitelist

หาก WAF บล็อก Request ที่ถูกต้อง เช่น การอัปโหลดไฟล์ หรือ Form ที่มี HTML ให้เพิ่ม Exception Rule ใน Whitelist เพื่อให้ผ่านโดยไม่ถูก Block

การตรวจสอบ WAF Log เพื่อหาสาเหตุที่เว็บทำงานผิดปกติ

เมื่อเปิดใช้ WAF แล้วเว็บทำงานผิดปกติหรือผู้ใช้รายงานว่าเห็น Error 403 หรือหน้าขาว สาเหตุอาจมาจาก WAF บล็อก Request ที่ถูกต้อง ขั้นตอนแรกคือตรวจสอบ WAF Log ก่อนเสมอ

ข้อมูลในแต่ละ Log Entry

ModSecurity Audit Log บันทึกข้อมูลสำคัญเหล่านี้สำหรับทุก Event ที่ตรวจพบ

• Timestamp — วันและเวลาที่เกิดเหตุ (ใช้เปรียบเทียบกับเวลาที่ผู้ใช้รายงานปัญหา)
• Client IP — IP ของผู้ส่ง Request (ช่วยระบุว่าเป็นผู้ใช้จริงหรือ Bot)
• Rule ID — หมายเลขกฎที่ทำงาน (เช่น 941100 = XSS detection)
• URI และ Parameter — URL และค่าที่ส่งมาที่ทำให้ Rule ทำงาน
• Action — ผลการตัดสินใจของ WAF ว่าบล็อกหรืออนุญาต
• Severity — ระดับความรุนแรง (CRITICAL, ERROR, WARNING, NOTICE)

วิธีดู WAF Log ใน DirectAdmin

1. ล็อกอิน DirectAdmin ไปที่ Advanced Features แล้วเปิด Web Application Firewall
2. มองหาลิงก์ ModSecurity Audit Log หรือ WAF Log
3. กรอง Log ตามช่วงเวลาที่เกิดปัญหา
4. ค้นหาบรรทัดที่มี Access denied หรือ id "9413"
5. บันทึก Rule ID ที่พบเพื่อนำไปสร้าง Exception

แนวทางการอ่าน Log และตัดสินใจ

เมื่อพบ Rule ที่ทำงานใน Log ให้ถามตัวเองว่า Request ที่ถูกบล็อกนั้นเป็นของผู้ใช้จริงที่ชอบธรรมหรือไม่ หากใช่ ให้สร้าง Exception เฉพาะ URL หรือ Rule ID นั้น หากเป็น Bot หรือ Scanner ที่ไม่รู้จัก การบล็อกเป็นพฤติกรรมที่ถูกต้องของ WAF ไม่ต้องแก้ไข ข้อสำคัญคืออย่ารีบปิด WAF ทั้งหมดเพื่อแก้ปัญหา False Positive จุดเดียว เพราะจะเปิดช่องให้การโจมตีอื่นๆ ผ่านเข้ามาได้

การใช้ WAF ร่วมกับ WordPress และ CMS อื่นๆ

เว็บไซต์ที่ใช้ WordPress หรือ CMS ยอดนิยมมักเกิด False Positive บ่อยเมื่อเปิด WAF เพราะ Admin ต้องส่ง HTML Content ผ่าน Editor เป็นประจำ ทางออกที่ดีที่สุดคือเพิ่ม Exception สำหรับ URL ของ Admin Panel เช่น /wp-admin/ หรือ /wp-json/ โดยสร้าง Exception Rule ที่ข้าม XSS Rule สำหรับ URL เหล่านั้น แต่ยังคงป้องกันการโจมตีอื่นๆ ไว้ครบ นอกจากนี้ Plugin สำหรับ Security ของ WordPress บางตัวยังมี Rule สำหรับ ModSecurity โดยเฉพาะ ซึ่งช่วยลด False Positive ที่เกิดจาก WordPress workflow ได้อย่างมีประสิทธิภาพ

ความสัมพันธ์ระหว่าง WAF กับ SSL/HTTPS

WAF ทำงานในระดับ HTTP Application Layer ไม่เกี่ยวกับการเข้ารหัส SSL/TLS แต่มีจุดสำคัญที่ต้องทราบ คือ WAF ต้องมองเห็น Request Content ได้จึงจะวิเคราะห์ได้ ดังนั้นถ้าใช้ HTTPS WAF จะต้องอยู่ที่ฝั่ง Server (หลังการ Terminate SSL) ไม่ใช่ก่อน SSL โดยบน Hosting ที่ใช้ Apache + ModSecurity การตั้งค่านี้จัดการอัตโนมัติโดย Server ผู้ใช้ไม่ต้องดูแลส่วนนี้ สิ่งที่ต้องทำคือเปิดใช้ WAF ใน DirectAdmin เท่านั้น แล้วระบบจะทำงานร่วมกับ SSL ได้ทันที