WAF และระบบป้องกัน DDoS: วาง Cloudflare หน้าระบบองค์กรให้ป้องกันได้จริง

วันที่ทีมเปลี่ยน DNS ให้ระบบวิ่งผ่าน Cloudflare รายงานความคืบหน้าฉบับนั้นเขียนได้ว่า "ระบบมี WAF และระบบป้องกัน DDoS แล้ว" ประโยคนั้นจริงเพียงครึ่งเดียว ถ้าเครื่อง origin ยังรับ request จากใครก็ได้บนอินเทอร์เน็ต WAF คือชั้นกรอง request ระดับ HTTP ที่วางอยู่หน้าระบบ ส่วน Cloudflare ป้องกัน DDoS ได้เฉพาะ traffic ที่วิ่งผ่านเครือข่ายของมันเท่านั้น บทความนี้เขียนให้หัวหน้าทีม IT และเจ้าของระบบที่ต้องตอบคณะกรรมการว่าหน้าระบบป้องกันอะไรได้จริง เราจะแยกให้เห็นว่า WAF ทำอะไรได้และทำอะไรไม่ได้ การป้องกัน DDoS ทำงานคนละชั้นอย่างไร และการตัดสินใจข้อไหนต้องมีเจ้าของหลังวันขึ้นระบบ

WAF คืออะไร และสิ่งที่มันป้องกันไม่ได้

OWASP นิยาม WAF ว่าเป็น application firewall สำหรับแอปพลิเคชัน HTTP ที่ใช้ชุด rule กับบทสนทนา HTTP และระบุว่า rule เหล่านั้นโดยทั่วไปครอบคลุมการโจมตีที่พบบ่อย เช่น Cross-site Scripting (XSS) และ SQL Injection (ที่มา: OWASP, Web Application Firewall) ต่างจาก network firewall ที่ตัดสินจาก IP และ port เพราะ WAF อ่านเนื้อหาของ request เช่น path, header และ body แล้วเทียบกับ pattern ของการโจมตี WAF ของ Cloudflare คือบริการแบบนี้ที่ทำงานบนเครือข่ายของ Cloudflare ก่อน request จะเดินทางถึง origin จึงเห็นเฉพาะ request ที่วิ่งผ่าน proxy เท่านั้น

ข้อจำกัดอยู่ตรงนี้ WAF รู้จักหน้าตาของ request ที่อันตราย แต่ไม่รู้กติกาธุรกิจของระบบคุณ ถ้าผู้ใช้คนหนึ่งเปลี่ยนเลขเอกสารใน URL แล้วเปิดเอกสารของหน่วยงานอื่นได้ request นั้นหน้าตาปกติทุกประการ ไม่มี pattern ให้ WAF จับได้เลย ระบบที่ให้ผู้ยื่นคำขอกดอนุมัติคำขอของตัวเองได้ หรือ session ที่ไม่หมดอายุหลังออกจากระบบ ก็อยู่ในกลุ่มเดียวกัน ช่องโหว่ด้าน access control, authentication และ business logic แบบนี้ต้องแก้ในโค้ดและในการออกแบบสิทธิ์ ไม่ใช่ที่หน้าระบบ

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

สองอย่างนี้ทำงานคู่กัน ไม่ได้แทนกัน

DDoS ป้องกันยังไง: แยกให้ออกว่าโดนชั้นไหน

การโจมตีแบบ DDoS ต้องคิดแยกเป็นสองชั้น ชั้นแรกคือระดับ network และ transport (layer 3/4) ที่ยิง packet หรือ connection จำนวนมหาศาลจนท่อหรือตาราง connection เต็ม ชั้นนี้แก้ที่เซิร์ฟเวอร์ของคุณไม่ได้ เพราะเมื่อ traffic มาถึงเครื่อง ท่อก็เต็มไปก่อนแล้ว การป้องกันต้องเกิดบนเครือข่ายที่ใหญ่กว่าการโจมตี ก่อนที่ traffic จะเดินทางมาถึง

ชั้นที่สองคือระดับ application (layer 7) ซึ่ง request แต่ละอันหน้าตาเหมือนผู้ใช้จริง เช่น การยิงหน้าค้นหาที่ต้อง query ฐานข้อมูลหนักซ้ำเป็นหมื่นครั้ง ปริมาณข้อมูลอาจไม่สูงเลย แต่ทุก request บังคับให้ origin ทำงานจริง Cloudflare อธิบายว่า HTTP DDoS Attack Protection managed ruleset เป็นชุด rule ที่ตั้งไว้ล่วงหน้าเพื่อจับรูปแบบการโจมตี DDoS ที่รู้จักในระดับ layer 7 เปิดใช้งานอยู่ตลอดเวลา และผู้ใช้ปรับได้เพียงพฤติกรรมของมัน คือ action เมื่อพบการโจมตี และระดับความไว (sensitivity) ของการตรวจจับ (ที่มา: Cloudflare, HTTP DDoS Attack Protection)

