اندر تفاوت Unicast و Anycast سوارابرها

پیرو حملات DDoS در ایران و رویداد #سوارابرها، بارها دیده‌شده افرادی که خیلی هم در حوزه‌ی خودشون متخصص هستن، در تفاوت خدمت DDoS Protection برای سرویس‌های IaaS که از منظر شبکه بصورت Unicast ارائه میشه، با نحوه‌ی DDoS Protection برای سرویس‌های CDN که معمولن از منظر شبکه بطور Anycast پیاده‌سازی میشن، براشون سوء تفاهم شده‌بود.
//این مطلب خیلی یهویی و کوتاه نوشته شده :)) و سعی کردم خیلی از جزئیات فنی که ممکنه حوصله‌سربر باشه رو ساده بیان کنم.

در پیاده‌سازی های Unicast، حملات DDoS بسیار موفق هستند چون می‌تونن تمامی منابع حمله رو، متمرکز کنن روی یک یا چند نقطه‌ [فیزیکی] (مثلن کل IPهایی که با BGP در دنیای اینترنت از یک محل اعلان میشن) و خیلی عامیانه‌ش اینکه لوله‌های اینترنت اون نقاط رو پر کنن.
حالا هرچقدر هم که تکنولوژی DDoS Protection/Mitigation و scrubbing پیشرفته باشه، اما بخاطر طبیعت سرویس IaaS، میشه گفت راهی جز افزایش دائمی پهنای باند وجود نداره و گاهی ممکنه پهنای باند زیرساخت‌های بزرگ پر بشه و مجبور به blackhole کردن بشن. اتفاقی که بارها در دنیا برای سرویس‌دهنده‌های بزرگ IaaS هم بطور روزانه رخ میده و بعنوان یکی از مخاطرات اینترنت شناخته شده. ادامه خواندن “اندر تفاوت Unicast و Anycast سوارابرها”

نگاهی بر ابزار MTR

به عنوان یک مدیر شبکه نیاز است تا برای مدیریت و خطایابی ساختار، با ابزارهای مختلفی آشنایی داشته باشید. در دنیای شبکه، ابزارهای متفاوتی برای خطایابی وجود دارند که در میان آن‌ها ping و taceroute از شهرت بیشتری برخوردارند. بااین‌حال ابزار دیگری نیز وجود دارد که شاید همانند این دو ابزار شهرت زیادی نداشته باشد اما فراهم‌کننده‌ی اطلاعاتی به‌مراتب بیشتر و مهم‌تر است. این ابزار قدرتمند، MTR نام دارد.

MTR به مدیر شبکه کمک می‌کند تا خطاها را شناسایی کرده و گزارشی از وضعیت کلی شبکه به دست آورد. در این مطلب سعی شده تا به MTR، داده‌های تولیدی توسط آن و نحوه‌ی تحلیل و تفسیر اطلاعات حاصل از این ابزار، پرداخته شود.

مروری بر عملکرد ابزارهای اصلی خطایابی شبکه

ابزارهای خطایابی شبکه چون ping، traceroute و MTR از Control Message Protocol (ICMP) برای تست ارتباطات و ترافیک تبادلی میان دو نقطه در اینترنت استفاده می‌کنند. هنگام ping یک IP، تعدادی پکت ICMP از مبدأ به سمت مقصد ارسال شده و مقصد نیز در پاسخ تعدادی پکت ICMP برای مبدأ ارسال می‌کند. برحسب پاسخ‌های تبادلی میان این دو نقطه، کاربر قادر خواهد بود تا مقدار round trip time (RTT) مابین این دو نقطه را محاسبه کند.

اما ابزارهایی همانند MTR و traceroute، با کمک فیلد TTL (Time to Live) در هدر پکت IP، تعداد گام‌ها (hop) در مسیر میان مبدأ و مقصد را محاسبه می‌کنند. TTL مشخص‌کننده‌ی تعداد گام‌هایی است که پکت قبل از منقضی شدن می‌تواند از آن‌ها عبور کند. هنگامی‌که از traceroute یا MTR استفاده می‌شود، برای شمارش تعداد hopها، ابتدا چند پیام ICMP با کمترین مقدار برای TTL (مقدار 1) ارسال شده و به‌تدریج مقدار TTL افزایش می‌یابد تا نهایتاً بسته به مقصد موردنظر رسد.

MTR را می‌توان ترکیبی از دو ابزار ping و traceroute معرفی کرد. این ابزار علاوه بر دید کلی از مسیری که ترافیک از مبدأ تا یک مقصد مشخص طی می‌کند، اطلاعات بیشتری در رابطه با وضعیت، ارتباطات و پاسخگویی hopهای قرارگرفته میان مبدأ و مقصد را نیز فراهم می‌آورد.

