سید مجید هاشمی
سید مجید هاشمی
خواندن ۸ دقیقه·۵ سال پیش

امنیت در پروتکل BGP : (BGPsec با RPKI چه تفاوتی دارد)

همانگونه که میدانید BGP (Border Gateway Protocol) پروتکلی است که در سراسر اینترنت برای تبادل اطلاعات مسیریابی بین شبکه ها استفاده می شود . در واقع این پروتکل زبان مشترک روتر ها در دنیای اینترنت برای تعیین چگونگی ارسال packet از یک روتر به روتر دیگر برای رسیدن به مقصد نهایی است . می توان گفت در حال حاضر BGP ستون فقرات شبکه اینترنت در دنیاست . برای آشنایی بیشتر با ساختار این پروتکل می توانید RFC 4271 را مطالعه نمایید .

چالش اصلی که BGP با آن مواجه است ، نبود ساز و کار امنیتی مشخص و اعتماد به متولیان شبکه مبنی بر عدم ارسال اطلاعات نادرست و تضمین صحت عملکرد سیستم شان است . از این رو خرابکاران با ارسال داده های غیرواقعی (جداول مسیریابی تقلبی) می توانند موجب بروز اشتباهاتی در مکانیزم مسیریابی در سطح این پروتکل شوند .

در این نوشته به بررسی راهکار های امن سازی پروتکل BGP که منجر به ارتقا امنیت این پروتکل و افزایش تاب آوری در کلیه سطوح زیرساخت های مسیریابی اینترنت می شود ، خواهیم پرداخت. برای درک بهتر این مبحث می توانید RFC 7454 سازمان Internet Engineering Task Force یا همان IETF با عنوان “BGP Operations and Security“ مطالعه نمایید .

همانگونه که گفته شد بزرگترین چالش پروتکل BGP نداشتن مکانیزم امنیتی به صورت پیش فرض است که به همین دلیل هر شبکه (ASN) می تواند هر رنج IP ی را Advertise نماید . در این صورت دغدغه هایی پیش رو خواهد بود :

  • خطاهای نوشتاری (Typing Errors) که با عنوان "Fat Fingers" نیز شناخته می شوند و به دلیل نزدیک بودن دکمه های کی بورد بروز این دست اشتباهات رایج است . کافیست در تایپ یک آدرس IP به جای عدد 2 عدد 3 را تایپ کنید .
  • نقض قوانین مسیریابی (Routing Policy violations) که اغلب با اعمال تنظیمات و فیلتر نادرست به اشتباه (غیر عمد) ، بروز می دهد . به عنوان مثال یک ASN رنج IP که متعلق به شبکه دیگری است را اشتباهاً Advertise می نماید .
  • حملات مخرب (Malicious attacks) که از سوی خرابکاران با هدف هدایت ترافیک رنج IP خاص به مقصد مورد نظر صورت می پذیرد . به این نوع حملات Route Hijacking نیز گفته می شود . اخیراً نوع جدیدی از این حملات به صورت ترکیبی از حملات BGP Hijacking و Man in The Middle انجام میگیرد . بدین صورت که ترافیک به مقصد خاص ارسال و پس از دستکاری و اعمال تغییرات از مقصد خاص به مقصد اصلی ارسال خواهد شد . در نتیجه در صورتیکه ترافیک به صورت غیر رمز ارسال گردد براحتی توسط فرد خرابکار قابل مشاهده و تغییر خواهد بود . در ادامه به چند نمونه از این حملات و رخداد ها در دنیای واقعی اشاره خواهیم کرد .

هایجک شدن ترافیک YouTube توسط پاکستان : روز یکشنبه ، 24 فوریه 2008 ، مخابرات پاکستان (AS17557) زمانیکه تصمیم گرفت سایت YouTube را برای کاربران این کشور فیلتر کند ، به اشتباه شروع به Advertise رنج 208.65.153.0/24 کرد . از سوی دیگر PCCW Global (AS3491) تامین کننده بالادست پاکستان تلکام نیز این رنج را به سمت BGP Peer's های خود ارسال نمود که منجر به hijacking ترافیک YouTube در مقیاس جهانی شد .

