امنیت BGP : بررسی جزئیات تغییر مسیر ترافیک مقاصد محبوب به ISP روسی

BGP hijack
منبع: bgpmon.net

در 12 دسامبر 2017، سرویس مانیتورینگ دنیای اینترنت، BGPMon، اتفاقی عجیب را گزارش کرد که بر طبق آن ترافیک شبکه هایی همانند گوگل، مایکروسافت، فیسبوک، اپل و … برای مدت زمان مشخصی از طریق یک ISP ناشناخته ی روسی مسیریابی شدند.

این اتفاق سبب شد تا بار دیگر این سوال مطرح شود که آیا ارتباطات در دنیای اینترنت امن و قابل اعتماد هستند؟ به بیان بهتر، آیا پروتکل BGP که وظیفه ی برقراری ارتباطات بین backbone ها، ISP ها و شبکه های بزرگ را در دنیا بر عهده دارد، دارای مکانیسم های امنیتی کافی هست؟

با گذشت سال ها و با وقوع اتفاقات مختلفی که از آنها با عنوان hijack یا ربوده شدن مسیرها یاد می شود، همانند اتفاق 12 دسامبر که تنها 8 ماه بعد از مسیریابی ترافیک مقاصدی همانند Master Card، Visa و … از طریق یک ISP تحت نظارت دولت روسیه، به وقوع پیوست، تقریبا این امر محرز گشته که امنیت BGP جز در حد حرف نیست.

با وجود همه ی این تفاسیر، چند نکته در رابطه با اتفاقی که در 12 دسامبر رخ داد، وجود دارند که کمی مشکوک بوده و جای تامل داشتند:

1- اول آن که بر طبق گفته ی محققان BGPMon، ترافیک های reroute شده متعلق به کمپانی های نفوذپذیر و حساسی بودند که علاوه بر گوگل، مایکروسافت، فیسبوک و اپل، می توان به Twitch، NTT Communications و Riot Games اشاره کرد. اولین نکته ی قابل توجه آن بوده که آدرس IP های hijack شده به بلاک های کوچکتر و البته خاص تر (more specific) نسبت به آن چیزی که از طریق شبکه های مبدا تبلیغ می شدند، شکسته شده بودند که این موضوع نشان دهنده ی آن است که در این تغییر مسیرها، عمدی در کار بوده.

برطبق ایمیل منتشر شده از Andree Toonk (یکی از محققان BGPMon): ” تبلیغ Prefix های 16/ از جانب گوگل کاملا طبیعی است اما در آن روز این prefix ها به صورت 24/ تبلیغ شدند. گوگل این بلاک ها را تبلیغ نکرده پس کسی باید آن ها را ساخته باشد و مساله اینجاست که اگر مشکل فقط خطا در پیکربندی BGP بود، ما نباید شاهد Prefix های جدید می بودیم. “

بگذارید واضح تر توضیح دهیم که چه اتفاقی رخ داده است: اعداد بعد از slash مشخص کننده ی سایز بخش network بلاک IP ای هستند که دریافت شده اند. هرچقد این عدد کوچکتر باشد، به این معنی است که آن بلاک آدرس، تعداد بیشتری آدرس IP قابل استفاده را شامل می شود. پس 16/ به معنی بلاکی با 64000 آدرس قابل استفاده و 24/ به معنای بلاکی با 254 آدرس قابل استفاده است. زمانی که مسیرها در جدول مسیریابی BGP قرار می گیرند، بلاک های کوچکتر و خاصتر (more specific) همانند آدرس های 24/، نسبت به سایر آدرس های مشابه ولی کم تر خاص، یعنی 16/ ها، ارجحیت پیدا کرده و شانس بیشتری برای تبلیغ به سایر ISP ها و backbone های اینترنتی دارند. بنابراین اگر کسی بلاک های آدرس تبلیغی از جانب گوگل را با Prefix کوچکتر تبلیغ نماید، در جداول BGP سایر روترهای همسایه به عنوان مسیر ارجح تر انتخاب می شود و ترافیک به این مقاصد، به جای گوگل به سمت او ارسال می شوند. مشابه آن چه در 12 دسامبر رخ داد.

2- نکته ی قابل توجه بعدی آن بود که این prefix های خاص از AS ای نشات می گرفتند (AS 39523) که سال ها بوده که به جز یک رویداد BGP که در ماه آگوست گوگل را نیز تحت تاثیر قرار داده بوده، هیچ فعالیت خاص دیگری نداشته و هیچ چیزی تبلیغ نمی کرده. اما چرا ناگهان این AS ظهور می کند و شروع به تبلیغ prefix هایی برای شبکه هایی همانند گوگل می نماید؟

