ตั้งค่า Rate Limiting และ WAF ป้องกันบอทถล่มเว็บแบบไม่ต้องเขียนโค้ด

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

ข่าวดีคือ หากเว็บไซต์ของคุณวางอยู่หลัง CDN หรือ Reverse Proxy ที่มีฟีเจอร์ด้านความปลอดภัย คุณสามารถสร้าง “เกราะหน้าเว็บ” ได้ทันที โดยไม่จำเป็นต้องแก้ไขโค้ดของแอปพลิเคชันเพิ่มเติม แนวทางหลักมีอยู่ 2 ชั้น ได้แก่ Rate Limiting และ WAF

ทำความเข้าใจกับ 2 ชั้นป้องกันหลัก

1. Rate Limiting

Rate Limiting คือการจำกัดความถี่ของ request ที่เข้ามาจาก IP เดียวกัน หรือจำกัดตามเส้นทางที่กำหนด เช่น หน้า login, หน้า search หรือ API สำคัญ วิธีนี้ช่วยลดการยิงถี่จากบอท และลดภาระของเซิร์ฟเวอร์ได้อย่างมีประสิทธิภาพ

2. WAF

WAF หรือ Web Application Firewall ทำหน้าที่ตรวจจับและบล็อกแพตเทิร์นการโจมตีที่พบได้บ่อย เช่น SQL Injection, XSS และพฤติกรรมที่เข้าข่าย Brute Force โดยเฉพาะหากใช้ Managed Rules ที่ครอบคลุมแนวทางของ OWASP Top 10 ก็สามารถเปิดใช้งานได้รวดเร็วและแทบไม่ต้องตั้งค่าซับซ้อน

เริ่มต้นตั้งค่าจากภาพรวม

วางเว็บไซต์หลัง CDN หรือ Proxy

CDN หรือ Reverse Proxy จะทำหน้าที่เป็นด่านหน้ารับ request ก่อนถึง origin server ทำให้สามารถกรองบอทหรือทราฟฟิกผิดปกติได้ตั้งแต่ต้นทาง ลดโอกาสที่ทราฟฟิกขยะจะหลุดไปถึงเซิร์ฟเวอร์จริง

เปิดใช้ WAF แบบ Managed Rules

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

ตั้ง Rate Limiting แบบเจาะจงเส้นทาง

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

เส้นทางที่ควรตั้ง Rate Limit ก่อน

เส้นทางต่อไปนี้มักเป็นเป้าหมายแรกของบอทและผู้โจมตี

• /login หรือ endpoint สำหรับยืนยันตัวตนทั้งหมด
• /wp-login.php และ /xmlrpc.php สำหรับเว็บไซต์ WordPress
• /api/send-otp หรือ API ที่ถูกเรียกถี่เป็นพิเศษ
• /search ซึ่งมักถูกใช้ในการ scrape ข้อมูล
• /cart/checkout เพื่อป้องกันบอทปั่นคำสั่งหรือก่อกวนระบบสั่งซื้อ

ค่าตั้งต้นที่นำไปใช้ได้จริง

แม้แต่ละเว็บไซต์จะมีลักษณะการใช้งานต่างกัน แต่ค่าตั้งต้นต่อไปนี้ถือว่าใช้งานได้ดีในหลายกรณี

• Login: 5 ครั้งต่อ 1 นาที ต่อ IP
• OTP: 3 ครั้งต่อ 5 นาที ต่อ IP
• Search: 30 ครั้งต่อ 1 นาที ต่อ IP
• API ทั่วไป: 60-120 ครั้งต่อ 1 นาที ต่อ IP

ค่าพวกนี้ควรนำไปทดลองใช้งานและปรับตามพฤติกรรมจริงของผู้ใช้ เพื่อไม่ให้เข้มเกินไปจนกระทบการใช้งานปกติ

เทคนิคที่ควรใช้: จำกัดแบบ 2 ระดับ

Soft Limit

เมื่อเกินลิมิต ให้ระบบแสดง Challenge เช่น CAPTCHA หรือ JavaScript Challenge ก่อน วิธีนี้เหมาะกับเว็บที่ต้องระวังไม่ให้บล็อกผู้ใช้จริงโดยไม่จำเป็น

Hard Limit

หากเกินลิมิตในจุดสำคัญ เช่น หน้า login หรือ endpoint อ่อนไหว สามารถตั้งให้บล็อกทันที 10-30 นาที วิธีนี้เหมาะกับสถานการณ์ที่มีความเสี่ยงสูงและต้องการหยุดการโจมตีอย่างรวดเร็ว

เพิ่มความแม่นยำด้วยการแยกตามประเทศหรือ ASN

หากเว็บไซต์ของคุณให้บริการเฉพาะในประเทศไทย การตั้งกฎให้ challenge หรือ block ทราฟฟิกจากประเทศที่ไม่เกี่ยวข้อง สามารถช่วยลด noise และลดภาระจากบอทได้มาก โดยไม่ต้องแก้ไขระบบภายในเลย

นอกจากนี้ หากผู้ให้บริการรองรับการตั้งกฎตาม ASN ก็สามารถจำกัดทราฟฟิกจากเครือข่ายที่มีความเสี่ยงหรือมาจาก data center จำนวนมากได้เช่นกัน