هایجک شدن ترافیک انگلستان توسط اکراین : روز شنبه ، 12 مارس 2015 ، شرکت Vega یکی از ارائه دهندگان خدمات اینترنت در اوکراین شروع به Advertise چهارده رنج آی پی British Telecom نمود که منجر به تغییر مسیر ترافیک اینترنت شمار زیادی از کاربران انگلستان به سمت اوکراین شد .

هایجک شدن ترافیک بین الملل توسط شرکت مخابرات ایران : روز دوشنبه ، 8 مرداد 1397 ، شرکت مخابرات ایران (AS58224) در پروسه "عملیات تغییر توپولوژی و تجمیع شبکه استانی" به علت غیرفعال نمودن یکی از Prefix Filtering های فی مابین BGP Peer این شرکت با اپراتور های بین الملل باعث اختلال در سیستم روتینگ بین الملل شده و باعث گردید بلافاصله تمامی مسیریابهای بین الملل جداول مسیریابی خود را بروزرسانی کنند و ترافیکهای غیر مرتبط به شبکه شرکت مخابرات ایران و به روتر استان خراسان شمالی مسیریابی شود.

سازمان  IETF اقدامات قابل توجهی همچون تشکیل کار گروه های RPSL و SIDR به منظور امن سازی route ها انجام داده‌ است . کارگروه SIDR راهکارهایی به منظور تامین و ارتقا امنیت BGP ارائه و توسعه می دهد . از این رو هدف اصلی SIDR کاهش ایرادات امنیتی در Inter-domain Routing system ها می باشد . دغدغه های اصلی که بیشترین تمرکز این گروه بر روی آن ها معطوف است را می توان بدین صورت عنوان نمود :

  • آیا یک AS اجازه ایجاد یک روت برای IP Prefix مورد نظر خود را دارد؟
  • آیا AS-Path ارائه‌شده در route همان مسیری میباشد که NLRI از آن استفاده کرده است؟

برای حل مورد اول می توان از متد RPKI و برای حل مورد دوم بر روی راهکار BGPSec که AS Path Validation را انجام می دهد تمرکز شده‌ است. در ادامه به بررسی متد BGPsec و تفاوت های آن با رویکرد RPKI خواهیم پرداخت . برای درک بهتر ابتدا به تشریح راهکار RPKI می پردازیم .

طرح مساله :

از آنجاییکه همه داده های IRR (Internet Routing Registry) به دلایلی همچون : عدم دقت در درج اطلاعات ، وجود داده های ناقص و عدم نگهداری مداوم قابل اعتماد نیستند و از سوی دیگر هر RIR (Regional Internet registry) مانند APNIC، ARIN، AFRINIC، LACNIC و RIPE NCC دارای IRR مجزا نیست که به ناچار می بایست از بانک های اطلاعاتی ثانویه همانند RADB ها و دیتا اپراتور ها استفاده نمود و از طرفی صحت اینکه IP/ASN ها متعلق به چه کسی است و توسط چه کسانی نگهداری می شود ، منجر به ایجاد Resource Public Key Infrastructure یا به اختصار RPKI گردید .

Resource Public Key Infrastructure (RPKI)

متد RPKI از سال 2008 و پس از شدت گرفتن حوادث BGP Hijacking توسط همه RIR ها مورد استفاده قرار گرفت و استاندارد سازی آن را IETF عهده دار شد . در این راهکار امنیتی آدرس های IP و ASN ها را به Public Key ها متصل نمود . پارامتر crypto-security را به IP ها و ASN های افزود که در نتیجه داده هایی که از جداول مسیریابی به پروایدر ها می رسید قابل اطمینان بود .

متد RPKI را می توان یک framework امنیتی به منظور تصدیق و تایید ارتباط دارندگان منابع (resource holders) و منابع اینترنتی شان (Internet resources) تعریف کرد (RFC6480) . با مطالعه استاندارد RFC6480 در خواهیم یافت ، متد RPKI سازو کاری برای بهبود Routing Security می باشد که از تجمیعIP Address Range ها و ASN ها از طریق Cryptographic Signature ها انجام می گردد. RKPI همچنین از گواهینامه X.509 استفاده می کند.

