اختطاف BGP لا يزال عيبًا هيكليًا في توجيه الإنترنت — اعتماد RPKI هو الحل | IRCNF - Intelligent Reliable Custom Next-gen Frameworks

بروتوكول يدير الإنترنت بدون مصادقة مدمجة

في كل مرة تفتح فيها موقعًا، تعبر حركة مرورك عشرات الأنظمة المستقلة — الشبكات المدارة بشكل مستقل من قبل مزودي الإنترنت ومقدمي الخدمات السحابية والمؤسسات. تتبادل هذه الشبكات معلومات التوجيه باستخدام بروتوكول BGP، وهو نظام صُمم عام 1989 على منديل ورقي في اجتماع IETF. يعمل البروتوكول على أساس الثقة: عندما تُعلن شبكة أنها تملك نطاقًا من عناوين IP، تصدقها جميع الشبكات الأخرى. لا يوجد أي دليل تشفيري مطلوب.

أنتج هذا العجز الهيكلي عقودًا من الحوادث. في أبريل 2010، اختطفت شركة China Telecom مسارات 15% من حركة الإنترنت العالمية، وأعادت توجيهها عبر شبكات صينية لمدة 18 دقيقة. في 2018، اختطف مهاجمون مسارات BGP لخوادم DNS الخاصة بـ Amazon Route 53 لسرقة 152,000 دولار من عملة Ethereum. في 2022، تسبب خطأ في التكوين في Vodafone Germany في تسرب BGP أدى إلى تعطيل الاتصال لملايين المستخدمين في أوروبا. هذه ليست حالات نادرة — سجل باحثو CAIDA أكثر من 1,700 حدث مؤكد لاختطاف BGP في 2023 وحده.

RPKI: الحل التشفيري المتاح منذ 2012

RPKI هو إطار معياري من IETF في RFC 6480 (2012) يربط ملكية عناوين IP بشهادات تشفيرية. يقوم مشغلو الشبكات بإنشاء ROAs — تصديقات موقعة تقول 'النظام المستقل X هو المصدر الشرعي للبادئة Y'. يمكن للموجهات المكونة للتحقق من هذه التوقيعات اكتشاف ورفض إعلانات المسار غير الصالحة قبل انتشارها.

لا يقوم RPKI بتشفير حركة المرور. لا يخفي جداول التوجيه. إنه يحل تحديدًا مشكلة التحقق من المصدر: التحقق من أن الشبكة التي تدعي أنها مصدر مسار لديها الحق في ذلك. هذا يلتقط غالبية عمليات اختطاف BGP الواقعية، سواء كانت خطأ في التكوين أو اختطافًا متعمدًا للبادئة من قبل جهات ضارة تنتحل هوية شبكات شرعية.

الأرقام حول فعالية RPKI قوية. دراسة 2023 من NIST وجامعة Maryland وجدت أن الشبكات التي تفرض RPKI (ROV) رفضت 95% من محاولات الاختطاف المختبرة. بدون ROV، قبلت نفس الشبكات 94% من الإعلانات الضارة.

أرقام التبني: أين يقف الإنترنت فعليًا في 2026

تسارع تبني RPKI منذ 2020، لكن الإنترنت بعيد عن الحماية. اعتبارًا من مايو 2026، يظهر لوحة تحكم RIPE NCC حوالي 47% من بادئات IPv4 العالمية مغطاة بـ ROAs صالحة. بالنسبة لـ IPv6، التغطية حوالي 52%. لكن إنشاء ROAs هو نصف المعادلة فقط — يجب على الشبكات أيضًا فرض التحقق من صحة أصل المسار، رفض المسارات التي تفشل في فحوصات RPKI.

