2 คะแนน โดย GN⁺ 27 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • BGP (Border Gateway Protocol) ซึ่งเป็นโปรโตคอลการกำหนดเส้นทางหลักของอินเทอร์เน็ต ทำหน้าที่เลือกเส้นทาง แต่ไม่มีฟังก์ชันตรวจสอบความปลอดภัยในตัว
  • ด้วยเหตุนี้ หากมีการเผยแพร่ข้อมูลเส้นทางที่ผิดพลาด ก็อาจเกิดการแย่งชิงทราฟฟิกหรือเหตุขัดข้องขนาดใหญ่ได้ และเพื่อป้องกันปัญหานี้จึงมีการนำ RPKI (Resource Public Key Infrastructure) มาใช้
  • RPKI ตรวจสอบความถูกต้องของเส้นทางด้วยวิธีการเข้ารหัสลับ และสามารถตัดสินเส้นทางที่ผิดว่าเป็น invalid แล้วบล็อกได้
  • Cloudflare ติดตามและเปิดเผยสถานะการใช้งาน RPKI ของ ISP และผู้ให้บริการทรานซิตรายใหญ่ทั่วโลก โดยยังมีบางรายที่ยังคงอยู่ในสถานะ unsafe
  • การกำหนดเส้นทางบนอินเทอร์เน็ตจะปลอดภัยได้ก็ต่อเมื่อผู้ให้บริการเครือข่ายรายใหญ่ทั้งหมดนำ RPKI และการทำฟิลเตอร์มาใช้ครบถ้วน

BGP ยังไม่ปลอดภัยอยู่หรือไม่

  • Border Gateway Protocol (BGP) คือ ‘บริการไปรษณีย์’ ของอินเทอร์เน็ต มีหน้าที่เลือกเส้นทางที่ดีที่สุดจากหลายเส้นทางที่ข้อมูลสามารถเดินทางไปได้
  • แต่เนื่องจากไม่มีฟังก์ชันด้านความปลอดภัยในตัว หากมีการเผยแพร่ข้อมูลเส้นทางที่ผิดพลาด ก็อาจทำให้เกิดเหตุขัดข้องของอินเทอร์เน็ตในวงกว้างหรือการแย่งชิงทราฟฟิกได้
  • เพื่อแก้ปัญหานี้ หากนำระบบรับรองชื่อ Resource Public Key Infrastructure (RPKI) มาใช้ ก็จะสามารถตรวจสอบความถูกต้องของเส้นทางได้
  • ISP และผู้ให้บริการทรานซิตระดับโลกหลายรายกำลังนำ RPKI มาใช้ และ Cloudflare ก็ติดตามพร้อมเผยแพร่ข้อมูลนี้
  • อินเทอร์เน็ตจะมีการกำหนดเส้นทางที่ปลอดภัยได้ก็ต่อเมื่อผู้ให้บริการเครือข่ายหลักทั้งหมดนำ RPKI มาใช้งาน

อัปเดตล่าสุด

  • 3 กุมภาพันธ์ 2026 ผู้ให้บริการทรานซิต Tier-1 ระดับโลก Sparkle(AS6762) ปฏิเสธพรีฟิกซ์ที่เป็น RPKI-invalid
  • 1 ตุลาคม 2025 ผู้ให้บริการทรานซิตรายใหญ่ของสโลวาเกีย Energotel(AS31117) เริ่มทำฟิลเตอร์เส้นทางที่เป็น RPKI-invalid
  • 28 สิงหาคม 2025 ISP รายใหญ่ของแคนาดา Bell Canada(AS577) ทำฟิลเตอร์เส้นทาง RPKI-invalid ภายในเครือข่าย
  • 22 กุมภาพันธ์ 2024 Deutsche Telekom(AS3320) ซึ่งเป็นหนึ่งใน ISP รายใหญ่ที่สุดของยุโรป ใช้ RPKI Origin Validation กับเครือข่ายทั่วโลก
  • 24 มกราคม 2024 Verizon(AS701) ของสหรัฐฯ ปรับใช้ RPKI Origin Validation อย่างสมบูรณ์ทั่วทั้งเครือข่าย