ادامه خواندن “نگاهی بر ابزار MTR”

وقتی سرنوشت‌ها به هم گره می‌خورند: کوتاه درباره‌ی اصطلاح Fate sharing

یه فلسفه‌ای هست تو دنیا که میگه اتفاقایی که برای ما میوفته بخشیش دست ما نیست و در گروی اثر عملی هست که سایر عناصر عالم بر زندگی ما دارن که بهش میگن تقدیر یا سرنوشت. حالا همین موضوع در دنیای شبکه هم صدق می‌کنه. اولین‌بار این اصطلاح رو در دنیای شبکه، آقای کلارک (David D. Clark) در سندی تحت عنوان “فلسفه‌ی طراحی پروتکل‌های اینترنتی DARPA” در سال 1988 معرفی کرد. به زبون ساده، fate sharing میگه:

“اگر ما مجموعه‌ای از عناصر متصل به هم رو داشته باشیم که عملکرد هر کدومشون در گرو عملکرد صحیح سایر عناصر باشه، در این صورت اگر یک عنصر بنا به هر دلیلی fail بشه، سایر عناصر هم به صورت خودکار fail خواهند شد.”

یه مثال تو دنیای واقعی برای درک بهتر این موضوع: سوار پرایدتون (مثلاً) هستین و دارین برمیگردین خونه که یهو متوجه میشین ماشین داره به سختی حرکت میکنه. سریع میزنین کنار و پیاده میشین و می‌بنین که بله یکی از چرخای عقبتون پنچر شده. موتور ماشین سالمه، سه تا چرخ دیگش سالمه امّا چون یه چرخش دچار مشکل شده عملکرد ماشینتون هم دچار مشکل شده و ماشین نمیتونه به حرکت خودش ادامه بده.

امّا ببینیم تو دنیای شبکه کجاها ممکنه fate sharing رخ بده. یکی از مصداقای اصلی بروز fate sharing در هنگام مجازی‌سازی (virtualization) هست. یعنی زمانی که ما یک یا چندتا توپولوژی مجازی رو بر روی یک بستر فیزیکی پیاده‌سازی می‌کنیم. در این صورت هر مشکلی برای اون بستر فیزیکی رخ بده، قطعاً توپولوژی‌های مجازی که بر روی اون پیاده‌سازی شدن هم دچار مشکل میشن. ادامه خواندن “وقتی سرنوشت‌ها به هم گره می‌خورند: کوتاه درباره‌ی اصطلاح Fate sharing”

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

منبع: bgpmon.net

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

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

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

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

تغییر رفتار پیش‌فرض eBGP با RFC8212

پیرو Route Leakage‌های مختلفی که در دنیای اینترنت رخ داده‌است، و همینطور نیاز مبرم Service Providerها، از اواسط سال 2015، در IETF گروه GROW بحثی شروع شد مبنی بر طراحی یک رفتار پیش‌فرض BGP در رابطه با تبادل روت‌ها با همسایگان خارجی (eBGP).
همانطور که می‌دانید در RFCهای مرتبط با BGP، علی‌الخصوص RFC4271، تابحال توضیحی در رابطه با رفتار پیش‌فرض همسایه‌های eBGP در تبادل روت‌ها زمانی که Policy خاصی اعمال نشده، ارائه نشده است، و این امر باعث شده که هر وِندوری رفتار سلیقه‌ای داشته باشد.

فارغ از جزئیات، بعنوان نمونه می‌توان به مدل‌های پیاده‌سازی زیر اشاره کرد:

  • بطور پیش‌فرض دو همسایه eBGP، زمانی که Policy خاصی روی ارتباطات eBGP تنظیم نشده باشد، روت‌های انتخاب‌شده در BGP Table خود را به یکدیگر ارسال می‌کنند و از یکدیگر قبول می‌کنند.
  • هیچ روتی ارسال نمی‌شود و هیچ روتی قبول نمی‌شود (discard) مگر اینکه Policy متناسبی تنظیم شده باشد.
  • برخی پیاده‌سازی‌ها هیچ روتی قبول نمی‌کنند و فقط روت‌های مربوط به AS خود را advertise می‌کنند.

مثلاً در حالت مثال اول، یکی از مخاطرات ممکن زمانی است که یک AS ناخواسته ترانزیت ارتباط بین ASهای دیگر می‌شود (در RFC7908 توضیح خوبی درباره‌ی Lateral ISP-ISP-ISP Leak همراه با دو بررسی دقیق در قسمت منابع، ارائه شده) ادامه خواندن “تغییر رفتار پیش‌فرض eBGP با RFC8212”