เอกสารเดียวกันมีคำแนะนำที่หน่วยงานรัฐควรอ่าน คือถ้าคาดว่าจะมี traffic ของผู้ใช้จริงพุ่งสูงมาก ให้พิจารณาปรับการตั้งค่า DDoS protection เพื่อไม่ให้ traffic จริงถูกจัดเป็นการโจมตี ลองนึกถึงสถานการณ์สมมติที่หน่วยงานหนึ่งเปิดลงทะเบียนสิทธิ์ตอนเก้าโมงเช้า และคนจำนวนมากกดเข้าพร้อมกันในนาทีแรก รูปแบบนี้ใกล้เคียงกับการโจมตีระดับ layer 7 มาก ถ้าไม่มีใครแจ้งทีมที่ดูแลล่วงหน้า การตั้งค่าที่ปกป้องระบบในวันธรรมดาอาจกันผู้ใช้จริงออกในวันที่พวกเขาต้องการระบบมากเป็นพิเศษ เอกสารยังระบุว่า action หรือระดับความไวบางแบบอาจไม่มีในทุก plan จึงควรตรวจว่า plan ที่ใช้อยู่ปรับอะไรได้จริงก่อนถึงวันนั้น

Cloudflare ป้องกันได้เฉพาะ traffic ที่วิ่งผ่านมัน

หน้าแก้ปัญหา WAF ของ Cloudflare เขียนไว้ตรง ๆ ว่า Cloudflare ลดผลกระทบได้เฉพาะ request ที่อยู่ใน traffic ที่ผ่าน proxy และในรายการตรวจสอบกรณีการโจมตีหลุดถึงเครื่อง ข้อสุดท้ายถามว่า traffic อันตรายวิ่งตรงไปที่ IP ของ origin จนข้ามการป้องกันของ Cloudflare หรือไม่ พร้อมแนะนำให้บล็อก traffic ทั้งหมดที่ origin ยกเว้นที่มาจาก IP ของ Cloudflare (ที่มา: Cloudflare, Troubleshoot managed rules) แปลเป็นภาษาของผู้บริหารได้ว่า ถ้าใครรู้ IP จริงของเครื่อง WAF ที่ลงทุนไปจะถูกเดินอ้อมได้ทันที

IP จริงหลุดออกไปได้หลายทาง เช่น DNS record เก่าที่ชี้ตรงไปเครื่องก่อนย้ายเข้า Cloudflare, subdomain สำหรับ staging หรือส่งอีเมลที่ไม่ได้เปิด proxy หรือระบบเก่าที่เคยใช้ IP เดียวกันมาก่อน การไล่ปิดทุกช่องทางที่ IP อาจหลุดเป็นงานที่ไม่มีวันจบ คำถามที่ควรถามจึงไม่ใช่ว่า IP หลุดหรือยัง แต่เป็นว่าถ้าหลุดแล้ว origin จะยอมรับ request นั้นหรือไม่

เอกสารของ Cloudflare เรื่องการปกป้อง origin ให้ทางเลือกหลายระดับ และบอกข้อแลกเปลี่ยนของแต่ละทางไว้ (ที่มา: Cloudflare, Protect your origin server) สามทางที่เราเห็นว่าเป็นจุดตัดสินใจหลักมีดังนี้

• Allowlist IP ของ Cloudflare ที่ firewall ของ origin เอกสารจัดไว้ว่าปลอดภัยระดับปานกลาง ต้องตั้ง allowlist IP range ของ Cloudflare ไว้ที่ origin และระบุว่ามีความเสี่ยงจาก IP spoofing ทางนี้เริ่มได้เร็ว เพราะใช้ firewall rule บน Google Cloud หรือ Microsoft Azure ที่ทีมคุ้นเคยอยู่แล้ว แต่ต้องมีคนคอยตรวจว่ารายการที่ตั้งไว้ยังตรงกับที่ Cloudflare ประกาศ

• Authenticated Origin Pulls ช่วยยืนยันว่า request ที่ถึง origin มาจากเครือข่าย Cloudflare จริง เอกสารจัดว่าปลอดภัยสูง แต่ต้องใช้โหมดเข้ารหัส Full หรือ Full (strict) และต้องตั้งค่าฝั่งเซิร์ฟเวอร์เพิ่ม เช่น การอัปโหลดใบรับรอง ใบรับรองจึงกลายเป็นอีกรายการที่ต้องมีเจ้าของคอยดูแล