สถานะของผู้ให้บริการหลัก

  • Cloudflare เปิดเผยสถานะการลงนาม RPKI และการทำฟิลเตอร์ของผู้ให้บริการหลัก 31 ราย
  • ผู้ให้บริการทรานซิตหลักอย่าง Lumen, Arelion, Cogent, NTT, Sparkle, Hurricane Electric, GTT, TATA, Zayo, Vodafone อยู่ในสถานะ safe ทั้งหมด
  • ISP รายใหญ่อย่าง Comcast, AT&T, Verizon, Deutsche Telekom, KPN, Swisscom, Bell Canada ก็ลงนามและทำฟิลเตอร์เสร็จสมบูรณ์แล้วเช่นกัน
  • ผู้ให้บริการบางราย (Google, IIJ, OCN, Vivacom เป็นต้น) ใช้งานเพียงบางส่วน จึงถูกจัดอยู่ในกลุ่ม partially safe
  • China Telecom, KT, SK Broadband, TurkTelekom, Vodafone DE, PLDT, IBM Cloud, OVH เป็นต้น ยังอยู่ในสถานะ unsafe

BGP Hijacking คืออะไร

  • อินเทอร์เน็ตเป็นโครงสร้างเครือข่ายแบบกระจายที่ประกอบด้วย Autonomous Systems (AS) หลายพันระบบ
  • แต่ละโหนดจะตัดสินเส้นทางโดยอาศัยเฉพาะข้อมูลที่ได้รับจากโหนดที่เชื่อมต่อโดยตรงกับตนเอง
  • BGP Hijacking คือการที่โหนดที่เป็นอันตรายเผยแพร่ข้อมูลเส้นทางที่ผิดพลาดเพื่อดักทราฟฟิก
  • หากไม่มีโปรโตคอลความปลอดภัย ข้อมูลที่ผิดพลาดนี้อาจแพร่กระจายไปทั่วโลก ทำให้ข้อมูลถูกส่งผ่านเส้นทางที่ไม่ถูกต้องได้
  • RPKI ช่วยให้สามารถทำให้เส้นทางผิดเหล่านี้เป็นโมฆะและบล็อกได้ผ่านการตรวจสอบทางเข้ารหัสลับ

บทบาทของ RPKI

  • RPKI (Resource Public Key Infrastructure) คือเฟรมเวิร์กความปลอดภัยที่เชื่อมโยงเส้นทางกับระบบอัตโนมัติด้วยวิธีเข้ารหัสลับเพื่อใช้ในการตรวจสอบ
  • เนื่องจากเป็นไปไม่ได้ที่จะตรวจสอบเส้นทางอินเทอร์เน็ตมากกว่า 800,000 เส้นทางด้วยตนเอง RPKI จึงเข้ามาช่วยทำให้กระบวนการนี้เป็นอัตโนมัติ
  • เมื่อเปิดใช้งาน RPKI แม้จะมีการเผยแพร่ข้อมูลเส้นทางที่ผิดพลาด เราเตอร์ก็จะตัดสินว่าเป็น invalid และปฏิเสธ
  • ในบล็อกของ Cloudflare มีการอธิบายหลักการทำงานของ RPKI และกรณีศึกษาการปรับใช้อย่างละเอียด

เหตุใด BGP จึงยังไม่ปลอดภัย

  • โดยพื้นฐานแล้ว BGP ไม่มีโปรโตคอลความปลอดภัยในตัว
  • แต่ละ Autonomous System ต้องดำเนินการฟิลเตอร์เส้นทางที่ผิดพลาดด้วยตนเอง
  • Route leak เกิดขึ้นได้จากการตั้งค่าที่ผิดพลาดหรือการกระทำที่เป็นอันตราย และอาจทำให้บางส่วนของอินเทอร์เน็ตไม่สามารถเข้าถึงได้
  • BGP Hijacking สามารถชี้นำทราฟฟิกไปยังระบบอื่น ทำให้เกิดการขโมยข้อมูลหรือการดักฟังได้
  • การกำหนดเส้นทางจะปลอดภัยได้ก็ต่อเมื่อทุก AS ประกาศเฉพาะเส้นทางที่ถูกต้องและทำฟิลเตอร์อย่างเหมาะสม

วิธีทดสอบ

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

ความพยายามด้านความปลอดภัยเพิ่มเติม

  • ผู้ดูแลเครือข่ายและนักพัฒนากำลังดำเนินงานด้านมาตรฐานเพื่อปรับปรุงโปรโตคอลการกำหนดเส้นทางที่ยังไม่ปลอดภัย
  • Cloudflare เข้าร่วมโครงการ MANRS (Mutually Agreed Norms for Routing Security)
    • MANRS เป็นชุมชนระดับโลกที่มุ่งเสริมความแข็งแกร่งให้โครงสร้างพื้นฐานการกำหนดเส้นทาง โดยสมาชิกตกลงที่จะนำกลไกการทำฟิลเตอร์มาใช้
  • ยิ่งมีผู้ให้บริการเข้าร่วมมากเท่าไร ระดับความปลอดภัยของการกำหนดเส้นทางทั่วทั้งอินเทอร์เน็ตก็จะยิ่งดีขึ้น

