รู้แล้ว! เบื้องหลัง Cloudflare ล่ม ที่แท้ฝีมือคนใน ไม่ใช่แฮกเกอร์

รายงานข่าวจาก Cloudflare เปิดเผยถึงเหตุการณ์ระบบล่มครั้งใหญ่เมื่อวันที่ 18 พฤศจิกายน 2568 เวลา 11:20 น. ตามเวลาสากลเชิงพิกัด (UTC) (ตรงกับเวลา 18:20 น. ของประเทศไทย) ซึ่งส่งผลกระทบให้ผู้ใช้งานอินเทอร์เน็ตไม่สามารถเข้าถึงเว็บไซต์ของลูกค้า Cloudflare ได้ โดยแสดงเป็นหน้าจอข้อผิดพลาด ภายในเครือข่ายของ Cloudflare

Cloudflare ยืนยันว่า ปัญหาดังกล่าวไม่ได้มีสาเหตุมาจาก การโจมตีทางไซเบอร์ หรือกิจกรรมที่เป็นอันตรายในลักษณะใด ๆ ไม่ว่าโดยตรงหรือโดยอ้อม

ต้นตอของปัญหา

สาเหตุหลักของระบบล่มเกิดจากการเปลี่ยนแปลงสิทธิ์ (Permissions) ในระบบฐานข้อมูลหนึ่งของบริษัท ซึ่งการเปลี่ยนแปลงนี้ส่งผลให้ฐานข้อมูลดังกล่าวสร้างรายการข้อมูลจำนวนมากเกินกว่าที่คาดไว้ลงใน “ไฟล์ฟีเจอร์” (feature file) ที่ระบบจัดการบอท (Bot Management system) ใช้งานอยู่ ทำให้ขนาดของไฟล์ฟีเจอร์ดังกล่าวเพิ่มขึ้นเป็นสองเท่า

เมื่อไฟล์ฟีเจอร์ที่มีขนาดใหญ่เกินกว่าที่คาดการณ์ไว้ ถูกเผยแพร่ไปยังเครื่องเซิร์ฟเวอร์ทั้งหมดที่ประกอบกันเป็นเครือข่ายของ Cloudflare ซอฟต์แวร์ที่ทำงานบนเครื่องเซิร์ฟเวอร์เหล่านี้ ซึ่งมีหน้าที่ในการกำหนดเส้นทางการจราจร (Route Traffic) ทั่วทั้งเครือข่าย ได้ทำการอ่านไฟล์ฟีเจอร์นี้เพื่ออัปเดตระบบจัดการบอท

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

การแก้ไขปัญหา

ในช่วงแรก Cloudflare เข้าใจผิดว่าอาการที่เห็นเกิดจากการโจมตีแบบ DDoS ขนาดใหญ่ แต่ในเวลาต่อมา ได้มีการระบุถึงปัญหาหลักที่แท้จริงอย่างถูกต้อง และสามารถหยุดการเผยแพร่ไฟล์ฟีเจอร์ขนาดใหญ่เกินกว่าที่คาดไว้ และแทนที่ด้วยไฟล์ฟีเจอร์เวอร์ชันก่อนหน้า การจราจรหลักของเครือข่ายส่วนใหญ่กลับมาทำงานตามปกติได้ภายในเวลา 14:30 น. (UTC) (ตรงกับเวลา 21:30 น. ของประเทศไทย) และระบบทั้งหมดของ Cloudflare กลับมาทำงานได้ตามปกติในเวลา 17:06 น. (UTC) (ตรงกับเวลา 00:06 น. ของวันที่ 19 พ.ย. ตามเวลาประเทศไทย)

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

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