ป้องกัน Bot และ DDoS Layer 7 ด้วย WAF — ตั้งค่า Rate Limit ยังไงให้พอดี
DDoS Layer 7 ปลอมตัวเป็นผู้ใช้จริง firewall เครือข่ายจึงมองไม่เห็น ตั้ง Rate Limit บน WAF ยังไงให้จับ Bot ที่ยิงถี่ๆ โดยไม่บล็อกลูกค้า ดูตัวอย่างใน zcrWAF demo
ป้องกัน Bot และ DDoS Layer 7 ด้วย WAF — ตั้งค่า Rate Limit ยังไงให้พอดี
DDoS ที่คนส่วนใหญ่นึกถึงคือทราฟฟิกถล่มจนเน็ตล่มทั้งเครือข่าย แต่มีการโจมตีอีกแบบที่อันตรายไม่แพ้กันและตรวจจับยากกว่ามาก — Layer 7 DDoS คือการยิงคำขอ HTTP ที่ดู "ถูกต้องตามรูปแบบ" ทุกอย่าง เหมือนผู้ใช้จริงกำลังเปิดหน้าเว็บ เพียงแต่ยิงถี่เกินกว่าที่ระบบจริงจะรับไหว หรือใช้เพื่อลองรหัสผ่านซ้ำๆ กับบัญชีผู้ใช้จำนวนมาก — เพราะมันเลียนแบบ traffic ปกติ firewall ระดับเครือข่ายจึงมองไม่เห็นความผิดปกติเลย
Rate limiting ใน WAF คือคำตอบสำหรับปัญหานี้ — จำกัดว่า IP หนึ่งๆ ยิงคำขอได้กี่ครั้งในช่วงเวลาหนึ่ง แต่ตั้งค่าไม่ดีก็บล็อกผู้ใช้จริงไปด้วยได้เช่นกัน บทความนี้พาดูว่าตั้งค่ายังไงให้พอดี
ทำไม Layer 7 DDoS ถึงตรวจจับยากกว่า
DDoS ระดับเครือข่าย (L3/L4) ส่งข้อมูลปริมาณมหาศาลเพื่ออุดช่องสัญญาณ ตรวจจับง่ายเพราะปริมาณข้อมูลผิดปกติชัดเจน — ส่วน Layer 7 DDoS ยิงคำขอ HTTP ปกติแต่ ถี่กว่าปกติมาก หรือ เจาะจงไปที่ endpoint ที่ใช้ทรัพยากรเยอะ เช่น หน้าค้นหาหรือหน้า login ที่ต้อง query ฐานข้อมูลทุกครั้ง ทำให้ server ทำงานหนักจนช้าหรือล่มโดยที่ traffic volume รวมไม่ได้สูงผิดปกติเลย
รูปแบบที่พบบ่อย:
- Credential stuffing — ยิง login request ซ้ำๆ ด้วยชุด email/password ที่หลุดจากที่อื่น
- Scraping — bot ดึงข้อมูลราคาสินค้าหรือเนื้อหาเว็บซ้ำๆ จำนวนมาก
- Application-layer flood — ยิงคำขอไปที่ endpoint เฉพาะจุดที่กิน CPU/database มากกว่าปกติ
3 กลไก Rate Limiting ที่ใช้ร่วมกัน
ค่าที่ตั้งไว้ในหน้า Rate Limiting ของ zcrWAF demo:
1) Visit Limit — จำกัดจำนวนคำขอทั้งหมดจาก IP เดียวในช่วงเวลาหนึ่ง ค่าในเดโมคือ Trigger Threshold 1,200 requests และ Block Duration 300 วินาที คือ IP ที่ยิงเกินเกณฑ์จะถูกบล็อกตามระยะเวลานั้น ส่วนหน้าต่างเวลาที่ใช้นับคำขออยู่ใน Show Advanced Options ใช้ป้องกัน scraping และการยิงถี่ทั่วไป
2) Attack Limit — จำกัดเฉพาะคำขอที่ระบบตรวจว่าเป็นรูปแบบการโจมตี ค่าในเดโมคือ Trigger Threshold 20 requests และ Block Duration 900 วินาที (15 นาที) — ตั้งค่าเข้มกว่า Visit Limit มาก เพราะเป็นคำขอที่ยืนยันแล้วว่าน่าสงสัย ไม่ใช่ traffic ทั่วไป
3) Error Limit — จำกัดจำนวนครั้งที่ IP หนึ่งได้รับ error response (เช่น 401, 403, 404) ค่าในเดโมคือ Trigger Threshold 80 และ Block Duration 600 วินาที (10 นาที) — ใช้จับ credential stuffing และการสแกนหา endpoint ที่ไม่มีอยู่จริง เพราะ IP ที่ได้ error ซ้ำๆ ในช่วงเวลาสั้นๆ มักไม่ใช่ผู้ใช้จริงที่พิมพ์ผิด
ทั้ง 3 กลไกทำงานคู่ขนานกัน — Visit Limit จับทราฟฟิกหนักทั่วไป, Attack Limit จับการโจมตีที่ยืนยันแล้ว, Error Limit จับพฤติกรรมลองผิดลองถูกซ้ำๆ ส่วนตัวเลขข้างบนเป็นค่าตั้งของ demo เอง ไม่ใช่ค่าที่แนะนำสำหรับเว็บของคุณ
ตั้งค่ายังไงไม่ให้บล็อกผู้ใช้จริง
- เริ่มจากค่า threshold สูงแล้วค่อยลด — ดู traffic pattern จริงของเว็บก่อน 1-2 สัปดาห์ แล้วตั้ง threshold สูงกว่าค่าเฉลี่ยของผู้ใช้จริงพอสมควร ไม่ใช่เดาค่ามาตั้งตรงๆ
- แยก threshold ตาม endpoint — หน้า login หรือหน้าค้นหาควรมี threshold เข้มกว่าหน้าดูสินค้าทั่วไป เพราะเป็นเป้าหมายหลักของ credential stuffing และ scraping
- ใช้ CAPTCHA แทนการบล็อกทันทีในบางจุด — สำหรับ traffic ที่น่าสงสัยแต่ยังไม่ชัดเจน การท้าทายด้วย CAPTCHA ช่วยกรองบอทออกโดยไม่ตัดผู้ใช้จริงทิ้งทันที
- ดู Error Limit คู่กับ log จริง — ถ้า Error Limit ตัดผู้ใช้จริงบ่อยเกินไป อาจเป็นสัญญาณว่า UX ของเว็บทำให้คนกด error บ่อย ไม่ใช่แค่ปัญหาความปลอดภัยอย่างเดียว
ทำไมเรื่องนี้เกี่ยวกับ PDPA
Credential stuffing ที่สำเร็จหมายความว่ามีคนเข้าถึงบัญชีผู้ใช้โดยไม่ได้รับอนุญาต ซึ่งอาจนำไปสู่การเข้าถึงข้อมูลส่วนบุคคลที่ผูกกับบัญชีนั้น — ถ้าเกิดขึ้นจริงและมีข้อมูลรั่วไหล องค์กรมีหน้าที่ต้องแจ้งเหตุตาม PDPA การมี rate limiting ที่ตั้งค่าดีคือชั้นป้องกันที่ลดโอกาสเกิดเหตุการณ์แบบนี้ตั้งแต่ต้นทาง
zcrWAF ช่วยเรื่องนี้ได้ยังไง
zcrWAF มาพร้อม rate limiting ทั้ง 3 ชั้นข้างต้นแบบตั้งค่าได้ต่อเว็บไซต์ พร้อม CAPTCHA challenge สำหรับ traffic ที่น่าสงสัยแต่ยังไม่ชัดเจน ทำงานร่วมกับการตรวจจับ OWASP Top 10 ในแพลตฟอร์มเดียวกัน
องค์กรที่อยากรู้ว่าเว็บไซต์ตัวเองเจอ bot traffic หรือ credential stuffing อยู่มากแค่ไหน ลองดูแพ็กเกจ zcrWAF ได้เลย
แหล่งข้อมูลอ้างอิง
- Cloudflare — What's an Application Layer DDoS Attack — ยืนยันว่า Layer 7 DDoS เลียนแบบทราฟฟิกปกติจนแยกยากและมักเจาะจงไปที่ endpoint อย่างหน้า login หรือ API แทนที่จะถล่มทั้งเครือข่าย ตรงกับคำอธิบายในบทความ
- OWASP — Credential Stuffing — ยืนยันนิยามและกลไกของ credential stuffing ที่ใช้ในบทความ
- IAPP — Thailand's PDPC Clarifies Data Breach Notification Requirements — ยืนยันว่าผู้ควบคุมข้อมูลมีหน้าที่ต้องแจ้งเหตุการละเมิดข้อมูลส่วนบุคคลตาม PDPA
ติดต่อทีมงาน
อยากรู้ว่าเว็บไซต์ที่ดูแลอยู่เจอ bot traffic หรือการยิงคำขอผิดปกติมากแค่ไหน ทีมงานยินดีให้คำปรึกษาฟรี