วิเคราะห์ความผิดปกติของ BGP ที่เกิดขึ้นในเวเนซุเอลา

 (blog.cloudflare.com)
1 คะแนน โดย GN⁺ 2026-01-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เกิด การรั่วไหลของเส้นทาง BGP (route leak) หลายครั้งในเครือข่าย CANTV(AS8048) ของเวเนซุเอลา ทำให้เส้นทางเครือข่ายบางส่วนถูกเผยแพร่อย่างผิดปกติ
  • ตามข้อมูลจาก Cloudflare Radar พบ เหตุการณ์รั่วไหล 11 ครั้ง นับตั้งแต่เดือนธันวาคม ซึ่งมีแนวโน้มสูงว่าเป็นความผิดพลาดทางเทคนิคจาก นโยบายการกำหนดเส้นทางที่ไม่รัดกุม
  • เหตุการณ์ครั้งนี้อยู่ในรูปแบบที่ AS8048 ส่งต่อเส้นทางที่ได้รับจากผู้ให้บริการต้นทาง AS6762(Sparkle) ไปยัง ผู้ให้บริการอีกราย AS52320(V.tal GlobeNet) ซึ่งเป็นโครงสร้างแบบ Type 1 hairpin leak ตามแบบฉบับ
  • การตรวจสอบต้นทางเส้นทางด้วย RPKI (ROV) ใช้ไม่ได้ผลกับกรณีนี้ และจำเป็นต้องมีมาตรฐานใหม่อย่าง ASPA(Autonomous System Provider Authorization) และ RFC9234 เพื่อป้องกันการรั่วไหลดังกล่าว
  • เนื่องจาก BGP มีโครงสร้างที่อาศัยความเชื่อถือเป็นพื้นฐาน อุบัติเหตุลักษณะนี้จึงเกิดขึ้นได้บ่อย และการนำเทคโนโลยีอย่าง ASPA·Peerlock·RFC9234 มาใช้คือหัวใจสำคัญของการดำเนินงานอินเทอร์เน็ตอย่างปลอดภัย

แนวคิดของการรั่วไหลของเส้นทาง BGP

  • BGP(Route Gateway Protocol) เป็นโปรโตคอลสำหรับแลกเปลี่ยนเส้นทางระหว่างระบบอัตโนมัติ (AS) บนอินเทอร์เน็ต
    • ความสัมพันธ์ระหว่างเครือข่ายประกอบด้วยรูปแบบ ลูกค้า-ผู้ให้บริการ(customer-provider) หรือ เพียร์(peer-peer)
  • การรั่วไหลของเส้นทาง(route leak) ถูกนิยามใน RFC7908 ว่าเป็น “การเผยแพร่ข้อมูลการกำหนดเส้นทางเกินขอบเขตที่ตั้งใจไว้”
    • ตัวอย่าง: ลูกค้าส่งต่อเส้นทางที่ได้รับจากผู้ให้บริการไปยังผู้ให้บริการอีกรายอีกครั้ง
  • การรั่วไหลลักษณะนี้เป็นการละเมิด กฎ valley-free routing ทำให้ทราฟฟิกวิ่งผ่านเส้นทางที่ผิดปกติ
    • ผลลัพธ์คืออาจเกิดปัญหาอย่างความแออัดของเครือข่าย ความล่าช้า และการสูญหายของทราฟฟิก

