امنیت BGP: نگاهی بر BGPSec

با سلام و عرض خسته‌نباشید خدمت تمامی دوستان عزیز؛ با بالا رفتن داستان‌های مربوط به BGP و اخبار مربوط به Hijackingهایی که در شبکه‌های‌اجتماعی و... میشنویم، گفتم خوب‌میشه که مقاله‌ای بنویسیم که توش بتونیم بحث‌های مربوط به امنیت در BGP رو بررسی کنیم و شرح بدیم. پس با من همراه باشید تا این مبحث رو باهم باز کنیم و بروی BGPSec هم نگاهی بیندازیم ;)

افزونه: چند روز پیش در ویرگول، درمورد BGP Hijacking مربوط به تلگرام مطلبی نوشتم که مطالعه‌اش بنظرم بد نیست و میتونه مفید باشه.

مشکلات امنیتی موجود در BGP

پروتکل مسیریابی BGP، درزمان طراحی بصورت یک پروتکل امن نوشته‌نشده است و دارای اشکالات امنیتی بسیاری است هنوز که هنوزه، تمامی آنها حل نشده‌اند و بسیاری از کارشناسان و فعالان حوزه شبکه و امنیت‌شبکه معقداند که پروتکل BGP، هنوز یک پروتکل کاملا امن نمیباشد. یکی از انواع حملاتی که در BGP میتواند انجام شود، Route Hijacking میباشد و زمانی پیش‌می‌آید که یک AS مسیری نامعتبر و جعلی در شبکه Advertise میکند.(مثل داستان مربوط به تلگرام). اخیرا نوع جدیدی از این حملات انجام میشوند که ترکیبی از حملات BGP Hijacking و Man-in-the-middle میباشند؛ در این نوع حمله، ترافیک به یک نقطه‌خاص ارسال میشود و سپس از آن نقطه‌خاص به مقصد اصلی ارسال خواهد شد؛در نتیجه در اینجور مواقع اگر ترافیک رمزنگاری نشده‌باشد براحتی برای دریافت‌کننده‌ی‌میانی قابل مشاهده و بررسی است.

امنیت BGP

حالا در مقابل، برای جلوگیری از این حملات چه کاری میتوان انجام داد؟ سازمان Internet Engineering Task Force یا همان IETF اقدامات قابل توجهی برای امن کردن Routeها انجام داده‌است، نظیر ایجاد RPSL و SIDR. گروه Secure Inter-Domain Routing Working Group یا همان SIDR راهکارهایی را توسعه‌میدهند که برای امنیت BGP کاربرد خواهند داشت و برای احرازهویت Routeها در زمان Exchanging بکاربرده میشوهد.

بعد از حادثه هایجک شدن YouTube توسط پاکستان در سال 2008، مسئله امنیت BGP بسیار مهمتر و قابل‌توجه‌تر شد. هدف اصلی SIDR کاهش اشکالات‌امنیتی در Inter-domain Routing system ها میباشد و دو آسیب‌پذیری‌ای که بیشترین تمرکز بروی آنها میباشد موارد زیر است:

  • آیا یک AS اجازه ایجاد یک IP Prefix را دارد؟
  • آیا AS-Path ارائه‌شده در Route همان مسیری میباشد که NLRI از آن استفاده کرده است؟(Network Layer Reachability Information)

برای حل مورد دوم بروی راهکاری تمرکز شده‌است که کار AS Path Validation را انجام میدهد، به این راهکار BGPSec میگویند. BGPSec سعی‌میکند که اطمینان‌خاطر دهد که BGP Update دریافت شده توسط BGP Peer بدرستی مسیری را ارائه‌میکند که خود پیغام Update از فرستنده تا گیرنده طی کرده است. تا الان 40عدد RFC توسط SIDR بصورت رسمی ارائه‌شده است و درحال‌حاضر 2 عدد هم پیشنویس درحال بررسی دارند؛ میتوان گفت که RFCهایی که در سال 2017 برای BGPSec از حالت پیشنویس خارج‌ و بصورت رسمی ارائه‌شدند، قدمی بزرگ برای امنیت روتینگ برداشتند:

  • ـ RFC 8205 - مشخصات BGPSec Protocol
  • ـ RFC 8206 - ملاحظات BGPSec برای انتقال AS
  • ـ RFC 8207 - ملاحظات عملیاتی BGPSec
  • ـ RFC 8208 - الگوریتم‌ها، کلیدها و امضاهای BGPSec
  • ـ RFC 8209 - گواهی‌نامه‌های BGPSec
  • ـ RFC 8210 - معرفی RPKI
  • ـ RFC 8211 - اقدامات مربوط به RPKI