สิ่งที่ผู้ใช้ทำได้

  • สามารถแชร์หน้า isbgpsafeyet.com เพื่อช่วยเผยแพร่ความจำเป็นของการนำ RPKI มาใช้
  • สามารถร้องขอให้ ISP หรือผู้ให้บริการโฮสติ้งของตนนำ RPKI มาใช้และเข้าร่วม MANRS
  • อินเทอร์เน็ตโดยรวมจะปลอดภัยได้ก็ต่อเมื่อ ISP รายใหญ่นำ RPKI มาใช้
  • Cloudflare เน้นย้ำข้อความว่า “เมื่ออินเทอร์เน็ตปลอดภัยขึ้น ทุกคนก็ได้ประโยชน์

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

 
GN⁺ 27 일 전
ความคิดเห็นจาก Hacker News
  • RPKI ไม่ได้ทำให้ BGP ปลอดภัยอย่างสมบูรณ์ แต่แค่ทำให้ ปลอดภัยขึ้น เท่านั้น
    การจี้เส้นทาง BGP ยังคงเกิดขึ้นได้ และ RPKI ตรวจสอบได้เพียงความเป็นเจ้าของ prefix โดยไม่ได้ปกป้องตัวเส้นทางเอง
    ผู้โจมตียังสามารถแกล้งทำเป็นว่าอยู่บนเส้นทางของ AS ผู้เสียหายเพื่อดักทราฟฟิกได้
    ส่วน BGPSec ที่ถูกเสนอมาเพื่อแก้ปัญหานี้ถูกมองว่าใช้งานจริงและนำไปติดตั้งได้ยาก

    • มีการเสนอ Proof-Carrying Data เป็นวิธีแก้ปัญหาความปลอดภัยของ BGP
      โดยให้แต่ละข้อความมีหลักฐานเชิงเข้ารหัสว่าถูกสร้างขึ้นอย่างถูกต้อง ซึ่งทำให้เวลาในการตรวจสอบคงที่ไม่ขึ้นกับขนาดเครือข่ายหรือจำนวน hop
      BGP ไม่ได้ไวต่อ latency มากนักและตัวโปรโตคอลก็เรียบง่าย จึงเป็นไปได้ว่าแนวทางนี้จะใช้ได้จริง
      ดูรายละเอียดเพิ่มเติมได้จาก บทความของ rot256.dev
      โดย RPKI ยังจำเป็นอยู่ แต่ BGPSec จะไม่จำเป็นอีกต่อไป
    • ปัจจุบันมีความพยายามลดผลกระทบของปัญหานี้ด้วย ASPA
      แม้จะยังอีกไกล แต่หน่วยงานหลักหลายแห่งกำลังมีส่วนร่วม
      ลิงก์ฉบับร่าง IETF
    • RPKI ทำให้ตรวจสอบความเป็นเจ้าของ prefix ได้ แต่เส้นทางยังคงอาศัยความเชื่อถือเป็นหลัก
      ให้ความรู้สึกเหมือนเสริมเฉพาะส่วนที่ตรวจสอบได้ง่าย
    • สภาวะในอุดมคติที่เรียกว่า ‘ปลอดภัย’ นั้นเป็นไปไม่ได้
      ท้ายที่สุดแล้วระบบเข้ารหัสทั้งหมดก็ยังต้องพึ่งพา registry หรือหน่วยงานที่มนุษย์เป็นผู้ดูแล
      RPKI ดีกว่าไม่มี แต่การตีความว่า “ตอนนี้ปลอดภัยพอแล้ว” เป็นเรื่องอันตราย
  • เมื่อเห็นว่า ISP รายใหญ่ในสหรัฐฯ และผู้ให้บริการมือถือรองรับฟีเจอร์นี้ ก็เลยรู้สึกว่า อัตราการใช้งานน่าจะสูงพอสมควร
    แต่ก็สงสัยว่าต้องมี ISP มากพอแค่ไหนจึงจะเรียกว่า ‘ปลอดภัย’ ได้ และมีความต่างกันตามภูมิภาคหรือไม่

    • ถ้า ทรานซิต ISP รายใหญ่ทั้งหมดเปิดใช้ ก็น่าจะเพียงพอ
      ถ้าเส้นทางที่ไม่ใช้ RPKI ผ่านทรานซิตไม่ได้ มันก็จะหมดความหมายไปเอง
    • ในความเป็นจริงมีผู้ให้บริการที่ถูกระบุว่า ‘unsafe’ มากกว่า 4 รายมาก คือ 254 ราย
      ต้องกด ‘Show all’ จึงจะเห็นรายการทั้งหมด
    • ฉันใช้ Sky ของสหราชอาณาจักรและมันถูกระบุว่า ‘unsafe’
      ถ้ามีตารางที่กรองตามประเทศและประเภทผู้ให้บริการได้ก็คงดี
    • T-Mobile USA แสดงผลการทดสอบว่า ทั้งผ่านและไม่ผ่านพร้อมกัน จนน่างง
    • ผู้ให้บริการรายใหญ่อย่าง British Telecom, NTT Docomo, Vodafone Espana, Starlink และ Rogers ก็ขึ้นว่า ‘unsafe’ เช่นกัน
      การบอกว่ามีเพียง 31 รายที่ปลอดภัยดูเป็นภาพที่มองโลกในแง่ดีเกินไป
  • ความที่เป็นเว็บไซต์ที่ Cloudflare ทำขึ้นมานั้น ชวนให้รู้สึกย้อนแย้ง
    อาจเป็นหน่วยงานที่มีโอกาสทำให้อินเทอร์เน็ตพังมากที่สุดในปี 2026 ก็ได้

    • ทุกวันนี้บริษัทต่าง ๆ มักทำ แคมเปญโน้มน้าวสาธารณะ ไปในทิศทางที่เป็นประโยชน์กับตัวเอง
      ถ้า RPKI เป็นประโยชน์ต่อธุรกิจก็จะโปรโมตว่าเป็น ‘เทคโนโลยีจำเป็นเพื่อความปลอดภัยของอินเทอร์เน็ต’
      ถ้าต้องการการยืนยันตัวตนก็จะชูเรื่อง ‘การคุ้มครองเด็ก’
      การตลาดแบบนี้เกิดซ้ำมาแล้วในอุตสาหกรรมวัคซีน อาวุธ และยาสูบ
  • ตอนนี้ RPKI ไม่ได้มีแค่ ROA อีกต่อไป
    การจี้ BGP อาจเกิดขึ้นได้ในจุดที่ไม่ใช่ทั้ง hop แรกหรือ hop สุดท้าย
    เว็บไซต์ควรถูกอัปเดตให้ทดสอบ ASPA-invalid prefix ด้วย

  • ISP Free SAS ถูกระบุว่า ‘unsafe’ แต่ผลทดสอบจริงกลับออกมาว่าสำเร็จ
    valid.rpki.isbgpsafeyet.com จัดการ prefix ที่ถูกต้องได้ถูกต้อง
    และ invalid.rpki.isbgpsafeyet.com ก็จัดการ prefix ที่ไม่ถูกต้องได้อย่างถูกต้องเช่นกัน

  • ISP ถูกระบุว่า unsafe ในตาราง แต่ผลทดสอบบอกว่าปลอดภัย

    • การอัปเดตล่าสุดของตารางคือวันที่ 3 กุมภาพันธ์ ดังนั้นดูเหมือนว่าจะมีการเปิดใช้ RPKI หลังจากนั้น
  • กราฟิกที่แสดงว่าผู้โจมตีเปลี่ยนเส้นทางทราฟฟิกไปยังเว็บไซต์อันตรายนั้น อาจทำให้เข้าใจผิดได้เล็กน้อย
    ถ้าใบรับรอง SSL ไม่ถูกต้อง เบราว์เซอร์จะบล็อกไว้ ทำให้ความเสียหายจริงมีขอบเขตจำกัด
    แต่ก็ยังสามารถถูกนำไปใช้เพื่อ โจมตีแบบปฏิเสธการให้บริการ (DoS) ได้อยู่

    • หากผู้โจมตียึดปลายทางได้ ก็อาจออก ใบรับรอง SSL ที่ใช้งานได้จริง ผ่าน Let’s Encrypt เป็นต้นได้เช่นกัน
  • RPKI และ ASPA ทำให้ปลอดภัยขึ้นจากเครือข่ายอื่นก็จริง แต่ก็เพิ่ม การพึ่งพา registry มากขึ้น
    หากประเทศของคุณถูกคว่ำบาตรและถูกตัดการเข้าถึง registry ก็จะไม่สามารถอัปเดตข้อมูลได้

    • จริง ๆ แล้ว registry ก็สามารถเพิกถอนการจัดสรรหมายเลขได้มานานแล้ว
      RPKI เพียงแค่ทำให้อำนาจนั้นแข็งแรงขึ้น
      ในท้ายที่สุดเราก็ยังทำเครือข่ายภายใต้ การอนุมัติของ IANA
      และถ้าจะหลุดจากสิ่งนี้ ก็ต้องออกแบบระบบการจัดสรร ASN และ IP ใหม่ทั้งหมด
  • BGP จะปลอดภัยจริงก็ต่อเมื่อเราเลิกใช้มันแล้วหันไปใช้ SCION
    ดู บทความวิกิของ SCION

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