تبني التطبيق (ROV) يتخلف أكثر. تشير قياسات مرصد MANRS (Mutually Agreed Norms for Routing Security) التابع لجمعية الإنترنت إلى أن حوالي 35% من الأنظمة المستقلة تفرض التحقق من RPKI بنشاط بحلول أوائل 2026. الفجوة بين 'لديه ROAs' و 'يفرضها فعليًا' هي المكان الذي تستمر فيه عمليات الاختطاف.

مزودو الخدمات السحابية الكبرى هم المتبنون الرائدون. Amazon Web Services و Google Cloud و Microsoft Azure و Cloudflare جميعهم يفرضون RPKI ROV على شبكاتهم. Cloudflare على وجه الخصوص نشر إحصائيات التطبيق علنًا، موضحًا أنه يرفض ملايين إعلانات المسار غير الصالحة شهريًا. المتخلفون هم بشكل أساسي مزودو الإنترنت الإقليميون في جنوب شرق آسيا وأمريكا اللاتينية وأجزاء من أفريقيا، حيث كان الاستثمار في أمن التوجيه أقل تاريخيًا.

لماذا يتوقف التبني الكامل: واقع المشغل

الحالة التقنية لـ RPKI لا لبس فيها. العوائق التشغيلية حقيقية. تكوين RPKI يتطلب من مهندسي الشبكات الحفاظ على قاعدة بيانات ROA دقيقة ومحدثة — انضباط غالبًا ما تفتقر إليه الفرق الحالية. ROAs المنتهية الصلاحية أو غير الصحيحة تشكل خطرًا على الموثوقية: إذا انتهت صلاحية ROA لشبكة شرعية ولم تقم بتحديثها، فإن الموجهات التي تفرض RPKI سترفض مساراتها كغير صالحة، مما يسبب انقطاعًا. 'تعفن ROA' هذا تسبب في اضطرابات حقيقية ويجعل المشغلين الحذرين يترددون في تفعيل التطبيق الصارم.

تضيف التسلسل الهرمي لسلطات التصديق أيضًا تعقيدًا. يتم تفويض مساحة عنوان IP عبر خمسة سجلات إنترنت إقليمية (ARIN، RIPE NCC، APNIC، LACNIC، AFRINIC)، كل منها يدير مرساة ثقة خاصة به لـ RPKI. يجب على المشغلين التفاعل مع سجلهم الإقليمي لإنشاء ROAs، وهي عملية تتراوح من بوابات الخدمة الذاتية المباشرة (واجهة RIPE NCC تعتبر الأفضل) إلى سير عمل تذاكر مرهق.

هناك أيضًا مشكلة العمل الجماعي. الشبكة التي تفرض RPKI تحصل على حماية جزئية فقط — يمكن أن يصل إليها مسار غير صالح عبر جار لا يفرض التطبيق. الفوائد الأمنية الواسعة تتطلب تبنيًا واسعًا، لكن المشغلين الأفراد يتحملون التكاليف التشغيلية بينما تعود الفوائد الإيجابية على الجميع. لهذا السبب تعتبر التفويضات والضغوط التنظيمية مهمة: توجيه NIS2 الخاص بالاتحاد الأوروبي، الذي دخل حيز التنفيذ في أكتوبر 2024، يحدد صراحة إجراءات أمن BGP بما في ذلك RPKI كضوابط تقنية متوقعة لمشغلي الشبكات الأساسيين.

ما بعد RPKI: التحقق من المسار و BGPsec

RPKI مع ROV يتحقق من أن AS المصدر للمسار شرعي. لا يتحقق من المسار — تسلسل AS الذي عبره إعلان المسار للوصول إلى الموجه الخاص بك. المهاجم الذي لديه حقوق توجيه شرعية لبعض البادئات لا يزال بإمكانه تنفيذ هجمات 'تسرب المسار' عن طريق إعلان مسارات بمسارات AS معدلة.

