ربودن مسیرهای BGP همچنان یک نقص ساختاری در مسیریابی اینترنت است؛ راه حل آن پذیرش RPKI است
پروتکلی که اینترنت را اداره میکند، احراز هویت داخلی ندارد
هر بار که یک وبسایت را بارگذاری میکنید، ترافیک شما از دهها سیستم خودمختار (AS) عبور میکند — شبکههایی که مستقل توسط ISPها، ارائهدهندگان ابر و شرکتها مدیریت میشوند. این شبکهها اطلاعات مسیریابی را با استفاده از پروتکل Border Gateway (BGP) مبادله میکنند، سیستمی که در سال ۱۹۸۹ توسط مهندسانی که ایدههایشان را روی دستمال کاغذی در جلسه IETF مینوشتند طراحی شد. این پروتکل بر اساس اعتماد کار میکند: وقتی یک شبکه اعلام میکند که صاحب یک بلوک آدرس IP است، همه شبکههای دیگر آن را باور میکنند. هیچ اثبات رمزنگاریای لازم نیست.
این نقص ساختاری دههها حادثه ایجاد کرده است. در آوریل ۲۰۱۰، China Telecom به مدت ۱۸ دقیقه مسیرهای ۱۵ درصد از ترافیک جهانی اینترنت را ربود و آن را از طریق شبکههای چینی هدایت کرد. در سال ۲۰۱۸، مهاجمان با ربودن مسیرهای BGP برای رزولورهای DNS سرویس Route 53 آمازون، ۱۵۲٬۰۰۰ دلار ارز دیجیتال Ethereum را دزدیدند. در سال ۲۰۲۲، یک پیکربندی اشتباه در Vodafone آلمان باعث نشت BGP شد که اتصال میلیونها کاربر در سراسر اروپا را مختل کرد. این موارد حاشیهای نیستند — محققان CAIDA تنها در سال ۲۰۲۳ بیش از ۱٬۷۰۰ رویداد تأییدشده ربودن BGP را ثبت کردهاند.
RPKI: راه حل رمزنگاری که از سال ۲۰۱۲ در دسترس بوده است
زیرساخت کلید عمومی منابع (RPKI) یک چارچوب است که توسط IETF در RFC 6480 (۲۰۱۲) استاندارد شده و مالکیت آدرس IP را به گواهیهای رمزنگاری پیوند میدهد. اپراتورهای شبکه مجوزهای مبدأ مسیر (ROA) ایجاد میکنند — تأییدیههای امضا شده که میگویند "سیستم خودمختار X مبدأ قانونی برای پیشوند Y است." روترهایی که برای اعتبارسنجی این امضاها پیکربندی شدهاند میتوانند اعلانهای مسیر نامعتبر را قبل از انتشار شناسایی و رد کنند.
RPKI ترافیک را رمزنگاری نمیکند. جداول مسیریابی را پنهان نمیکند. این راه حل به طور خاص مشکل اعتبارسنجی مبدأ را حل میکند: تأیید اینکه شبکهای که ادعای مبدأ یک مسیر را دارد واقعاً حق انجام این کار را دارد. این کار بیشتر ربودنهای BGP در دنیای واقعی را که یا پیکربندی اشتباه تصادفی است یا ربودن عمدی پیشوند توسط عوامل مخربی که خود را به جای شبکههای قانونی جا میزنند، پوشش میدهد.
محاسبات تأثیر RPKI قوی است. یک مطالعه در سال ۲۰۲۳ توسط NIST و دانشگاه مریلند نشان داد که شبکههایی که اعتبارسنجی مبدأ مسیر RPKI (ROV) را اعمال میکنند، ۹۵ درصد از تلاشهای ربودن آزمایش شده را رد کردند. بدون ROV، همان شبکهها ۹۴ درصد از اعلانهای مخرب را پذیرفتند.
آمار پذیرش: اینترنت واقعاً در سال ۲۰۲۶ کجاست؟
پذیرش RPKI از سال ۲۰۲۰ شتاب گرفته است، اما اینترنت هنوز از محافظت فاصله زیادی دارد. تا می ۲۰۲۶، داشبورد امنیت مسیریابی RIPE NCC نشان میدهد که تقریباً ۴۷ درصد از پیشوندهای IPv4 مسیریابی شده جهانی تحت پوشش ROAهای معتبر هستند. برای IPv6، پوشش حدود ۵۲ درصد است. اما ایجاد ROA تنها نیمی از معادله است — شبکهها همچنین باید اعتبارسنجی مبدأ مسیر را اعمال کنند و مسیرهایی را که بررسی RPKI را رد میکنند رد کنند.
پذیرش اعمال ROV عقبتر است. اندازهگیریهای رصدخانه MANRS (هنجارهای توافق شده متقابل برای امنیت مسیریابی) انجمن اینترنت نشان میدهد که تقریباً ۳۵ درصد از سیستمهای خودمختار تا اوایل ۲۰۲۶ به طور فعال اعتبارسنجی RPKI را اعمال میکنند. شکاف بین «ایجاد ROA» و «اعمال واقعی آن» جایی است که ربودنها همچنان موفق میشوند.
ارائهدهندگان بزرگ ابری پیشرو در پذیرش هستند. Amazon Web Services، Google Cloud، Microsoft Azure و Cloudflare همگی ROV RPKI را در شبکههای خود اعمال میکنند. Cloudflare به طور خاص آمار اعمال خود را به صورت عمومی منتشر کرده است که نشان میدهد ماهانه میلیونها اعلان مسیر نامعتبر را رد میکند. عقبماندهها عمدتاً ISPهای منطقهای در جنوب شرقی آسیا، آمریکای لاتین و بخشهایی از آفریقا هستند، جایی که سرمایهگذاری در امنیت مسیریابی از نظر تاریخی کمتر بوده است.
چرا پذیرش کامل متوقف میشود: واقعیت اپراتور
مورد فنی برای RPKI unambiguous است. موانع عملیاتی واقعی هستند. پیکربندی RPKI نیاز دارد که مهندسان شبکه یک پایگاه داده دقیق و بهروز از ROAها را نگهداری کنند — انضباطی که تیمهای موجود اغلب فاقد آن هستند. ROAهای قدیمی یا نادرست خود یک خطر قابلیت اطمینان هستند: اگر ROA یک شبکه قانونی منقضی شود و آن را بهروز نکند، روترهای اعمالکننده RPKI مسیرهای آن را به عنوان نامعتبر رد میکنند و باعث قطعی میشوند. این «پوسیدگی ROA» باعث اختلالات واقعی شده و اپراتورهای محتاط را مردد میکند که اعمال سختگیرانه را فعال کنند.
سلسله مراتب مرجع صدور گواهی نیز پیچیدگی را اضافه میکند. فضای آدرس IP از طریق پنج ثبت منطقه ای اینترنت (ARIN، RIPE NCC، APNIC، LACNIC، AFRINIC) توزیع میشود، که هر کدام Trust Anchor خود را برای RPKI اداره میکنند. اپراتورها باید برای ایجاد ROA با RIR خود تعامل کنند، فرآیندی که از پورتالهای سلف سرویس ساده (رابط RIPE NCC بهترین در کلاس محسوب میشود) تا گردش کارهای بلیتمحور دست و پاگیر متغیر است.
همچنین یک مشکل اقدام جمعی وجود دارد. شبکهای که RPKI را اعمال میکند تنها محافظت نسبی به دست میآورد — یک مسیر نامعتبر همچنان میتواند از طریق یک همسایه غیراعمالکننده به آن برسد. مزایای امنیتی گسترده نیاز به پذیرش گسترده دارد، با این حال اپراتورهای فردی هزینههای عملیاتی را متحمل میشوند در حالی که اثرات مثبت به همه میرسد. به همین دلیل است که الزامات و فشارهای نظارتی مهم هستند: دستورالعمل NIS2 اتحادیه اروپا که در اکتبر ۲۰۲۴ اجرایی شد، به صراحت اقدامات امنیتی BGP از جمله RPKI را به عنوان کنترلهای فنی مورد انتظار برای اپراتورهای شبکه ضروری فهرست میکند.
فراتر از RPKI: اعتبارسنجی مسیر و BGPsec
RPKI با ROV تأیید میکند که AS مبدأ یک مسیر قانونی است. این روش مسیر را اعتبارسنجی نمیکند — دنباله ASهایی که یک اعلان مسیر برای رسیدن به روتر شما طی کرده است. یک مهاجم که حقوق مسیریابی قانونی به برخی پیشوندها دارد همچنان میتواند با تبلیغ مسیرهایی با مسیرهای AS دستکاری شده، حملات "نشت مسیر" انجام دهد.
BGPsec (RFC 8205)، یک توسعه که امضاهای رمزنگاری را به هر هاپ در مسیر AS اضافه میکند، پاسخ نظری است. در عمل، BGPsec تقریباً استقرار صفر دارد زیرا نیاز دارد که همه شبکههای یک مسیر از آن پشتیبانی کنند تا هر مزیت امنیتی در سطح مسیر به دست آید. استقرار جزئی هیچ محافظتی و سربار عملیاتی قابل توجهی ارائه نمیدهد. گروه کاری SIDROPS IETF به طور فعال در حال توسعه جایگزینهای سبکتر است، از جمله مجوز ارائهدهنده سیستم خودمختار (ASPA)، که روابط ارائهدهنده-مشتری را بدون امضای کامل هر هاپ تأیید میکند.
ASPA سریعتر از BGPsec در حال جذب است. تا سال ۲۰۲۵، RIPE NCC ایجاد شیء ASPA را در پورتال خود یکپارچه کرده است و چندین ISP بزرگ اروپایی استقرار آن را آغاز کردهاند. ASPA میتواند دستهای از نشتهای مسیر را که ROV خالص RPKI نمیتواند، به طور خاص سناریوهایی که یک مشتری مسیرهای دریافت شده از یک ارائهدهنده را به یک ارائهدهنده دیگر تبلیغ میکند — یک بردار رایج در قطعیهای بزرگ مانند قطعی ۲۰۱۹ Cloudflare که توسط یک ISP کوچک پنسیلوانیا ایجاد شد، شناسایی کند.
نکات عملی برای اپراتورهای شبکه
اگر هر زیرساخت شبکهای را اداره میکنید:
- هم اکنون ROA ایجاد کنید از طریق پورتال RIR خود (ARIN، RIPE NCC، APNIC، LACNIC یا AFRINIC). پورتال RPKI RIPE NCC بصریترین است؛ ARIN گزینههای RPKI میزبانی شده و تفویضی ارائه میدهد. این کار کمریسک است و بلافاصله دیگر شبکهها را از ربودن تصادفی از پیشوندهای شما محافظت میکند.
- اعمال ROV را فعال کنید روی روترهای مرزی خود. اکثر روترهای مدرن (Juniper، Cisco، Nokia، Arista) به طور بومی از اعتبارسنجی RPKI پشتیبانی میکنند. ابتدا در حالت ثبت نام (logging mode) تست کنید تا مثبتهای کاذب را قبل از تغییر به حالت اعمال شناسایی کنید. ابزارهایی مانند Routinator، OctoRPKI از Cloudflare و Routinator از NLnet Labs میتوانند به عنوان اعتبارسنج RPKI محلی شما عمل کنند.
- به MANRS بپیوندید (manrs.org). برنامه هنجارهای توافق شده متقابل برای امنیت مسیریابی راهنمای پیادهسازی و پاسخگویی عمومی ارائه میدهد. تا می ۲۰۲۶، MANRS بیش از ۹۰۰ شبکه شرکتکننده دارد و به طور فزایندهای در تصمیمات خرید و همسطحی (peering) ذکر میشود.
- تاریخ انقضای ROAهای خود را ممیزی کنید. پوسیدگی ROA یک خطر عملیاتی واقعی است. نظارت بر انقضا را خودکار کنید — اکثر پورتالهای RIR از هشدارهای ایمیلی پشتیبانی میکنند، اما ابزارهای شخص ثالث مانند داشبورد RPKI RIPE NCC یا Cloudflare Radar اعتبارسنجی مستقل ارائه میدهند.
- تحولات ASPA را دنبال کنید. اگر سازمان شما روابط همسطحی پیچیده دارد، اشیای ASPA در نهایت ارزش استقرار در کنار ROAهای RPKI را خواهند داشت. وبلاگ RIPE NCC و لیست پستی گروه کاری SIDROPS IETF را برای سیگنالهای آمادگی دنبال کنید.
زیرساخت مسیریابی اینترنت قرار نیست خودش را از طریق پذیرش ارگانیک به تنهایی تعمیر کند. الزامات NIS2 اتحادیه اروپا و فشار مداوم CISA بر اپراتورهای زیرساخت حیاتی ایالات متحده به آرامی عقربه را حرکت میدهند. برای مهندسان شبکه و تیمهای امنیتی، پنجره فعلی فرصتی است تا جلوتر از الزامات انطباق حرکت کنند در حالی که ابزارهای عملیاتی به بلوغی رسیدهاند که استقرار واقعاً قابل مدیریت است.