กรณีการรั่วไหลของเส้นทางของ AS8048(CANTV)

  • Cloudflare Radar ยืนยันว่า AS8048(CANTV) ได้ส่งต่อเส้นทางที่ได้รับจาก AS6762(Sparkle) ไปยัง AS52320(V.tal GlobeNet)
    • นี่เป็นรูปแบบของ route leak อย่างชัดเจน
  • ต้นทางของเส้นทางที่รั่วไหลคือ AS21980(Dayco Telecom) ซึ่งเป็น เครือข่ายลูกค้า ของ AS8048
    • ความสัมพันธ์ระหว่างทั้งสอง AS ได้รับการยืนยันว่าเป็น ความสัมพันธ์แบบผู้ให้บริการ-ลูกค้า จากข้อมูลของ Cloudflare Radar และ bgp.tools
  • ในเส้นทางดังกล่าวมีการทำ prepend หลายครั้งโดย AS8048
    • การ prepend เป็นเทคนิคที่ทำให้เส้นทางนั้นน่าสนใจน้อยลง เพื่อชี้นำให้ทราฟฟิกไปยังเส้นทางอื่น
    • ดังนั้นความเป็นไปได้ที่จะเป็น MITM(การโจมตีแบบคนกลาง) โดยเจตนาจึงต่ำ
  • การรั่วไหลเกิดขึ้นหลายครั้งระหว่าง 2 มกราคม 2026 เวลา 15:30~17:45 UTC และมีแนวโน้มว่าเกิดจาก ข้อผิดพลาดของนโยบายเครือข่ายหรือปัญหาการลู่เข้า
  • จากบันทึกของ Cloudflare Radar พบว่าเกิด การรั่วไหลลักษณะคล้ายกัน 11 ครั้งตั้งแต่เดือนธันวาคม จึงประเมินได้ว่าเป็น ปัญหาความไม่พร้อมของนโยบายอย่างต่อเนื่อง

สาเหตุทางเทคนิคและปัญหาเชิงนโยบาย

  • มีความเป็นไปได้ว่า AS8048 ตั้งค่า นโยบาย export routing ไปยัง ผู้ให้บริการ AS52320 ไว้อย่างหลวมเกินไป
    • หากใช้เพียง prefix list ที่อิงกับ IRR แทนการใช้แท็กลูกค้า BGP community ก็อาจทำให้เกิดการส่งต่อเส้นทางที่ผิดพลาดได้
  • ข้อผิดพลาดเชิงนโยบายลักษณะนี้สามารถป้องกันได้ด้วย คุณสมบัติ Only-to-Customer(OTC) ของ RFC9234
    • OTC จะกำหนดบทบาท BGP (ลูกค้า·ผู้ให้บริการ·เพียร์) อย่างชัดเจน เพื่อบล็อกการเผยแพร่เส้นทางที่ผิดพลาด

บทบาทของ RPKI และ ASPA

  • Sparkle(AS6762) ยังไม่ได้ใช้งาน RPKI Route Origin Validation(ROV) อย่างสมบูรณ์ แต่
    • กรณีนี้เป็นความผิดปกติของ เส้นทาง(path) จึงไม่สามารถป้องกันด้วย ROV ได้
  • ASPA(Autonomous System Provider Authorization) ให้การตรวจสอบที่อิงตามเส้นทาง
    • โดยแต่ละ AS จะระบุรายการผู้ให้บริการต้นทางที่ได้รับอนุญาต ทำให้สามารถบล็อกเส้นทางที่ผิดปกติได้โดยอัตโนมัติ
    • ตัวอย่าง: หาก AS6762 ประกาศว่า “ไม่มีผู้ให้บริการต้นทาง” เครือข่ายอื่นก็จะสามารถปฏิเสธเส้นทางที่ผิดพลาดซึ่งมี AS6762 รวมอยู่ได้
  • ASPA ทำงานบนพื้นฐานของ RPKI และมี ผลโดยตรงต่อการป้องกัน route leak

