خلاصه ای کوتاه درباره‌ی حملات DDoS در چندین ماه اخیر

حتماً در جریان هستین که طی ماه های اخیر حملات DDoS نه تنها قوی تر و طولانی تر، بلکه هوشمندتر شدن. یکی از بدترین انواع اون تقریباً زمانی بود که زیرساخت DNS شرکت Dyn رو تحت تاثیر قرار داد.
البته عمده ی این قطعی ها صرفاً در شمال آمریکا حس میشد چون شرکت Dyn در اقصی نقاط دنیا DNS Server داره و خب جوری طراحی شده که مثلا کاربران آسیا از نزدیک ترین DNS Server جواب میگیرن (Anycast).

میدونیم که DNS مثه دفترچه تلفن اینترنت هست و با توجه به اینکه Dyn یکی از بزرگترین DNS Provider ها هست، خیلی از وبسایت های مهم دنیا هم طی این حملات از دسترس خارج شدن.
نکته ی خیلی بد درمورد این وبسایت ها این بود که فقط از یک DNS Provider استفاده می کردن که به نوعی SPoF محسوب میشه. البته عدم استفاده از چند DNS Provider هم دلایل خاص خودش رو داره که مهمترینش بنظرم سخت شدن نگهداری و مدیرت هست چون باید همیشه مطمئن باشید که هردو Provider رکوردهای یکسان دارند. و خب چه بسی با پیشرفته تر شدن حملات، همزمان چند DNS Provider تحت حمله قرار بگیرن.

نکته‌ی جالب در رابطه با این حمله استفاده از “چیزهای متصل به اینترنت” بود (Internet of Things). شخصاً همیشه از Internet of Things ترس داشتم و هیچوقت بهش مطمئن نبودم و اینبار خودش رو نشون داد. نمیدونم، اما امیدوارم یک روز این اتفاقات جنبه‌ی خطرات انسانی پیدا نکنه. فکر میکنم بهتره اگر خودمون از اینگونه اشیاء استفاده میکنم سعی کنیم از امنیتشون مطمئن بشیم و اگر در توسعه و تولید این اشیاء نقش داریم روی مباحث امنیتیشون بیشتر و دقیق تر کار کنیم.

یک موضوع مرتبط با این قضیه هم قراری هست تحت عنوان MANRS که مخفف Mutually Agreed Norms for Routing Security هست. هدف MANRS این هست که پروایدر در کنار هم روی یکسری مکانیزم های امنیتی در روتینگ تفاهم داشته باشن. پیشنهاد میکنم حتماً در اینباره مطالعه کنین.

خوش و بشی با داکر (Docker)

مبحثی که در موردش میخایم شروع به صحبت کنیم، در مورد Container ها و علی الخصوص داکر (Docker) هستش که به صورت کلی و مختصر به تعریف و توضیح کوتاهی در موردشون می پردازیم.

لازم به گفتن میدونم که بعضی از تعاریف برای سادگی به شکل دیگه ای بیان میشه و سعی میکنم زیاد ریز بینانه وارد نشم تا مبحث ویژگی فهم عمومی داشته باشه.

Container چیست؟

Docker Container - داکر

خب اول از همه بریم سراغ Container و ببینیم چی هست و کجا استفاده مون میشه.
به زبان خیلی ساده میشه گفت Container به گروهی از پروسس ها میگن که داخل یک فضای ایزوله شده‌ قرار گرفته‌اند (البته ما در docker سراغ این میریم که microprocess ها رو داشته باشیم و در هر کانینر یک پروسس اصلی رو اجرا کنیم). از نگاهی دیگه میشه گفتش که مدلی از مجازی سازی در لایه ی سیستم عامل هستش که هسته ی سیستم عامل این قابلیت رو به ما میده که تعدادی فضای ایزوله رو کاربر بتونه ایجاد کنه.

اینجا سؤال پیش میادش که فضای ایزوله ای که ازش اسم بردیم چی هستش؟ چه قابلیتی از سیستم عامل هستش که این ویژگی رو به ما داده؟

در سیستم عامل لینوکس، یکی از مزیت‌های هسته، Namespace هستش که منابع سیستمی رو برای ما به صورتی کاملاً مجزا جدا و شبیه سازی میکنن. مثلاً Process ID، دسترسی شبکه یا حتی فایل سیستم و یا ارتباطات داخلی پروسس ها.
پس اینطوری ما با استفاده از Namespace یک فضای ایزوله برای کارمون ایجاد کردیم.

خب، دوباره تعریف سادمون از Container رو اینجا باز گو میکنم: Container به گروهی از پروسس ها میگن که داخل یک فضای ایزوله شده قرار گرفته و هر Container میتونه قابلیت‌های Namespace رو که چندتاشون رو نام بردیم داشته باشه.