این که مهندسین AS 39523 با این میزان ترافیک بالایی که در طول این تغییر مسیر، از AS خود عبور داده اند، قرار است چه کاری انجام دهند، نامشخص است. ترافیک های وب و ایمیل معمولا رمزنگاری می شوند و سال ها تلاش شده تا روش های مختلفی برای تضعیف روش های رمزنگاری و یا حتی شکستن رمزها ابداع شوند، حملاتی همانند Logjam یا DROWN. اما تا به امروز هیچ مدرکی مبنی بر این که این حملات در مورد مسیرهای ربوده شده ی BGP توانسته اند موفق عمل کنند و آنها را decrypt نمایند، منتشر نشده است.

پس حداقل کاری که پروایدر روسی AS 39523 که این مسیرهای ربوده شده از آن عبور داده شده اند، می تواند انجام داده باشد آن است که از این داده ها یه کپی تهیه و دخیره کرده و در صورتی که روزی روشی برای decrypt داده های رمزنگاری شده پیدا شد، از آنها استفاده کند.

اتفاقی که در 12 دسامبر رخ داد، آخرین نمونه از ربوده شدن مسیرهای BGP نیست و نخواهد بود. برای جلوگیری از تکرار چنین اتفاقاتی، ISP ها و backbone ها باید نسبت به مسیرهای جدیدی که به عنوان مسیرهای قابل اعتماد یا trust به آنها تبلیغ می شوند، دقیق تر باشند.

بنا به گفته ی Alexander Lyamin مدیرعامل شرکت Qrator Labs در گفتگو با Ars Technica: ” به وجود آمدن چنین مشکلاتی ناشی از عدم فیلتر مسیرهاست. در این رویداد همه می توانند AS 39523 را محکوم و سرزنش نمایند اما اگر ارائه دهندگان اینترنت بین المللی در نقاط مرزی خود فیلترینگ مناسب را پیاده سازی نکنند، ما محکوم به مشاهده ی حوادث مشابهی در آینده خواهیم بود.”

تلاش برای امن کردن BGP:

با توجه به آن چه در بالا شرح داده شد و موارد متعدد مشابه آن در سال های اخیر، ایجاد و توسعه ی روش هایی برای امن کردن BGP، بیش از پیش حائز اهمیت تلقی می شود. به تازگی مجموعه ای از استانداردها تحت عنوان Secure Inter-Domain Routing (یا SIDR) توسط نهاد IETF منتشر شده اند که نشان دهنده ی اولین تلاش ها برای دفاع از سیستم مسیریابی اینترنتی در برابر حملات می باشند.

این مکانیسم دفاعی بر پایه ی روش های رمزنگاری است تا این اطمینان حاصل شود که داده ها فقط از مسیرهایی عبور می کنند که برای آن ها مجاز تعریف می شوند. سه بخش اصلی که IETF SIDR در حال کار بر روی آنهاست عبارتند از:

1- Resource Public Key Infrastructure (RPKI)
که در واقع به دارندگان بلاک هایی از آدرس های اینترنتی همانند فراهم کنندگان خدمات ابری، این امکان را می دهد که تعیین نمایند چه شبکه هایی می توانند یک direct connection با آدرس های بلاک آنها داشته باشند. این روش در RFC 7115 معرفی و شرح داده شده است.

2- BGP Origin Validation
که به روترها این امکان را می دهد که با استفاده از اطلاعات RPKI بتوانند مسیرهای BGP تبلیغی غیرمجاز را فیلتر کرده و به این ترتیب جلوی حملاتی همانند hijack مسیرها گرفته شود.

3- BGP Path Validation
که تحت عنوان BGPsec شناخته می شود و RFC مربوط به آن اخیرا توسط IETF منتشر شده، در واقع نوآوری جدیدی است که این امکان را برای روترها فراهم می کند تا با استفاده از امضای دیجیتال مطمئن شوند که کل مسیر (از مبدا تا مقصد) در دنیای اینترنت، از شبکه های مجاز عبور کرده است. البته باید اذعان نمود که در رابطه با این روش هنوز ابهامات و مشکلاتی وجود دارد.

اگر علاقه مند به آشنایی بیشتر با این روش ها هستید می توانید از طریق صفحه ی مربوط به SIDR در وب سایت IETF، روند پیشرفت آن ها و آخرین تغییراتشان را پیگیری نمایید.

نویسنده: مینا رضائی

محقق و همیشه در حال یادگیری، عاشق نقاشی، گاهی هم نویسندگی یا تألیف کتابای بزرگ :) (مسئولیت و صحت و سقم کلیه ی مطالب منتشر شده از جانب من تنها بر عهده ی خودم می باشد)

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

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