เปลี่ยนตัวบ่งชี้ภัยคุกคามของ Cloudflare ให้เป็นกฎ WAF แบบเรียลไทม์

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

เมื่อฉันอ่านการเปลี่ยนตัวบ่งชี้ภัยคุกคามของ Cloudflare ให้เป็นกฎ WAF แบบเรียลไทม์ สิ่งที่อยู่ในใจของฉันไม่ใช่คำว่า “การเข้าถึงอัตโนมัติแบบอัจฉริยะ” แต่เป็นรูปภาพที่ใช้งานได้จริงหลายภาพ: IP ถูกทำเครื่องหมายเป็นสีแดงและถูกดักจับในอีกสิบนาทีต่อมา; ASN ถูกทำเครื่องหมายว่ามีความเสี่ยงสูงและเป็นผลให้มีการแชร์ทางออกทั้งหมด ตัวอย่างการโจมตีที่มีอายุสั้นเพิ่งเข้าสู่ฐานกฎ และปริมาณการโจมตีถูกตัดออกไป เหลือกฎเก่าที่ยังคงมีผลใช้บังคับต่อไป เรียลไทม์ไม่ได้เป็นเพียงเกี่ยวกับความเร็วเท่านั้น แต่ยังบีบอัดวงจรการใช้งานของกฎ ความน่าเชื่อถือของข้อมูล และความรับผิดชอบในการจัดการลงในหน้าต่างเดียวกัน

กฎสามารถทำได้อย่างรวดเร็ว โดยมีเงื่อนไขว่าสามารถถอนออกได้

เมื่อตัวบ่งชี้ภัยคุกคามเข้าสู่ WAF ผู้ที่หมดความอดทนเป็นคนแรกมักไม่ใช่ผู้โจมตี แต่เป็นบุคคลที่ปฏิบัติหน้าที่ เนื่องจากเมื่อกฎมีผลบังคับใช้ สิ่งที่ตามมาจะไม่ใช่ “การปรับปรุงความปลอดภัย” แบบนามธรรม แต่เป็นการบาดเจ็บจากอุบัติเหตุ การอุทธรณ์ การย้อนกลับ และการตรวจสอบโดยเฉพาะ ตัวบ่งชี้ระดับ IP เป็นวิธีที่ง่ายที่สุดในการมอบหมาย พวกมันโจมตีด้วยแต้มเดียว เวลาเอาชีวิตรอดสั้น และค่าใช้จ่ายในการฟื้นฟูต่ำ ตัวบ่งชี้ เช่น ASN, ส่วนเครือข่าย, ลายนิ้วมือ TLS และการรวมคำขอ จะต้องระมัดระวังมากกว่ามาก ครอบคลุมพื้นที่ขนาดใหญ่และมีผลข้างเคียงที่ยากขึ้นเมื่อโจมตี

ส่วนที่มีคุณค่าจริงๆ ของเรื่องนี้ก็คือกฎไม่ได้เขียนเพียงครั้งเดียวแล้วเสร็จ แต่ปรากฏพร้อมกับ TTL แหล่งที่มา ช่วงการเข้าถึง และเงื่อนไขการยกเลิก หากไม่มีฟิลด์เหล่านี้ กฎแบบเรียลไทม์จะลดลงอย่างรวดเร็วจนกลายเป็นบันทึกการแบนที่หมดอายุ หากคุณบล็อกการโจมตีวันนี้ คุณจะเริ่มบล็อกผู้ใช้ปกติในวันพรุ่งนี้ กลิ่นเหม็นที่พบบ่อยที่สุดในการผลิตคือฐานกฎเริ่มหนาขึ้นเรื่อยๆ และสิ่งที่เหลืออยู่ไม่ใช่การตัดสินที่มีประสิทธิภาพ แต่เป็นอารมณ์ทางประวัติศาสตร์

ควรเหลือบัฟเฟอร์ไว้ระหว่างเลเยอร์ตัวบ่งชี้และเลเยอร์การดำเนินการ

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

