WAF คืออะไร? — ต่างจาก Firewall ธรรมดายังไง ทำไมเว็บสาธารณะต้องมี
WAF คืออะไร ต่างจาก Firewall ทั่วไปยังไง WAF แกะดูเนื้อหาของคำขอ HTTP ก่อนถึงเซิร์ฟเวอร์ กันทั้ง SQL injection และ bot ดูว่าเว็บของคุณถึงเวลาต้องมีหรือยัง
WAF คืออะไร? — ต่างจาก Firewall ธรรมดายังไง ทำไมเว็บสาธารณะต้องมี
Firewall ทั่วไปเปรียบเหมือนยามหน้าประตูที่เช็คว่า "ใครเข้ามา ผ่านช่องทางไหน" — ดูแค่ต้นทาง ปลายทาง และพอร์ตที่ใช้ ไม่ได้แกะดูว่าสิ่งที่ถือเข้ามาคืออะไร ปัญหาคือเว็บไซต์และ API เปิดพอร์ต 80/443 ให้ทุกคนเข้าถึงได้อยู่แล้วโดยดีไซน์ — firewall ธรรมดาจึงปล่อยผ่านทุกคำขอ HTTP ที่มาถูกพอร์ต ไม่ว่าคำขอนั้นจะเป็นลูกค้าจริงหรือเป็นความพยายามฉีด SQL injection เข้าฐานข้อมูล
WAF (Web Application Firewall) คือชั้นป้องกันที่แกะดู "เนื้อหา" ของคำขอ HTTP แต่ละอันก่อนจะปล่อยให้ถึงเซิร์ฟเวอร์จริง — เหมือนยามที่ไม่ได้แค่เช็คบัตร แต่เปิดกระเป๋าดูด้วยว่าเอาอะไรเข้ามาบ้าง
WAF ต่างจาก Firewall ทั่วไปตรงไหน
| Firewall ทั่วไป | WAF |
|---|
| มองที่ระดับไหน | Network layer — IP, port, protocol | Application layer — เนื้อหาจริงของ HTTP request |
| ป้องกันอะไร | การเข้าถึงที่ไม่ได้รับอนุญาตในระดับเครือข่าย | OWASP Top 10, bot, การยิงคำขอถี่ผิดปกติ, brute-force |
| ตัวอย่างที่บล็อกได้ | Port scan, IP ที่ไม่อยู่ใน allowlist | SQL injection, credential stuffing, path traversal |
| จุดที่วาง | ขอบเขตเครือข่าย | หน้าเว็บ/API ก่อนถึง origin server |
พูดง่ายๆ firewall ตัดสินใจจาก "ใครเคาะประตู" ส่วน WAF ตัดสินใจจาก "เคาะประตูแล้วพูดอะไร" — สองชั้นนี้ทำงานเสริมกัน ไม่ใช่แทนกัน องค์กรที่มีแค่ firewall ธรรมดาจึงยังเปิดช่องให้การโจมตีระดับ application ผ่านเข้ามาได้สบายๆ
WAF กรองทราฟฟิกยังไง — 4 ขั้นตอน
1) ตรวจสอบ Request — แกะดูเนื้อหาของ HTTP request แต่ละอันที่เข้ามา ทั้ง header, parameter และ payload
2) เทียบกับ Rule — จับคู่กับ signature ที่รู้จัก (OWASP Top 10, bot pattern) และพฤติกรรมที่ผิดปกติจาก baseline
3) บล็อกหรือปล่อยผ่าน — ตัดสินใจแบบ real-time ว่า request นั้นน่าสงสัยพอจะบล็อก ท้าทายด้วย CAPTCHA หรือปล่อยผ่านตามปกติ
4) บันทึก Log — เก็บทุกเหตุการณ์ไว้ตรวจสอบย้อนหลัง พร้อมจำแนกประเภทการโจมตีให้อัตโนมัติ
ทำไมเว็บสาธารณะและ API ถึงต้องมี WAF
เว็บไซต์และ API ที่เปิดให้บุคคลทั่วไปเข้าถึงเจอความเสี่ยงที่แยกจากผู้ใช้จริงได้ยากด้วยตาเปล่า:
- OWASP Top 10 — SQL injection, XSS, broken access control และรูปแบบการโจมตีเว็บที่พบบ่อยที่สุด
- Bot และสคริปต์อัตโนมัติ — scraper, credential stuffing bot ที่ลองรหัสผ่านที่หลุดมาจากที่อื่นซ้ำๆ กับบัญชีจริง
- ทราฟฟิกยิงถี่ผิดปกติ — ทั้งจากการโจมตีจริงและบั๊กจาก integration ฝั่งลูกค้า ซึ่งแยกยากถ้าไม่มีเครื่องมือช่วย
- Path traversal และการสแกนหาช่องโหว่ — พยายามเข้าถึงไฟล์หรือ endpoint ที่ไม่ควรเข้าถึงได้จากภายนอก
หน้าตาจริงในแดชบอร์ด zcrWAF
หน้า Dashboard ของ zcrWAF demo ติดตามข้อมูลนี้แบบสด — ยอดรวม request ที่เห็น/อนุญาต/บล็อก สรุป top attacking IP แยกตามประเทศ และตัวนับ QPS แบบเรียลไทม์ ทำให้ทีมเห็นสถานการณ์สดโดยไม่ต้องรอสรุปรายวัน ดีโมนี้รันบนข้อมูลตัวอย่างของแพลตฟอร์มเอง จึงควรมองว่าเป็นการสาธิตสิ่งที่แดชบอร์ดติดตามได้ ไม่ใช่ตัวเลขมาตรฐานที่ทุกองค์กรจะเจอ
จุดสำคัญคือสัดส่วน allowed vs blocked เอง — แม้เว็บที่มี traffic น้อย ส่วนใหญ่ก็ยังเป็นผู้ใช้จริง แต่สิ่งที่ถูกบล็อกคือสิ่งที่ firewall ธรรมดาจะปล่อยผ่านไปเฉยๆ เพราะมันมาถูกพอร์ต
สัญญาณว่าองค์กรถึงเวลาต้องมี WAF
- มีเว็บไซต์หรือ API ที่เปิดให้บุคคลภายนอกเข้าถึงได้ โดยเฉพาะที่มีฟอร์ม login หรือรับข้อมูลลูกค้า
- เคยเจอทราฟฟิกพุ่งผิดปกติโดยไม่รู้สาเหตุ หรือสงสัยว่ามี bot กำลังลองรหัสผ่านอยู่
- ทีม dev ไม่มีเวลาตาม patch ช่องโหว่ทุกจุดทันเวลา ต้องการชั้นป้องกันเสริมระหว่างรอแก้ code จริง
- อยู่ในกลุ่มธุรกิจที่มีข้อมูลลูกค้าอยู่หลังฟอร์มเว็บ (e-commerce, การเงิน) ซึ่งข้อมูลรั่วผ่านช่องโหว่เว็บกระทบ PDPA โดยตรง
- ไม่มีวิธีแยกระหว่างทราฟฟิกจากผู้ใช้จริงกับ bot/scraper ที่มาสแกนหาช่องโหว่
เข้าเงื่อนไขสัก 2-3 ข้อจากด้านบน? zcrWAF คือชั้นป้องกันที่ออกแบบมาสำหรับตรงนี้โดยเฉพาะ
zcrWAF ครอบคลุมอะไรบ้าง
zcrWAF คัดกรองทราฟฟิกก่อนถึง origin server จริง ครอบคลุม:
องค์กรที่มีเว็บไซต์หรือ API สาธารณะและอยากรู้ว่าตอนนี้ traffic มีสัญญาณผิดปกติแบบนี้อยู่หรือไม่ ลองดูแพ็กเกจ zcrWAF ได้เลย
ติดต่อทีมงาน
อยากรู้ว่าเว็บไซต์หรือ API ที่ดูแลอยู่มีทราฟฟิกผิดปกติซ่อนอยู่หรือไม่ ทีมงานยินดีให้คำปรึกษาฟรี
แหล่งที่มา