วิธีป้องกัน Brute Force โดยไม่เพิ่มโค้ด

การป้องกัน Brute Force แบบไม่แตะโค้ดสามารถทำได้ด้วย 3 องค์ประกอบร่วมกัน

1. ตั้ง Rate Limit ที่ /login
2. ใช้ WAF ตรวจจับพฤติกรรมซ้ำ ๆ เช่น ยิงถี่ เปลี่ยน username ไปเรื่อย
3. เปิดใช้ IP Reputation หรือ Bot Score หากแพลตฟอร์มที่ใช้รองรับ

เมื่อรวมทั้งสามส่วนเข้าด้วยกัน ระบบจะสามารถแยกทราฟฟิกเสี่ยงออกจากผู้ใช้จริงได้แม่นยำขึ้นมาก

สัญญาณอันตรายที่ควรเร่งเปิดโหมดเข้มขึ้น

หากพบพฤติกรรมต่อไปนี้ ควรเพิ่มระดับการป้องกันทันที

• มี request ไปยัง /login ทุก 1-2 วินาทีแบบต่อเนื่อง
• ค่า 401, 403 หรือ 429 เพิ่มขึ้นผิดปกติ
• มีทราฟฟิกจำนวนมากมาจาก data center หรือเครือข่ายที่ไม่เคยใช้งานมาก่อน

สัญญาณเหล่านี้มักบ่งบอกว่ากำลังเกิดการทดสอบช่องโหว่หรือ Brute Force อยู่เบื้องหลัง

ข้อควรระวังสำคัญก่อนเปิดกฎแรงเกินไป

อย่าใช้ IP เป็นเกณฑ์เดียวเสมอไป

หากผู้ใช้จำนวนมากอยู่หลัง NAT เดียวกัน เช่น ในออฟฟิศ มหาวิทยาลัย หรือเครือข่ายองค์กร การบล็อกตาม IP อย่างเดียวอาจทำให้ผู้ใช้จริงโดนกระทบได้ ทางออกคือใช้ Challenge ก่อน Block หรือใช้การจำกัดแบบอิง session/cookie หากระบบรองรับ

อย่าตั้งลิมิต API ต่ำเกินไปกับ Mobile App

แอปมือถือหลายตัวมีระบบ retry อัตโนมัติ หากตั้งลิมิตต่ำมาก อาจทำให้ผู้ใช้จริงถูกตอบกลับด้วย 429 โดยไม่จำเป็น

อย่าลืม Whitelist ระบบที่จำเป็น

บริการอย่าง payment gateway callback, webhook จาก third-party หรือระบบเชื่อมต่อภายนอกที่จำเป็น ควรถูกเพิ่มใน whitelist เพื่อไม่ให้ถูกกฎความปลอดภัยบล็อกโดยไม่ตั้งใจ

เช็กลิสต์ตั้งค่าให้เสร็จภายใน 30 นาที

หากต้องการเริ่มต้นอย่างรวดเร็ว สามารถใช้เช็กลิสต์นี้ได้ทันที

• เปิด WAF Managed Rules
• เปิด Bot Mitigation หรือ Bot Fight Mode หากมี
• สร้าง Rate Limit สำหรับ /login
• สร้าง Rate Limit สำหรับ /api/send-otp
• เริ่มต้นด้วย action แบบ Challenge ก่อน
• หากพบบอทหนัก ค่อยปรับเป็น Block
• เปิด log เพื่อตรวจสอบ top path, top IP และ top country

ตัวอย่างสถานการณ์จริงที่พบได้บ่อย

กรณีเว็บอีคอมเมิร์ซโดนยิงหน้า Search

เมื่อเปิด Rate Limit ที่ 30 ครั้งต่อนาที พร้อมตั้ง Challenge เพิ่ม พบว่าโหลด CPU ลดลงอย่างชัดเจน ขณะที่ผู้ใช้จริงยังสามารถค้นหาสินค้าได้ตามปกติ

กรณีเว็บสมาชิกโดน Brute Force ตอนกลางคืน

เมื่อกำหนดกฎที่ /login เป็น 5 ครั้งต่อนาที และบล็อก 15 นาทีทันทีเมื่อเกินลิมิต จำนวนการพยายามเดารหัสผ่านลดลงเกือบหมดภายในคืนเดียว

สรุป

การวางเว็บไซต์หลัง CDN หรือ Reverse Proxy แล้วเปิดใช้ WAF ร่วมกับ Rate Limiting คือวิธีที่เร็วและคุ้มค่ามากในการป้องกันบอทถล่มเว็บและลดความเสี่ยงจาก Brute Force โดยแทบไม่ต้องเขียนโค้ดเพิ่ม

หัวใจสำคัญคือการเริ่มจากจุดเสี่ยงสูง เช่น /login, /api/send-otp, /search และใช้แนวทางแบบ 2 ระดับ คือ Challenge ก่อน แล้วค่อย Block เมื่อจำเป็น หากตั้งค่าครบทั้งสองชั้นได้ดี เว็บไซต์จะเสถียรขึ้นอย่างเห็นผล ลดทราฟฟิกขยะ ลดภาระเซิร์ฟเวอร์ และช่วยประหยัดค่าใช้จ่ายได้ในระยะยาว