ชี้แจงเหตุการณ์ AWS และ Cloudflare ล่มบางส่วนสาเหตุเพราะ ‘BGP Route leak’

เมื่อวานนี้มีเหตุการณ์เข้าลูกค้าของ AWS, Cloudflare และ Linode เข้าใช้งานไม่ได้บางส่วน โดยมีบทวิเคราะห์และชี้แจงถึงสาเหตุทั้งหมดว่าต้นเหตุเกิดมาจาก BGP Leak แต่ทำไมถึงกระทบในวงกว้างอย่างไรเราขออนุญาตสรุปคำชี้แจงจาก Cloudflare ที่เขียนไว้มาให้อ่านกันครับ

เครดิต : PacketFlow

พื้นฐานของอินเทอร์เน็ตในการ Routing จะมีลักษณะตามด้านบนคือมี Autonomous System แบ่งเป็นโซนและแทนด้วยเลข AS Number ที่ไม่ซ้ำกันจากนั้นผู้ดูแลรายใหญ่ๆ (ISP ระดับประเทศเป็นต้น) จะใช้โปรโตคอล BGP คุยกันเพื่อสร้าง Network Map ขึ้นมาให้รู้ได้ว่าหากต้องการจะไปที่จุดนี้ต้อง Route ทราฟฟิคไปที่ไหน

ไอเดียของปัญหาต้นตอมาจาก ISP เล็กๆ แห่งหนึ่งในตอนเหนือของรัฐแพนซิลวาเนียที่ชื่อ DQE Communications ซึ่งมี AS Number คือ AS33154 ได้มีการใช้ฟีเจอร์ BGP Optimizer ที่ทำให้สามารถแบ่ง IP Prefix (Split)ที่ได้รับให้ย่อยลง เช่น 104.20.0.0/20 กลายเป็น 104.20.0.0/21 และ 104.20.8.0/21 เปรียบเทียบได้กับการแบ่งเส้นทางออกเป็น 2 ทาง อย่างไรก็ดีมีกลไกในเครือข่ายที่สามารถ Route ภายใต้เขตเครือข่ายที่ดูแลได้อยู่แล้ว ปัญหาเพียงอย่างเดียวที่ไม่ควรเกิดคือการประกาศข้อมูลการ Split ให้โลกรู้…

credit : blog.cloudflare

ประเด็นคือ DQE ได้ประกาศ Specific Route ไปหาลูกค้าที่ชื่อ Allegheny Technologies Inc. ซึ่งมี AS Number คือ AS396531 และข้อมูลการ Route ก็ถูกส่งไปหา Verizon (AS701) จากนั้นหายนะก็เกิดขึ้นจากที่นี่เนื่องจาก Verizon ไม่ได้ปฏิบัติตาม Best Practice อย่างเคร่งครัดและนี่คือรอยต่อที่สามารถกระทบกับเครือข่ายระดับใหญ่ โดยเปรียบเสมือนว่า Verizon ได้ประกาศแก่โลกว่านี่คือ Route ที่ดีว่าเพราะเป็นเส้นทางที่เฉพาะเจาะจงกว่าไปยัง Cloudflare, AWS และ Linode (เหมือนบอกว่าจะไปห้างพารากอนใช้ทางนี้สั้นกว่าแทนที่บอกว่าไปสถานีสยามก่อน) ทันใดนั้นก็กระทบกับผู้ให้บริการรายใหญ่ทันทีคือ Amazon, Cloudflare และ Linode ซึ่งจากที่ทราฟฟิคที่กำลังวิ่งอยู่บน Highway (เครือข่ายขนาดใหญ่) ก็ไหลสู่ถนนท้องถิ่นแทนและกระทบกับการใช้งาน (รูปด้านบนแทนคำอธิบายเหตุการณ์ได้อย่างดี)

ป้องกันอย่างไร?

