خواندنی بایگانی

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

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

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

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

با وجود همه ی این تفاسیر، چند نکته در رابطه با اتفاقی که در 12 دسامبر رخ داد، وجود دارند که کمی مشکوک بوده و جای تامل داشتند: ادامه خواندن “امنیت BGP : بررسی جزئیات تغییر مسیر ترافیک مقاصد محبوب به ISP روسی”

همخوان کنید

Dual-Stack Lite

در پست قبل معماری Large Scale NAT یا LSN، به همراه مشکلاتی که سر راه این معماری وجود داشت و همینطور راه حل هایی که برای حل این مشکلات قابل استفاده بودند، توضیح داده شد. خلاصه ای کوتاه از آن چه در پست قبل مطرح گردید به این صورت است که:

ساده ترین روش برای پیاده سازی LSN، بهره گیری از NAT444 بود که یکی از مشکلات سر راه این روش، احتمال ایجاد overlap بین آدرس های IP Private مشتریان و رنج آدرس IP های Private ای بود که ISP به لینک بین دستگاه خود و مشتری اختصاص داده بود.

مشکل بزرگ بعدی زمانی پیش می آمد که دو مشتری که هر دو با یک LSN ارتباط داشتند، قصد برقراری ارتباط با یکدیگر را داشته باشند. در این صورت چون آدرس Private به آدرس Public ای نگاشت نمی شد، احتمال drop شدن پکت ها از سوی دستگاه هایی که در لبه ی ساختار شبکه ی مشتری قرار داشتند، افزایش پیدا می کرد.

یکی از راه حل های پیشنهادی برای حل این مشکل آن بود که از یک بلوک از آدرس های IPv4 باقی مانده که با آدرس های RFC 1918 (یا همان آدرس های IPv4 Private) هم پوشانی نداشته باشند، به عنوان shared address استفاده شوند و از این طریق هم مشکل هم پوشانی آدرس ها حل شود و هم از مشکل فیلتر شدن پکت های مشتریانی که در پشت یک LSN یکسان قرار دارند، جلوگیری گردد. اما این پیشنهاد تقریباً هیچ وقت عملیاتی نشد.

راه حل بعدی، استفاده از آدرس های IPv6 بین ISP و مشتریان، به جای آدرس IPv4 بود. در واقع استفاده از NAT464. این روش علاوه بر این که مشکلات NAT444 را حل می کرد، به Provider ها نیز این امکان را می داد که سریعتر به سمت معماری IPv6-only که مد نظر داشتند، حرکت کنند. سختی این روش آن بود که هم CPE NAT ( یا همان NAT سنتی مورد استفاده سمت ساختار مشتری) و هم معماری LSN، باید قابلیت ترجمه ی هردوی آدرس های IPv4 و IPv6 به یکدیگر را می داشتند که همین موضوع باعث ایجاد پیچیدگی و بروز مشکلات جدیدی در عملکرد، مقیاس پذیری و افزونگی می شد.

روشی که برای حل این مشکلات پیشنهاد شد، Dual-Stack Lite نام داشت. در این روش به لینک بین مشتری و ISP، فقط آدرس IPv6 اختصاص داده می شود. پکت IPv4 ای که از جانب ساختار مشتری بخواهد به مقصدی خارج از این ساختار ارسال شود، در یک پکت IPv6 کپسوله شده و به سمت Provider ارسال می شود. روتری که در لبه ی ساختار Provider قرار دارد، این پکت IPv6 را باز کرده و در قبال محتویات آن ( که در واقع یک پکت IPv4 است) از NAT44 استفاده می کند.

پس به این ترتیب با پیاده سازی یک تانل IPv4 بر روی لینک IPv6 بین ساختار مشتری و ISP، این هدف محقق می شود و علاوه بر این که پیاده سازی این تانل خیلی ساده تر از ترجمه ی آدرس هاست، نگرانی های مربوط به مباحث redundancy و performance هم برطرف می شوند.