داکیومنت RFC 8205 توضیحات و مشخصاتی از BGPSec میباشد که بصورت استاندارد انتشار یافته‌است؛ در RFC به این صورت توضیح داده‌شده است که BGPSec یک افزونه برای روتینگ پروتکل BGP میباشد که میتواند توسط BGP Update Messageها امنیت را برای مسیر(Path)ها فراهم کند. BGPSec میتواند توسط یک Path Attributeـه اختیاری در BGP به‌نام BGPsec_Path، پیاده‌سازی شود. این مشخصه حاوی یک Digital Signature میباشد که میتواند توسط هر ASـی که Update message را انتشار میدهد، ایجاد شود. Digital Signature به‌ما این قابلیت را میدهد که فقط ASهای موجود در "لیست ASهای Update message" اجازه Advertise کردن Route را داشته‌باشد.

در اصل، مقصود اصلی از ایجاد BGPSec ،فراهم کردن مکملی برای BGP Origin Validation میباشد(RFCهای 6483 , 6811) تا در زمانی که عمل Origin Validation(تصدیق مبدا) انجام میشود، بتوان بصورت همزمان از عمل Route Hijacking هم جلوگیری به عمل آورد؛ این کار توسط گواهی‌نامه‌های Resource Public Key Infrastructure(به اختصار RPKI) انجام میشود که تخصیص AS Numberها و IP Address هارا تصدیق و تایید میکند.(RFC 6480).

همانطور که در RFC 6480 شرح داده‌شده‌است، سیستم RPKI راهی برای بهبود Routing Security میباشد که توسط همکاری IP Address Rangeها و ASNها از طریق Cryptographic Signatureها انجام داده‌میشود؛ RKPI از X.509 Certificateها استفاده میکند(که همراه افزونه‌هایی از IPv4 و IPv6 پریفیکس‌ها و ASNها میباشد).(RFC 3779).

در زمان درخواست منابع، RIRها(APNIC، ARIN، AFRINIC، LACNIC و RIPE NCC) این Certificateهارا برای Resource Holderها صادر میکنند؛ عموما Certificateها هر سال Renew میشوند و هر RIR از Certificate شخصی و مربوط به سازمان خودش برای امضا Certificateهای صادر شده‌اش استفاده میکند. RKPI به Network Operatorها اجازه میدهد که یک اطلاعیه رمزنگاری‌شده و قابل اعتبارسنجی درمورد "route announcementهایی که آنها توسط ASN و IP Prefixهای خودشان مجاز به انتشار میباشند" ایجاد کنند.

به این اطلاعیه‌ها Route Origin Authorisations (به اختصار ROA) گفته میشود، که همچنین میتواند برای مشخص کردن Maximum طول یک Prefix که یک AS مجاز به Advertise کردنش میباشد، استفاده شود. (مقاله مدیریت ROAها در RIPE) در تصویر زیر، توسط ابزار RIPE NCC RPKI Validator Tool، آمده‌ایم Prefixهایی که AS25 و AS42 مجاز به تبلیغ میباشند را استخراج کردیم.

مقاله: نحوه Math کردن RKPI در سیسکو

درصورت استفاده از BGPSec، مکانیزم عادی‌ما، حالا نیاز به استفاده از یک BGP attribute دیگر دارد و Negotiation با دیگر eBGP Peerها درمورد BGP capability؛ پس در نتیجه کم‌کم به Peerهای ما پیشنهاد داده میشود که با یکدیگر به توافق برسند و از این به بعد، با استفاده از BGPSec بایکدیگر صحبت کنند. در دنیای اینترنت آینده، Interconnected ASهایی که از BGPSec استفاده میکنند، قادر به تضمین این مورد میباشند که تمامی Routeهای Advertiseشده بدرستی و بدون اشکال توزیع شده‌اند؛ اگرچه زیبایی و قشنگی BGP امن‌شده، زمانی دیده میشود که non-BGPSec speakers کمتری در Routing Pathها وجود داشته باشد.

امیدوارم که تا به اینجا این مقاله برای شما مفید بوده باشه و مورد توجه شما واقع بشه؛ انشاالله اگر استقبال خوبی از کاربران دریافت کنم، سعی میکنم که مقاله‌های بیشتر و بهتری درمورد این موضوع براتون آماده کنم.

این مقاله از IETF Journal بسیار عالی هستش در این زمینه و بهتون پیشنهاد میکنم که حتما مطالعه کنید.

موفق باشید.