• Cloudflare Tunnel ให้ origin สร้างการเชื่อมต่อขาออกไปหาเครือข่าย Cloudflare เพียงทางเดียว โดยไม่ต้องเปิดเผย IP ของเครื่อง เอกสารจัดว่าปลอดภัยสูง และต้องติดตั้ง daemon ชื่อ cloudflared บนเครื่องหรือ virtual machine ของ origin ทางนี้ย้ายภาระจาก firewall rule ไปเป็น process หนึ่งตัวที่ต้อง monitor และอัปเดต

เราไม่คิดว่ามีทางไหนถูกสำหรับทุกระบบ เกณฑ์ที่เราใช้เลือกคือทีมไหนจะดูแลกลไกนั้นต่อได้หลังผู้พัฒนาส่งมอบงาน ถ้าทีม infra ขององค์กรดูแล firewall บนคลาวด์อยู่ทุกวัน allowlist อาจยั่งยืนกว่า Tunnel ที่ไม่มีใครจำได้ว่าติดตั้งไว้เครื่องไหน และไม่ว่าเลือกทางใด ถ้า IP เดิมเคยหลุดไปแล้ว การล็อก origin ปิดทางให้ request ที่เดินอ้อม WAF ได้ แต่ traffic ระดับ network ที่ยิงตรงมาที่ IP นั้นยังไปถึงเครือข่ายของผู้ให้บริการคลาวด์ของคุณอยู่ การเปลี่ยน IP ของ origin หลังล็อกเสร็จจึงเป็นอีกข้อที่ควรตัดสินใจไปพร้อมกัน

Managed rules กับ false positive: ดูผลก่อน แล้วค่อยบล็อก

managed ruleset คือชุด rule สำเร็จรูปที่ผู้ให้บริการดูแลและอัปเดตให้ การเปิดใช้งานกดเพียงไม่กี่ครั้ง แต่ผลของมันกระทบผู้ใช้จริงตั้งแต่ request แรก Cloudflare นิยาม false positive ว่าเป็น request ที่ถูกต้องแต่ถูกตรวจจับและจัดการเหมือนเป็นการโจมตี ในระบบองค์กร จุดที่ควรระวังคือฟอร์มที่ส่ง HTML จาก rich-text editor ช่องค้นหาหรือตัวกรองรายงานที่รับข้อความยาว และการอัปโหลดไฟล์ ข้อมูลเหล่านี้อาจมีหน้าตาคล้าย pattern ของ XSS หรือ SQL Injection ทั้งที่เป็นงานปกติของเจ้าหน้าที่

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

เมื่อเจอ false positive แนวทางในหน้าแก้ปัญหาเดียวกันคือเพิ่ม exception เพื่อข้าม rule สำหรับ request บางกลุ่ม ปรับค่าของ OWASP ruleset หรือปิดเฉพาะ rule ที่มีปัญหาแทนการปิดทั้ง ruleset ข้อที่เราเน้นเพิ่มคือ exception ทุกตัวต้องแคบ ระบุทั้ง path และ rule และมีเหตุผลกับชื่อผู้อนุมัติกำกับไว้ รายการตรวจสอบกรณีการโจมตีหลุดในหน้าเดียวกันก็ถามว่า managed rules ถูกข้ามด้วย exception อยู่หรือไม่ exception กว้าง ๆ ที่ตั้งไว้แก้ปัญหาเฉพาะหน้าเมื่อปีก่อน คือช่องที่ไม่มีใครจำได้ว่าเปิดไว้

Rate limiting เป็นคนละเครื่องมือกับการป้องกัน DDoS

rate limiting คือการกำหนดเพดานจำนวน request ต่อช่วงเวลาสำหรับ request ที่ตรงเงื่อนไข และกำหนด action เมื่อเกินเพดาน ตำแหน่งที่คุ้มค่าคือ endpoint ที่แต่ละ request มีต้นทุนหรือมีความเสี่ยง เช่น หน้า login ที่ถูกเดารหัสผ่าน หน้าส่ง OTP ที่แต่ละครั้งมีค่า SMS หรือ API ที่ระบบภายนอกเรียกใช้ เครื่องมือนี้ตอบปัญหาการใช้งานเกินขอบเขตจากผู้เรียกแต่ละราย ไม่ได้ออกแบบมาเพื่อรับการโจมตีที่กระจายมาจากแหล่งจำนวนมาก

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

ใครเป็นเจ้าของ rule หลังวันขึ้นระบบ