داکِر (Docker)

Docker Logo - داکر

وقتش رسیده که بریم سراغ Docker و ببینیم نهنگ آبی و خندون داکر کی هستش و چی هست و رسالتش چیه.

هسته‌ی داکر که میتونیم بهش Docker Engine بگیم، یک نرم‌افزار متن باز هستش که روی سیستم عامل نصب میشه و به ما اجازه ی ساخت، پیاده‌سازی و مدیریت Container ها رو میده. این برنامه توسط تیم داکر و یا dotCloud نوشته شده و در اختیار من و شما قرار گرفته. Docker به ما این قابلیت رو میده که برنامه‌های خودمون رو به صورت اتوماتیک پیاده‌سازی کنیم و در قالب microprocess هر container رو دربیاریم و استفاده کنیم.

بزرگترین مزیتی که Docker بهمون ارایه میده این هستش که به سرعت میتونین کار development خودتون رو باهاش تست کنین، جلو ببرین و به حالت production برسونینش. ازین باحال تر این هستش که دیگه مثله نیازمندی های KVM، VMware و … به سیستم عجیب و غریبی نیاز نداریم؛ در واقع بسادگی میتونین روی سیستمی که دارین (که شاید RAM و CPU بالایی نداشته باشه)، داکِر رو نصب و ازش استفاده کنین.

موارد کاربردی داکر

در مورد مزیتی که اول گفتم (تسریع در Development) بگذارین یک مثال تجربیِ کوچیک بزنم:
امروز میخاستم یک اسکریپت کامپایل Nginx با OpenSSL ورژن ۱٫۰٫۲j و یک سری enable/disable کردن‌های دیگه درست کنم. روال کار برای من اینجوری بودش:

  1. نصب پیش نیاز ها
  2. دانلود nginx و openssl
  3. کامپایل openssl
  4. کامپایل nginx

اگه تا به حال کامپایل انجام داده باشین، متوجه میشین بعضی وقتا حوصله سَربَر میشه، مخصوصاً زمانی که بخواین پکیج رو کم و زیاد کنین یا موقغی که بلا به دور با نقص پیش نیاز مواجه بشین.

۲ تا حالت رو با هم بررسی میکنیم. یکی حالت معمولی و روی یک سیستم عامل معمولی که میخایم یک template تر و تمیز بسازیم. و حالت بعدی استفاده از docker که میخایم یک کانتینر ازش بسازیم. ادامه خواندن “خوش و بشی با داکر (Docker)”

سفر به اعماق پروتکل های مسیریابی: Link State ها (۳)

سلام به همه ی همراهان عزیز. در دو قسمت قبلی سعی کردیم تا در رابطه با این که در پروتکل های link state روترها چطور همسایه هاشون رو پیدا می کنن و با اونها ارتباط همسایگی تشکیل میدن و این که چطور خودشون رو به همسایه هاشون معرفی می کنن، توضیح بدیم. در این قست قصد داریم تا با هم بررسی کنیم، بعد از این که روتری معرفی نامه ی سایر روترها در ساختار رو دریافت کرد، اون ها رو کجا ذخیره می کنه و بعد چطور با استفاده از این اطلاعات جدول روت خودش رو می سازه.

Link State Database
بعد از این که روترها معرفی نامه ی خودشون رو در قالب Link State Information ها ارسال کردند، این اطلاعات در دیتابیسی به اسم Link State Database ذخیره میشه. هر Link State Information باید دارای اطلاعاتی باشه که به کمک اون ها روتر توانایی محاسبه ی کوتاهترین مسیر رو داشته باشه. حداقل این اطلاعات عبارتند از: شناسه ای از روتر تولید کننده ی Link State Information، شناسه ای از همسایه ی متصل به این روتر و Cost یا همون هزینه از روتر تولید کننده ی Link State Information تا همسایش.
خوب فرض کنید یک ساختار ساده مثل تصویر زیر داریم:

ادامه خواندن “سفر به اعماق پروتکل های مسیریابی: Link State ها (۳)”

سفر به اعماق پروتکل های مسیریابی: Link State ها (۲)

سلام به همه ی همراهان عزیز. اگر از مطلب قبل یادتون باشه، گفتیم که پیچیده ترین و مهم ترین بخش عملکرد Link State ها مربوط می شد به جریان Link State Information ها در ساختار. و گفتیم برای این که این جریان درست انجام بشه از فیلدهایی داخل فرمت Link State Information (اگر براتون سواله که چرا من از لفظ Link State Information استفاده می کنم، در قسمت قبل این موضوع رو توضیح دادم 🙂 ) استفاده می شد که یکی از اون ها Sequence Number بود. طراحی عملکرد این فیلد تاثیر زیادی بر نحوه ی فلودینگ Link State Information ها میذاشت. به همین دلیل مدل های مختلفی برای نحوه ی عملکرد این فیلد معرفی شد که عبارت بودند از : Linear , Circular و Lollipop. قصد داریم تا در این مطلب، با هم این مدل ها رو بررسی کنیم.