BGPsec (RFC 8205)، وهو امتداد يضيف توقيعات تشفيرية لكل قفزة في مسار AS، هو الحل النظري. عمليًا، BGPsec لديه نشر قريب من الصفر لأنه يتطلب من جميع الشبكات في المسار دعمه قبل أن تتحقق أي فوائد أمنية على مستوى المسار. النشر الجزئي لا يوفر أي حماية ويسبب عبء تشغيلي كبير. تعمل مجموعة عمل SIDROPS في IETF بنشاط على تطوير بدائل أخف، بما في ذلك ASPA، التي تتحقق من علاقات المزود-العميل دون توقيعات لكل قفزة.

ASPA يكتسب زخمًا أسرع من BGPsec. اعتبارًا من 2025، قام RIPE NCC بدمج إنشاء كائنات ASPA في بوابته، وبدأت عدة مزودي إنترنت أوروبيين كبار في نشره. يمكن لـ ASPA اكتشاف فئة من تسريبات المسار التي لا يستطيع RPKI ROV الخالص اكتشافها، وتحديدًا السيناريوهات التي يعيد فيها العميل إعلان مسارات تلقاها من مزود إلى مزود آخر — وهو ناقل شائع في الانقطاعات الكبرى مثل انقطاع Cloudflare 2019 الذي تسبب فيه مزود إنترنت صغير في بنسلفانيا.

إجراءات عملية لمشغلي الشبكات

إذا كنت تدير أي بنية تحتية للشبكة:

أنشئ ROAs الآن عبر بوابة سجلك الإقليمي (ARIN، RIPE NCC، APNIC، LACNIC، أو AFRINIC). بوابة RPKI من RIPE NCC هي الأكثر بديهية؛ ARIN تقدم خيارات RPKI مستضافة ومفوّضة. هذا منخفض المخاطر ويحمي الشبكات الأخرى فورًا من عمليات الاختطاف العرضية الناشئة من بادئاتك.
فعّل تطبيق ROV على موجهاتك الحدودية. معظم الموجهات الحديثة (Juniper، Cisco، Nokia، Arista) تدعم التحقق من RPKI بشكل أصلي. اختبر في وضع التسجيل أولاً لتحديد الإيجابيات الخاطئة قبل التبديل إلى التطبيق. أدوات مثل Routinator و OctoRPKI من Cloudflare و Routinator من NLnet Labs يمكن أن تكون بمثابة مدقق RPKI محلي لك.
انضم إلى MANRS (manrs.org). يوفر برنامج المعايير المتفق عليها لأمن التوجيه إرشادات للتنفيذ ومساءلة عامة. اعتبارًا من مايو 2026، MANRS لديه أكثر من 900 شبكة مشاركة ويتم الإشارة إليه بشكل متزايد في قرارات الشراء والنظير.
راجع تواريخ انتهاء ROA الخاصة بك. تعفن ROA هو خطر تشغيلي حقيقي. أتمتة مراقبة انتهاء الصلاحية — معظم بوابات السجلات الإقليمية تدعم التنبيهات البريدية، لكن أدوات الطرف الثالث مثل لوحة تحكم RPKI من RIPE NCC أو Cloudflare Radar توفر تحققًا مستقلاً.
تابع تطور ASPA. إذا كانت مؤسستك لديها علاقات نظير معقدة، فإن كائنات ASPA ستكون في النهاية جديرة بالنشر إلى جانب ROAs لـ RPKI. تابع مدونة RIPE NCC وقائمة بريدية IETF SIDROPS لإشارات الجاهزية.

البنية التحتية للتوجيه على الإنترنت لن تصلح نفسها عبر التبني العضوي وحده. تفويضات NIS2 من الاتحاد الأوروبي والضغط المستمر من CISA على مشغلي البنية التحتية الحيوية في الولايات المتحدة يحركان المؤشر ببطء. لمهندسي الشبكات وفرق الأمن، النافذة الحالية هي فرصة للتقدم على متطلبات الامتثال بينما نضجت الأدوات التشغيلية إلى درجة أصبح فيها النشر قابلًا للإدارة حقًا.