OWASP ระบุไว้ว่าการปรับแต่ง WAF ต้องได้รับการดูแลต่อเนื่องเมื่อแอปพลิเคชันมีการเปลี่ยนแปลง แปลว่าทุก release ที่เพิ่มฟอร์มหรือ endpoint ใหม่อาจทำให้เกิด false positive รอบใหม่ คำถามที่ควรตอบให้ได้ก่อนขึ้นระบบมีสี่ข้อ เมื่อผู้ใช้จริงถูกบล็อกเขาโทรหาใคร ใครมีสิทธิ์อนุมัติ exception ใครอ่าน security events เป็นประจำ และใครถือสิทธิ์ admin ของบัญชี Cloudflare

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

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

ข้อโต้แย้งที่ได้ยินบ่อย

ข้อโต้แย้งที่ได้ยินบ่อยคือ ระบบอยู่หลัง Cloudflare แล้ว ช่องโหว่ที่เหลือในโค้ดจึงรอแก้รอบหน้าได้ เหตุผลนี้เข้าใจได้ เพราะเวลาของทีมพัฒนามีจำกัด และ WAF ลดความเสี่ยงได้จริงกับการโจมตีที่มี pattern ชัด แต่ช่องโหว่ด้านสิทธิ์และ business logic ที่เล่าไว้ข้างต้นผ่าน WAF ไปได้ เพราะหน้าตาเหมือน request ปกติ และถ้า origin ยังเปิดรับ request ตรง ช่องโหว่ทุกข้อก็ยังเข้าถึงได้โดยไม่ผ่าน WAF เลย เรามอง WAF เป็นชั้นที่ลดความเสี่ยงระหว่างรอแก้ ทีมพัฒนายังเป็นคนที่ปิดช่องโหว่ได้จริง และควรได้เวลาสำหรับงานนั้นในแผน

จะเริ่มตรงไหน

ถ้าต้องเรียงลำดับใหม่ตั้งแต่ต้น เราจะปิดทางอ้อมก่อนปรับ rule เพราะ rule ที่ดีแค่ไหนก็ไม่มีความหมายถ้า request เดินอ้อมได้

1. ทำรายการ hostname ทั้งหมดขององค์กร แล้วแยกว่า record ไหนเปิด proxy ผ่าน Cloudflare และ record ไหนชี้ตรงไปที่เครื่อง

2. ทดสอบจากเครือข่ายภายนอกว่า origin ยังตอบ request ที่ส่งตรงไปที่ IP หรือไม่ ถ้ายังตอบ ให้เลือกวิธีล็อก origin และระบุทีมที่ดูแลกลไกนั้น

3. เปิด managed rules ในโหมดหรือขอบเขตที่ให้ดูผลได้ก่อน อ่าน security events ให้ครอบคลุมรอบงานจริงหนึ่งรอบ แล้วจึงเปลี่ยนเป็นบล็อก

4. ตั้ง rate limiting เฉพาะ endpoint ที่มีต้นทุนต่อ request เช่น login และ OTP โดยใช้ตัวเลขจาก traffic จริง

5. แจ้งทีมที่ดูแล Cloudflare ล่วงหน้าทุกครั้งที่มีวันที่คาดว่าผู้ใช้จะเข้ามาพร้อมกันจำนวนมาก

6. เขียนชื่อเจ้าของ rule ผู้อนุมัติ exception และผู้ถือสิทธิ์ admin ของบัญชีไว้ในเอกสารส่งมอบ

สรุป

WAF และระบบป้องกัน DDoS ของ Cloudflare ปกป้องได้เฉพาะสิ่งที่วิ่งผ่านมัน และกรองได้เฉพาะสิ่งที่มี pattern ให้จับ ถ้าจะหยิบไปใช้อย่างเดียวจากบทความนี้ ให้ตรวจว่า origin ของระบบสำคัญยังรับ request ตรงจากอินเทอร์เน็ตหรือไม่ คำตอบของคำถามนี้บอกได้ว่าประโยค "ระบบมี WAF แล้ว" ในรายงานของคุณจริงแค่ไหน

หากองค์กรของคุณกำลังวาง Cloudflare หน้าระบบเดิม หรือมี WAF อยู่แล้วแต่ยังไม่แน่ใจว่าใครเป็นเจ้าของ rule และอยากให้มีคนช่วยทบทวน เรายินดีคุยด้วย ไม่มีกำหนดเวลาบังคับ และไม่ต้องรีบตัดสินใจ

หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ ข้อมูลเพิ่มเติมเกี่ยวกับเราอยู่ที่ superdev.tech สำหรับองค์กรที่กำลังทบทวนการตั้งค่าหน้าระบบ เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน และหากคุยแล้วพบว่าสิ่งที่มีอยู่เพียงพอแล้ว เราจะบอกตรง ๆ