***

  • در نظر گرفتن فضای خطی برای Sequence Number:

در این مدل تصمیم بر آن شد که مقدار فیلد Sequence Number در یک بازه ی خطی متناهی از اعداد مثبت قرار داشته باشد. بنابراین اینطور در نظر گرفته شد که اگر Sequence Number، یک فیلد N بیتی باشد مثلا ۳۲ بیتی، حداکثر مقداری که می تواند در آن قرار گیرد: ۴,۲۹۳,۹۶۷,۲۹۶=۲۳۲ ‏‎ خواهد بود. ‏پس بازه ی خطی از ۰ شروع شده و تا ‏‎۴,۲۹۳,۹۶۷,۲۹۶ ادامه می یابد و شمارش Sequence Number هم از صفر شروع شده تا به حداکثر این بازه برسد.

Linear Sequence Number

در این روش اگر چند Link State Information یکسان با Sequence Number های مختلف دریافت می گردید، Link State Information با Sequence Number بزرگتر جدیدتر در نظر گرفته می شد. اما این مدل دو مشکل بزرگ داشت: اول این که در این مدل، بازه به صورت متناهی در نظر گرفته شده بود و  زمان طراحی این مدل فرض بر این بود که مقدار حداکثر بازه، آنقدر بزرگ است که روتر ‏به این مقدار حداکثر نمی رسد. اما این موضوع در نظر گرفته نشد که روتر یک دستگاه است و ممکن است دچار تداخل در عملکرد شده و همین امر باعث شود که مقدار Sequence Number به حداکثر مقدار تعیین شده برای آن برسد. در این صورت اتفاقی که رخ می داد آن بود که کل فرآیند از ‏کار می افتاد و آنقدر منتظر می ماند تا ‏Age‏ آنLink State Information ‎  در تمام ‏دیتابیس ها منقضی شده و حذف شود و حال فرآیند می توانست نمونه ی جدیدی از آنLink State Information ‎  با مقدار حداقل برای Sequence Number را تولید و ارسال نماید. ادامه خواندن “سفر به اعماق پروتکل های مسیریابی: Link State ها (۲)”

سفر به اعماق پروتکل های مسیریابی: Link State ها (۱)

سلام به همه ی همراهان عزیز. اگر با موفقیت از سرزمین Distance Vector عبور کنیم، سرزمین بعدی که بهش خواهیم رسید ‏Link State‏ نام داره. زمانی که از  Link State Routing Protocol ها یاد میشه، اون ها رو ‏هوشمند ولی پر از رمز و راز و پیچیدگی معرفی می کنن. بهتره پیش از ورود به این سرزمین، ‏کمی با خصوصیات این روتینگ پروتکل ها آشنا بشیم!  🙂

***

تاریخچه ی مختصری از تکنولوژی مسیریابی ‏Link State
برخلاف Distance Vector ها که فقط مسیرها را تبلیغ می کنند و هیچ  دیدی از کل شبکه در اختیار قرار نمی دهند، در ‏link state‏ ها روتر، مسیر تبلیغ نمی کند بلکه اطلاعاتی راجع به لینک های متصل به خود، وضعیت این لینک ها و همسایه ‏هایی که به این لینک ها متصل می باشند را به همسایه های خود تبلیغ می کند. روترها تا زمانی که این اطلاعات را از ‏همسایه های خود دریافت نکنند مسیری را برای رسیدن به مقصدی انتخاب نمی کنند. پس می توان اینگونه بیان کرد که:

Link State Routing Protocol

اگر Distance Vector ‏ها حکم یک تابلو سر دو راهی را دارند، Link State ها در حکم یک نقشه ی کامل می باشند.

اما نحوه ی عملکرد ‏link state‏ ها به طور کلی به اینصورت است که:‏

  • تشکیل رابطه ی ‏adjacency‏ یا مجاورت با همسایه ها
  •  معرفی خود به همسایه ها
  • ساخت دیتابیسی از اطلاعاتی که از همسایه ها فراگرفته شده
  • ساخت جدول روت بر اساس اطلاعات دیتابیس تشکیل شده

    ‏تمام عملکرد ‏Link State‏ ها در این چهار خط خلاصه می شود. اما این فقط ظاهر امر می باشد، بیایید دقیق تر بررسی کنیم و ببینیم ‏پشت هر کدام از این موارد چه اتفاقی در حال رخ دادن است.‏

ادامه خواندن “سفر به اعماق پروتکل های مسیریابی: Link State ها (۱)”