در مقاله ی زیر سعی شده تا بیشتر با Dual-Stack Lite و انواع مدل های پیاده سازی آن آشنا شویم.

Understanding Dual-Stack Lite

همخوان کنید

آشنایی با معماری Large Scale NAT (LSN)

اگر از پست قبل به خاطر داشته باشید، توضیح داده شد که چندین سال از NAT به عنوان راهکاری در ساختارهای شبکه ی مشتریان برای کاهش نیاز به آدرس های IPv4 Public استفاده می شد.

زمانی که آدرس های IPv4 Public به مرز اتمام نزدیک شدند، ISP ها به دنبال جواب این سوال بودند که چطور می توانند ارتباط خود با مشتریانشان را حفظ کنند. پاسخ این پرسش این بود که اگر NAT در لبه ی مرزی ساختار مشتریان با Provider ها توانسته بود موفق عمل کند پس قطعا می تواند در لبه ی مرزی ساختار Provider ها با مشتریانشان نیز موفق عمل نماید. در واقع این پاسخ، ایده ی اصلی شکل گیری مفهومی با نام Large Scale NAT یا LSN بود.

معماری LSN به این صورت است که، ISP ها برای لینک هایی که به سمت مشتریان خود دارند به جای تخصیص آدرس IPv4 Public از آدرس های IPv4 Private استفاده می کنند و برای لینک هایی که برای ارتباط آن ها با اینترنت است از آدرس IPv4 Public.

بنابراین اگر مشتری در روتر مرزی خود با Service Provider از NAT استفاده کرده باشد، پکتی که از سمت ساختار مشتری به سمت ISP ارسال می شود، ابتدا آدرس IPv4 Private آن به یک آدرس IPv4 Private دیگر که از سمت ISP به لینک بین آن و روتر مرزی مشتری اختصاص پیدا کرده، نگاشت می شود و در هنگام خروج پکت از ساختار Provider به سمت اینترنت، آدرس آن به یک آدرس IPv4 Public ترجمه می شود. پس بنابراین دوبار ترجمه رخ می دهد: یک آدرس IPv4 Private به یک آدرس IPv4 Private دیگر و نهایتا به یک آدرس IPv4 Public ترجمه می گردد. به همین دلیل این عمل اصطلاحا NAT444 نامیده می شود.

خوبی این روش آن است که NAT ای که سمت مشتریان پیاده سازی شده هیچ نیازی به تغییر ندارد چرا که برای NAT مهم نیست که آدرس outside ای که باید نگاشت به آن انجام شود، باید Private باشد یا Public. بنابراین از دید تجهیز سمت مشتری، هیچ تغییری رخ نداده است.

اما این معماری قطعا مشکلاتی را نیز در پی خواهد داشت: به عنوان مثال تصور کنید که مشتری در ساختار خود از همان رنج آدرس IPv4 Private ای استفاده کرده باشد که Provider آن رنج را به لینک بین خود و مشتری اختصاص داده است، در این صورت overlap رخ خواهد داد. یا مثلا تصور نمایید که یک مشتری قصد ارسال پکتی را به یک مشتری دیگر که در پشت همان LSN ای که با آن ارتباط دارد، داشته باشد. معمولا فایروال ها یا ACL هایی که در روترها تعریف می شوند، مانع از ورود پکتی با آدرس IP Private به داخل ساختار شده و این پکت ها رو drop می کنند.

در این پست سعی شده تا بیشتر با معماری LSN، مزایا و معایب آن و هم چنین راهکارهایی که برای حل مشکلات این معماری ارائه شده است، آشنا شویم.

Large Scale NAT Architectures

همخوان کنید

مفهوم Carrier Grade NAT (CGN)