هنگامیکه که LIR ها از RIR ها درخواست منابع می کنند این گواهی (Certificate) ها توسط RIR ها برای نگهدارندگان منابع (Resource Holder) صادر می شود . متد RPKI به اپراتور های شبکه این امکان را می دهد که یک اطلاعیه Encrypt و validate شده به منظور route announcement هایی که آنها توسط ASN و IP Prefix های خود مجاز به انتشار هستند ، ایجاد کنند. به این اطلاعیه ها Route Origin Authorizations یا به اختصار ROA گفته می شود . برای بررسی و اعتبار سنجی رنج هایی که یک AS مجاز به Advertise آنها می باشد می توانید از ابزار RIPE NCC RPKI Validator استفاده نمایید و یا با مراجعه به سایت lg.he.net شبکه AS مورد نظر را جستجو نمایید . تصویر زیر نمونه ای از رنج های مجاز به انتشار پژوهشگاه دانش‌هاي بنيادي (IPM) را مشاهده می نمایید .

علامت کلید سبز نشانه ROA امضاء شده و معتبر است
علامت کلید سبز نشانه ROA امضاء شده و معتبر است

مطابق آنچه گفته شد RPKI تنها یکی از مراحل رسیدن به اعتبارسنجی در BGP است که در آن تنها اعتبار نگهدارنده منابع و مجوز انتشار رنج IP بررسی و تایید می شود ولیکن مسیر route ها فاقد اعتبار خواهند بود . برای اعتبار بخشی به AS-Path از متد های دیگری همچون BGPSec , ASPA , AS-Cones استفاده می شود که در حال حاضر تنها BGPsec به مرحله استاندارد سازی و پیاده سازی رسیده است و موارد دیگر به صورت پیش نویس در IETF در حال بررسی می باشند .

BGPSec

همانگونه که گفته شد RPKI در برابر حملات تغییرات مسیر روت محافظتی نمی کند . برای این منظور به روشی برای تایید AS-Path نیازمندیم همچنین میبایست اطمینان حاصل شود کسی اطلاعات مربوط به مسیر منتهی به روتر های ما را دستکاری نمی کند .

با استفاده از BGPsec ، پارامتر AS-Path با استفاده از گواهی (Certificate) از RPKI اپراتور به صورت رمزنگاری شده امضا می شود . به منظور اعتبار سنجی AS-Path ، روتر ها زنجیره های (Chains) مورد اطمینان از کلیه signature ها از AS-Path را تایید می کنند. به تصویر زیر دقت کنید :

زنجیره کلید و امضاء در BGPsec
زنجیره کلید و امضاء در BGPsec

متد BGPSec سعی‌ بر آن دارد که اطمینان دهد BGP Update دریافت شده توسط BGP Peer بدرستی مسیری را ارائه‌ می دهد که اصل پیغام Update از فرستنده تا گیرنده طی کرده است. همانگونه که اشاره شد  IETF این استاندارد را تحت RFC8205 ارائه و در حال تکمیل آن است . پس از آن نیز استاندارد های تکمیلی در این حوزه ارائه گردید که در زیر به برخی از آنها اشاره شده است:

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

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

هدف اصلی از ایجاد BGPSec ،فراهم کردن مکملی برای BGP Origin Validation است ، تا در زمانی که عمل Origin Validation(تصدیق مبدا) انجام می شود ، بتوان بصورت همزمان از عمل Route Hijacking هم جلوگیری به عمل آورد .

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



منابع :

https://www.ripe.net/support/training/material/bgp-operations-and-security-training-course/BGP-Slides-Single.pdf

https://dyn.com/blog/uk-traffic-diverted-ukraine/

https://www.ripe.net/publications/news/industry-developments/youtube-hijacking-a-ripe-ncc-ris-case-study

https://dyn.com/blog/pakistan-hijacks-youtube-1/

https://www.cra.ir/Portal/View/Page.aspx?PageId=8df53126-079b-4bca-b313-bbd3f9e2d732&ObjectId=9de7c856-d4d2-4166-85b2-eec54f12b397&WebpartId=3c86ca2e-19a0-4742-ad64-9f751b225d82



شاید از این پست‌ها خوشتان بیاید