ข้อเสนอเพื่อสร้าง BGP ที่ปลอดภัย

  • โดยธรรมชาติแล้ว BGP เป็น โปรโตคอลที่อาศัยความเชื่อถือ ดังนั้นการรั่วไหลจากข้อผิดพลาดเชิงนโยบายหรือความผิดพลาดของมนุษย์จึงเกิดขึ้นบ่อย
  • หากใช้งานเทคโนโลยีอย่าง ASPA, RFC9234, Peerlock/Peerlock-lite ควบคู่กัน จะช่วยให้
    • เสริมความแข็งแกร่งของการตรวจสอบเส้นทาง
    • บล็อกการเผยแพร่เส้นทางที่ผิดพลาด
    • เพิ่มเสถียรภาพของเครือข่าย
  • ปัจจุบัน RIPE รองรับการสร้างวัตถุ ASPA แล้ว และ
    • ผู้ดูแลระบบควรส่งคำขอ การรองรับ RFC9234 ไปยังผู้ผลิตอุปกรณ์เครือข่าย
  • การนำมาตรฐานเหล่านี้มาใช้ร่วมกันคือ วิธีสำคัญในการป้องกันอุบัติเหตุ BGP แบบกรณีเวเนซุเอลา

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-01-09
ความคิดเห็นใน Hacker News

  • ผมว่าทิศทางคอมเมนต์ที่นี่ค่อนข้างเหนือความคาดหมาย ทุกคนพูดถึง ความหวาดกลัวต่อบริษัทอเมริกัน แต่ดูไม่ค่อยเกี่ยวกับเนื้อหาในบทความเท่าไร
    บทความของ Cloudflare แค่อธิบายวิธีการทำงานของ BGP และชี้ว่ามี การรั่วไหลของเส้นทาง จาก ISP ในเวเนซุเอลาเกิดขึ้นบ่อย
    แน่นอนว่า Cloudflare อาจผิดหรืออาจกำลังปิดบังอะไรบางอย่างก็ได้ แต่ในบทความไม่มีส่วนไหนบอกว่าพวกเขาเข้าไปแทรกแซงโดยตรง ผมเลยสงสัยว่าทุกคนเห็นอะไรถึงมั่นใจขนาดนั้น

    • ผมไม่คิดว่าบทความนี้มีหลักฐานอะไรที่น่ากลัว
      แต่ถ้าดูกรณี Stuxnet หรือ Dual EC DRBG ก็ไม่ควรประเมินความสามารถของรัฐบาลในการใช้ 0-day ต่ำเกินไป
      เพื่อนของผมเคยทำงานที่บริษัท FANG และบอกว่าเคยเห็นการ ส่งสตรีมข้อมูลให้รัฐบาลโดยตรง จริง ๆ แบ็กดอร์ของ ISP ก็มีอยู่จริง (Room 641A)
      ถ้า Cloudflare ให้ความร่วมมือตามหมายศาลจริง พวกเขาจะสามารถเขียนบทความปฏิเสธเรื่องนั้นได้ตามกฎหมายหรือ?
      เพราะแบบนี้คนถึงมี ความระแวงโดยพื้นฐาน กันอยู่แล้ว ข้อสรุปของ Cloudflare ที่ว่า “นี่เป็นปัญหาเก่าที่ไม่ได้มีอะไรพิเศษ” เลยฟังดูไม่ค่อยหนักแน่น
    • ผมก็สงสัยเหมือนกัน ไม่เข้าใจว่าบทความนี้เชื่อมไปสู่การแทรกแซงของรัฐบาลสหรัฐได้อย่างไร
      แล้วก็อยากรู้ด้วยว่าในโครงสร้างของ BGP มีเหตุผลอะไรที่ทำให้สหรัฐทำเรื่องแบบนี้ได้ง่ายกว่าประเทศอื่นหรือเปล่า
    • น่าจะเป็นเพราะคนส่วนใหญ่ตัดสินจากแค่พาดหัว อีกทั้งสหรัฐก็มี ภูมิหลังทางประวัติศาสตร์ ที่เคยทำเรื่องแบบนี้มาจริง
      ตอนนี้ความเห็นสาธารณะต่อรัฐบาลสหรัฐค่อนข้างประชดประชันและไม่ไว้ใจอยู่แล้ว เลยทำให้แม้แต่เหตุการณ์เล็ก ๆ ก็ถูกมองด้วยความสงสัย
      หรือไม่ก็อาจเป็นแค่บัญชีโซเชียลจากรัสเซียหรือจีนก็ได้ แต่ใครจะไปรู้
    • ไม่กี่วันก่อนก็มีบทความคล้ายกัน — บทความของ loworbitsecurity ที่เชื่อมความผิดปกติของ BGP เข้ากับทฤษฎีการบุกเวเนซุเอลา
      แล้วก็มี บทความ CNN ที่รายงานว่าทรัมป์พูดถึงความเป็นไปได้ในการใช้ปฏิบัติการทางทหารแม้กับชาติพันธมิตร
      ถ้าเป็นรัฐบาลชุดนี้ ผมกลับคิดว่าพวกเขาน่าจะ ออกมาคุยโวเรื่องการโจมตีแบบนี้อย่างเปิดเผย เสียมากกว่า เพราะงั้นตอนนี้ผมยังเชื่อฝั่ง “แค่ตั้งค่าผิดพลาดธรรมดา”
      แต่ก็เป็นธรรมดาที่ความไม่ไว้วางใจของคนจะเพิ่มขึ้น เพราะทุกครั้งที่สหรัฐเป็นข่าวช่วงนี้ก็มักเกี่ยวกับการข่มขู่ การถอนตัว หรือมาตรการคว่ำบาตร

  • ถึงจะอ่านตอนง่วง ๆ แต่บทความก็น่าสนใจดี การวิเคราะห์ AS path prepending สนับสนุนทฤษฎีว่า “เป็นอุบัติเหตุ” ได้ดี
    ถ้าเป็นรัฐที่ต้องการดักทราฟฟิก ก็คงไม่มีเหตุผลจะตั้งใจทำให้เส้นทางยาวขึ้น
    มีโอกาสสูงว่าเป็นแค่ ความผิดพลาดในการตั้งค่า routing ธรรมดา ๆ BGP ยังเป็นระบบที่อาศัยความเชื่อใจกันอยู่มาก แค่พิมพ์ผิดนิดเดียวก็ส่งผลไปทั่วโลกได้
    คำอธิบายแบบ export filter ที่หายไป ดูสมเหตุสมผลกว่าการมองว่าเป็นเจตนาร้าย

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

  • เอกสารหนึ่งจาก Snowden leaks ที่น่าอ้างถึงคือ NSA Network Shaping 101
    เป็นเอกสารที่เขียนในปี 2007 อธิบายเรื่อง ASIN และการควบคุมทราฟฟิกระดับเลเยอร์ 3

    • แต่คำว่า “layer 3 shaping” ในเอกสารนี้ดูเหมือนไม่ค่อยเกี่ยวกับความผิดปกติของ BGP เท่าไร
      มันแค่ระดับอธิบายโครงสร้างว่าทราฟฟิกที่ส่งไปยัง IP หนึ่ง ๆ จะวิ่งผ่านลิงก์นั้นอย่างไร
    • ตลกดีที่แม้แต่ NSA เองยัง ใช้แนวคิด ASN ผิด เหมือนกับพูดว่า “เพื่อนบ้านของฉันอาศัยอยู่ในสตริง ‘123 Main Street’”

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

    • ผมจำได้ว่าเคยมีเพื่อนคนหนึ่งพูดถึงการดักฟังที่ถูกกฎหมาย แล้วสีหน้าของเขาตอนนั้นแข็งไปทั้งหน้า
      โครงสร้างพื้นฐานเพื่อการสอดส่อง แบบนี้มีมานานแล้ว และญี่ปุ่นก็เคยทำการมอนิเตอร์ทราฟฟิกแบบเรียลไทม์ตั้งแต่ปี 2003
      ตอนนี้ เทคโนโลยี DPI เองก็ทำได้ง่ายเกินไปแล้ว
    • วงจรของความไม่ไว้วางใจแบบนี้เหมือนจะเกิดซ้ำทุก 10 ปี
      คนที่เพิ่งเข้ามาในวงการเริ่มต้นอย่างไร้เดียงสา แต่สุดท้ายก็เห็นโครงสร้าง ความแนบแน่นระหว่างรัฐบาลกับบริษัท แล้วสูญเสียความเชื่อใจ
      พอเวลาผ่านไป คนรุ่นใหม่ก็จะเข้ามาและผ่านกระบวนการเดิมซ้ำอีก
    • การมองว่า Cloudflare พยายามปกปิดปฏิบัติการของรัฐบาลสหรัฐดูเป็นการตีความเกินไป
      ใจความของบทความคือ Hanlon’s razor หรือก็คือควรสงสัยความผิดพลาดก่อนความมุ่งร้าย
      แน่นอน ถ้า Cloudflare บิดเบือนข้อเท็จจริงจริงก็ควรถูกวิจารณ์ แต่ตอนนี้ยังไม่มีหลักฐานแบบนั้น
    • เรื่องที่ว่า “บริษัทพัวพันกับรัฐบาล” นั้นเป็นแบบนี้ทุกประเทศอยู่แล้ว ไม่ใช่เรื่องใหม่อะไร

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

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

  • บทความนี้เป็นการ ทบทวน BGP ที่ดี
    ตอนที่ผมเคยทำงานเป็นวิศวกรเครือข่าย ผมใช้ BGP community magic เยอะมาก และบางทีก็คิดว่าถ้า BGP แสดงได้แค่สามแบบคือ provider, customer, peer มันอาจจะง่ายกว่านี้มาก

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

  • ครั้งหนึ่ง Google Maps เคยพาผมออกจากทางด่วนไปผ่านลานจอดรถ Walmart แล้วไปขึ้นอีกทางด่วนหนึ่ง
    ตอนนั้นผมคิดว่าเป็นแค่ข้อผิดพลาดของอัลกอริทึมธรรมดา แต่ถ้ามันพาไปผ่าน McDonald’s drive-thru ผมคงเริ่มสงสัยว่าเป็นแผนสมคบคิด
    กรณีนี้ก็คล้ายกัน มองว่าเป็นความผิดพลาดธรรมดาดูน่าเชื่อถือกว่า

    • ที่การรั่วไหลของเส้นทาง BGP ไม่เกิดบ่อยกว่านี้ เป็นเพราะ การกรองของ ISP อื่น ๆ ความผิดพลาดแบบนี้เกิดขึ้นได้ง่ายกว่าที่คิด

  • ผมรู้สึกน่ากลัวนิด ๆ ที่โครงสร้างพื้นฐานหลักของอินเทอร์เน็ตถูกขับเคลื่อนโดย บริษัทอเมริกันเป็นศูนย์กลาง
    ตอนนี้ประเทศอื่น ๆ ก็ควรสร้างโครงสร้างที่เป็นอิสระของตัวเองได้แล้ว

    • แต่อินเทอร์เน็ตเองก็เป็น ระบบที่กองทัพ มหาวิทยาลัย และบริษัทของสหรัฐสร้างขึ้น ตั้งแต่แรกอยู่แล้ว จะบอกว่าน่าตกใจมากก็คงไม่ใช่
      งั้นก็อยากรู้ว่าใครควรเป็นคนดูแลแทน
    • ยุโรปเองก็สามารถสร้างบริษัทแบบ Cloudflare ได้เหมือนกัน แต่ปัญหาคือ สมองไหลและการลงทุนไม่พอ
    • อินเทอร์เน็ตมีความเป็น กระจายศูนย์ อยู่โดยธรรมชาติ ไม่มีอะไรอย่างเราเตอร์ BGP ส่วนกลางหรอก

  • ผมเฝ้าดูอุบัติเหตุ BGP มานานแล้ว และรู้สึกเสมอว่าการแยกแยะระหว่าง การเปลี่ยนแปลงที่ตั้งใจ, ความผิดพลาด, และ ความขัดข้องเชิงโครงสร้าง เป็นเรื่องยาก
    เพราะงั้นผมจะถามสามคำถามก่อนเสมอ: ขอบเขตผลกระทบค่อย ๆ กว้างขึ้นไหม, เส้นทางเปลี่ยนแบบสมมาตรหรือเปล่า, และการกู้คืนกลับมาสะอาดเรียบร้อยไหม
    จากนั้นผมจะดูการเปลี่ยนแปลงของ AS-path prepending ก่อน แล้วเปรียบเทียบการมองเห็นในแต่ละภูมิภาค
    สุดท้ายค่อยไล่ดูว่า “ใครได้ประโยชน์” ผมเองก็สงสัยว่าคนอื่นใช้ตัวชี้วัดอะไรในการตรวจจับปัญหาแบบนี้

  • การครอบคลุมทั่วโลก ของ Cloudflare น่าทึ่งจริง ๆ

    • แต่ผมกลับคิดว่านั่นเองคือ ความรวมศูนย์ที่อันตรายต่อโลก และตอนนี้บริษัทที่ไม่ใช่สหรัฐก็ควรยืนได้อย่างอิสระแล้ว
    • ถ้าเป็นเครือข่าย Anycast ก็สามารถสังเกต BGP ได้จากหลายจุดอยู่แล้ว ไม่ใช่ความสามารถเฉพาะของ Cloudflare
      เพียงแต่พวกเขาเป็น องค์กรที่ขับเคลื่อนด้วยวิศวกรรม เลยเก่งในการเผยแพร่การวิเคราะห์แบบนี้ต่อสาธารณะ
    • ที่จริงใคร ๆ ก็ทำการวิเคราะห์คล้ายกันได้ด้วย RIPE RIS
    • Cloudflare มีทรัพยากรเยอะ และพูดตามตรงว่าเป็น บริษัทที่ยอดเยี่ยม