เมื่อนำมาใช้จริง กฎจะดีที่สุดที่จะไม่เป็นสวิตช์เปิด/ปิดแบบเรียบ แต่เป็นชุดของสถานะที่สามารถแสดงความรุนแรงของการกระทำได้ บันทึกก่อน จากนั้นจึงท้าทาย จากนั้นจำกัดกระแส และเข้าสู่การสกัดกั้นในที่สุด ประโยชน์ของสิ่งนี้ก็คือตรงไปตรงมา กฎเกณฑ์สามารถค่อยๆ เพิ่มขึ้นเมื่อหลักฐานมีความแข็งแกร่งขึ้น และสามารถปรับลดระดับลงได้อย่างรวดเร็วเมื่อหลักฐานอ่อนแอลง สำหรับทีมรักษาความปลอดภัย สิ่งนี้สามารถรักษาความน่าเชื่อถือได้ดีกว่าการกรอกกฎทั้งหมดพร้อมกัน สำหรับฝั่งธุรกิจ อย่างน้อยพวกเขาก็เห็นความผันผวนที่ผิดปกติเมื่อปรากฏตัวครั้งแรก แทนที่จะรอจนกว่าตั๋วบริการลูกค้าจะกองพะเนินเพื่อดูว่าเกิดอะไรขึ้น

{
  "action": "challenge",
  "scope": "path:/login",
  "ttl": "15m",
  "confidence": 0.82
}

โครงสร้างนี้ดูเรียบง่าย แต่จริงๆ แล้วมีความสำคัญมาก เมื่อ confidence อยู่ในระดับต่ำ ความท้าทายอันดับแรกเป็นเหมือนวิจารณญาณทางวิศวกรรมมากกว่าการสกัดกั้นโดยตรง ttl จะหมดอายุโดยอัตโนมัติหลังจากหมดอายุ เพื่อหลีกเลี่ยงข้อมูลเก่าที่ค้างอยู่ที่ด้านข้าง scope ถูกลดขนาดเป็นเส้นทางหรือส่วนการจราจร เพื่อไม่ให้พื้นที่ความเสียหายจากอุบัติเหตุขยายใหญ่ขึ้นอย่างไม่สิ้นสุด

หากไม่มีการตรวจสอบ กฎก็จะยิ่งยาวขึ้นและดูเหมือนกองขยะ

ความกลัวที่ใหญ่ที่สุดของ WAF แบบเรียลไทม์ไม่ใช่อัตราการเข้าชมที่ต่ำ แต่ไม่มีใครรู้ว่าเกิดอะไรขึ้นหลังจากการปะทะ หลังจากที่กฎถูกเผยแพร่ คุณจะต้องสามารถมองย้อนกลับไปในสามสิ่ง: จำนวนการโจมตีจริงที่ถูกบล็อก จำนวนคำขอปกติที่ถูกฆ่าโดยไม่ได้ตั้งใจ และมีวิธีบายพาสใหม่หรือไม่หลังจากการโจมตี การเชื่อมต่อทั้งสามสิ่งนี้เข้าด้วยกันเท่านั้นจึงจะถือว่ากฎใช้งานได้และบำรุงรักษาได้ หากไม่มีสิ่งใดสิ่งหนึ่ง ในที่สุดมันก็จะกลายเป็นการกระทำเฉื่อยของการ “ปิดกั้นไว้ก่อน”

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

ชุดเครื่องมือนี้เหมาะสำหรับทีมที่มีความสามารถในการกำจัดอยู่แล้วเท่านั้น

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

เมื่อมีการนำระบบประเภทนี้ไปใช้ ค่าจะไม่ใช่แค่ “หยุดเร็วขึ้น” สิ่งที่สำคัญกว่าคือการเปลี่ยนการกำจัดความปลอดภัยจากการตัดสินด้วยตนเองเพียงครั้งเดียวให้เป็นห่วงโซ่การดำเนินการที่เพิกถอน ตรวจสอบได้ และไล่ระดับได้ ข้อดีของแพลตฟอร์มอย่าง Cloudflare ในการทำเช่นนี้ไม่ใช่แค่สามารถรับสัญญาณภัยคุกคามได้มากขึ้นเท่านั้น แต่ยังมีความสามารถในการส่งสัญญาณไปยังเลเยอร์กฎ จากนั้นเชื่อมต่อเลเยอร์กฎกลับไปที่การตรวจสอบ การย้อนกลับ และการตรวจสอบ หากไม่มีห่วงโซ่นี้ เรียลไทม์จะทำให้ข้อผิดพลาดเกิดขึ้นเร็วขึ้นเท่านั้น ด้วยห่วงโซ่นี้กฎเกณฑ์จึงสามารถเข้าสู่การผลิตได้อย่างแท้จริง