اگر از پست قبل به خاطر داشته باشید، Dual Stack ساده ترین روش برای حرکت به سمت استفاده از IPv6 بود. در این روش، در صورتی که در یک ساختار IPv6، تمام دستگاه ها قابلیت پشتیبانی از هر دوی ورژن های IPv4/IPv6 را داشته باشند قادر خواهند بود تا با هر مقصدی؛ چه IPv4 و چه IPv6؛ ارتباط برقرار نمایند. این روش زمانی که اکثر کاربران هنوز در حال استفاده از IPv4 باشند، روش مناسبی است.

اما مشکل این روش آن بود که به ازای هر اینترفیسی، همزمان یک آدرس IPv4 و یک آدرس IPv6 نیاز بود و این امر در حالی است که آدرس های IPv4 به پایان رسیده اند و قرار بر پیاده سازی روشی برای توسعه ی IPv6 و نه افزایش نیاز به IPv4 ای است که دیگر وجود ندارد!

در گذشته برای کاهش نیاز به آدرس های IPv4 Public عموما از دو روش استفاده می شد:

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

راه حل بعدی استفاده از NAT44 بود که در واقع نگاشتی را بین آدرس های IPv4 Private، به یک آدرس IPv4 Public انجام می داد و به این ترتیب برای سازمان ها این امکان فراهم می شد که برای ارتباطات دستگاه های داخلی خود از آدرس های IPv4 Private استفاده کنند و اگر نیازی به ارتباط با اینترنت بود، از NAT استفاده می شد و نیاز به آدرس IPv4 Public کاهش پیدا می کرد.

اما این روش هم مشکلی مشابه روش استفاده از DHCP داشت. تعداد آدرس های IPv4 Public محدود بودند و اگر همزمان تعداد زیادی دستگاه نیاز به اتصال به اینترنت داشتند، این روش جوابگو نبود. بنابراین عملکرد NAT44 به گونه ای تغییر داده شد که از شماره پورت ها در هنگام نگاشت آدرس ها استفاده شود. همانطور که می دانید مشهورترین اصطلاح برای این روش Port Address Translation یا PAT بود که اکنون دیگر PAT یک روش جداگانه محسوب نمی شود و تبدیل به عملکرد نرمال NAT44 گشته است.

اول این مبحث مطرح شد که روش Dual Stack در واقع مشکل IPv4 را حل نمی کرد چراکه نیاز به آدرس های IPv4 Public به تعداد زیاد، داخل Service Provider ها هم چنان وجود داشت و سپس همانطور که مطرح شد عملی که NAT انجام می داد آن بود که به شما این امکان را می داد که در داخل ساختار از آدرس های IPv4 Private استفاده کنید و بعد با داشتن چند آدرس محدود Public و استفاده از NAT، بین این آدرس ها نگاشت انجام دهید. پس آیا امکان پذیر نیست که ایده ی استفاده از NAT به داخل سرویس پروایدرها منتقل شود؟

در این مقاله به مسایلی که به آن ها اشاره شد پرداخته می شود و نهایتا به معرفی راهکار Carrier Grade NAT یا CGN ختم می گردد.

Understanding Carrier Grade NAT

همخوان کنید

معمای Dual Stack

اخباری که بر پایان عمر IPv4 اشاره می کنند روز به روز در حال افزایش هستند. خبری که این روزها باعث ترس عده ی زیادی شده، یک خبر جدید نیست بلکه از سال ها قبل هشدار این رویداد داده شده بود و روش هایی برای مدیریت این شرایط معرفی گردیده بود.

در هر حال، چه در اوج هوشیاری از این رویداد و چه بی خبر از آن، تمام سازمان ها باید به فکر دوره ی گذار از IPv4 به IPv6 باشند. این گذار احتمالا سخت و دشوار خواهد بود چرا که هنوز تعداد زیادی از کاربران و دستگاه هایی که به اینترنت متصل می شوند از IPv4 استفاده می نمایند، ارتباط بسیاری از ISP ها با مشتریانشان و حتی با سایر ISP ها بر بستر IPv4 است، دسترسی به بسیاری از محتواها در دنیای اینترنت بر پایه ی IPv4 می باشد و … ادامه خواندن “معمای Dual Stack”

همخوان کنید