Cloudflare ได้แนะนำวิธีการป้องกันบางส่วนจาก Mutually Agreed Norms for Routing Security (MANRS) มาไว้คร่าวๆ ดังนี้

  • Hard Limited – ตั้งค่าจำกัด Prefix ที่ได้รับ โดย Router สามารถทำการปิดเซสชันหากจำนวนของ Prefix เกินค่า Threshold
  • IRR-Based Filtering – IRR หรือ Internet Routing Registry ทำให้เครือข่ายสามารถเพิ่ม Entries เข้าไปยัง Distributed Database ได้ โดย Network Operator รายอื่นสามารถใช้ IRR Record สร้างลิสต์ของ Prefix อย่างเฉพาะสำหรับเซสชัน BGP กับ Peer ของตนได้ ซึ่งหาก Verizon ใช้ก็คงไม่มีเครือข่ายไหนได้รับค่าจำเฉพาะแบบผิดๆ เหมือนในเหตุการณ์นี้ 
  • RPKI Resource Public Key Infrastructure ซึ่งเป็นวิธีการที่ออกแบบมาเพื่อป้องกัน BGP Hijacking ให้มั่นใจได้ว่า Prefix ไหนควรรับโดยไม่สนใจเส้นทางว่าคืออะไร โดย Cloudflare กล่าวว่าตนและ AT&T รวมถึงผู้ให้บริการอื่นๆ ต่างใช้งานเรียบร้อยแล้ว

โดยจากเหตุการณ์นี้ส่งผลกับทราฟฟิคระดับ Global ของ Cloudflare ราว 15% ซึ่งดูเหมือนว่าจะเป็นความโชคร้ายของ Cloudflare AWS และ Linode เพราะเปรียบเสมือนว่ามีผู้ร่วมทีมที่ละเลยการปฏิบัติหน้าที่ตาม Best Practice โดยข้างท้ายของบทความ Cloudflare กล่าวว่า “เราพยายามติดต่อทั้งโทรและอีเมลไปหาวิศวกรของ Verizon มากกว่า 8 ชม.แต่ก็ไม่มีการตอบรับ” ทั้งนี้ปัญหาคลี่คลายได้จากความช่วยเหลือของ DQE Communications เพื่อหยุดการ Advertise เส้นทางที่ถูก Optimized ไปยัง Allegheny นั่นเอง

ที่มา :  https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/ และ  https://www.bleepingcomputer.com/news/technology/bgp-route-leak-causes-cloudflare-and-amazon-aws-problems/


About nattakon

จบการศึกษา ปริญญาตรีและโท สาขาวิศวกรรมคอมพิวเตอร์ KMITL เคยทำงานด้าน Engineer/Presale ดูแลผลิตภัณฑ์ด้าน Network Security และ Public Cloud ในประเทศ ปัจจุบันเป็นนักเขียน Full-time ที่ TechTalkThai

Check Also

Jack Ma เผย แต่ละวัน Alibaba Group ถูกโจมตีมากถึง 300 ล้านครั้ง

ในงาน Forbes Global CEO Conference ในสิงคโปร์ Jack Ma ผู้ก่อตั้งแห่ง Alibaba Group ได้ออกมาเล่าถึงการที่ในแต่ละวัน Alibaba ต้องรับมือกับการโจมตีมากถึง 300 ล้านครั้ง แต่บริการหลักๆ นั้นก็ยังคงทำงานได้อย่างมั่นคงปลอดภัยอยู่

Oracle ออก Patch อุดช่องโหว่ 219 รายการ โดย 142 รายการในนั้นถูกโจมตีจากระยะไกลได้

Patch ประจำไตรมาสของ Oracle ในรอบล่าสุดนี้ ได้ออกมาด้วยกันถึง 219 รายการ โดย 34 รายการเป็นช่องโหว่บน Oracle MySQL, 142 รายการถูกโจมตีได้จากระยะไกล และมีช่องโหว่ความรุนแรงระดับ 10 ตามคะแนน CVSS ปรากฎบน Oracle NoSQL ด้วย โดยช่องโหว่ที่น่าสนใจในรอบนี้มีดังนี้