DOTS، روشی جدید در مواجهه با حملات DDoS؟

این روزها حملات DDoS به بخش لاینفکی از دنیای اینترنت مبدل شده‌اند و روز به روز نیز در حال پیچیده‌تر و قوی‌تر شدن می باشند.
طبعاً شرکت‌های مختلفی وجود دارند که سرویس‌های DDoS Protection/Mitigation ارائه کرده و هر یک از آن‌ها نیز راهکارها و روش های خاص خود را دارند (گاهی نیز شبیه به هم).

جدای از بحث استفاده از تجهیزات مقابله با DDoS در شبکه‌ها، زمانی که از یک سرویس‌دهنده‌ی بیرونی استفاده می‌شود، بطور خیلی کلی، معمولا دو حالت پیاده‌سازی (با استفاده از BGP و Tunnel) وجود دارد (معروف به Diversion/Reinjection یا Offramping/Onramping):

  • کل ترافیک دائماً از طریق آن سرویس‌دهنده عبور داده شود و اگر حمله‌ای وجود داشته باشد، همانجا مانده و تنها (به اصطلاح) ترافیک پاک به شبکه برسد (Scrubbing).
  • فقط زمانی که شبکه تحت حمله قرار می‌گیرد، طی یکسری عملیات و تغییر routing، ترافیک ورودی به شبکه بجای آن که مستقیم از اینترنت به شبکه وارد شود، مانند مدل قبل به سمت یک سرویس‌دهنده هدایت شده و توسط آن بررسی شده و تنها ترافیک پاک به شبکه می‌رسد. این روش، به نوعی On-demand محسوب می شود و کل عملیات و تغییر روتینگ می تواند به صورت خودکار و یا بصورت دستی توسط یک اپراتور رخ دهد.

شبکه ها - DOTS - DDoS Protection Mitigation

ادامه خواندن “DOTS، روشی جدید در مواجهه با حملات DDoS؟”

آشنایی با اصول اولیه ی IPv6 (اینفوگرافیک)

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

با این حال هنوز هم بسیاری از دستگاه ها در دنیای اینترنت هم چنان از IPv4 استفاده می کنند و بسیاری از کاربران با مفهوم IP آشنا نمی باشند.

اینفوگرافیگی که در ادامه آمده جهت آشنایی و کمک به افرادی تهیه شده است که شناخت چندانی از IP و ضرورت مهاجرت به IPv6 ندارند ولی این روزها بیش از پیش با این مفاهیم روبه رو می شوند. ادامه خواندن “آشنایی با اصول اولیه ی IPv6 (اینفوگرافیک)”

پادکست ۳ – بررسی مفهوم Leaky Abstraction

تقریبا دو هفته پیش بود که به خاطر درخواست یکی از مشتریان AT&T مبنی بر مشکلی که برای ارتباطات و سرویس هاش در چندین کشور مختلف اروپا به وجود اومده بود، وارد پروسه ی خطایابی مشکل این مشتری شدم. معمولا زمانی معمارها و مشاوران درگیر چنین موضوعاتی میشن که تیم مهندسی نتونن مشکل رو رفع کنن و مشتری درخواست نظارت رده های بالاتر و از شرکت داشته باشه.

مشکل این مشتری این بود که از یک تاریخ مشخصی به طور ناگهانی در زمان هایی از روز در ارتباطات بین نقاط مختلفش در اروپا Packet loss زیادی مشاهده می شد و برخی از سرویس هاش به مشکل می خوردن.

تیم مهندسی شبکه تقریبا همه چیز رو بررسی کرده بود اما هنوز نتونسته بود عامل بروز این مشکل رو پیدا کنه. اتفاق عجیبی که هر ۴ یا ۵ ساعت یکبار رخ میداد و باعث این Packet loss می شد اما …

این ها بخشی از اتفاقی بود که برای یکی از مشتریان AT&T این اواخر رخ داده بود و در این پادکست شرح داده میشه.

در این رویداد خواهید دید که چطور تغییرات و تصمیم گیری هایی در یک بخش میتونن به بخش های دیگه ای از شبکه نفوذ کنن که شاید مستقیما درگیر اون تغییرات نیستن ولی تحت تاثیر اون ها قرار می گیرن. این مساله اصطلاحا Leaky Abstraction یا انتزاع رخنه گر نامیده میشه که قبلا توضیحی مختصر راجع به اون در این پست داده شده بود. ادامه خواندن “پادکست ۳ – بررسی مفهوم Leaky Abstraction”

DNSSEC حقیقتی فراموش شده (قسمت اول: تاریخچه)

مدتی بود که تقریبا در اکثر مقالاتی که میخوندم چشمم به اصطلاحی می افتاد به اسم DNSSEC. از اونجایی که چندان میونه ی خوبی با امنیت ندارم (امنیت هم با من میونه ی خوبی نداره 🙂 ) با خودم میگفتم خب DNS که تکلیفش معلومه چیه، SEC هم که یعنی Security، پس احتمالا باید مربوط باشه به یک توسعه ی امنیتی برای DNS. اما هرچی بیشتر زمان می گذشت تاکید بر این واژه بیشتر و بیشتر می شد. همین عامل باعث شد که من بالاخره بخوام پا در دنیای امنیت (البته صرفا برای مدتی کوتاه و برای یک بخش خیلی کوچیک از این دنیا 🙂 ) بذارم و به دنبال شناخت DNSSEC برم.

قبل از هرچیزی دوست دارم شما هم مثل من با تاریخچه ی شکل گیری و ظهور DNSSEC آشنا بشید چون نظرم این هست که دونستن تاریخچه‌ی هر چیزی ما رو در یافتن نیازها و ایده ی اصلی که منجر به ایجاد اون مفهوم شده و هم چنین درک درست عملکردش کمک میکنه.

***

زمانی که مفهوم اینترنت به گستردگی حال حاضر نبود، سیستم ها برای برقراری ارتباط با یکدیگر، مستقیما از IP بهره می گرفتند. پس از چندی تصمیم بر آن شد که سیستم ها با نام همدیگر را فرابخوانند. به همین جهت باید از مکانیزمی استفاده می شد که برای سیستم مشخص می گردید که IP متناظر با هر نام چیست. این مکانیزم استفاده از فایلی با نام host بود که در آن IP متناظر با هر نام درج می گردید و باید به هر سیستمی که قصد ارتباط با سایر سیستم ها با نام را داشت منتقل می شد. اما با گسترده تر شدن دنیای اینترنت و اضافه شدن میلیون ها Host به این ساختار، استفاده از فایل host و انتقال آن به هر سیستم عملا غیرممکن شد.

همین عامل سبب معرفی سرویسی با نام Domain Name Service (DNS) گردید. این سرویس طی دو RFC با شماره های ۸۸۲ (بررسی مشکلاتی که سبب ایجاد این سرویس گردید) و ۸۸۳ (بررسی مشخصات و ویژگی های عملکردی DNS) در سال ۱۹۸۳ معرفی شد.

نحوه ی عملکرد DNS در حالت نرمال:

DNS یک دیتابیس توزیع شده، سلسه مراتبی و داینامیک است که وظیفه ی آن نگاشت اطلاعاتی چون hostname، آدرس IP، رکوردهای text، اطلاعات تبادل mail (یا همان رکورد MX)، اطلاعات name server ها (NS record) و هم چنین اطلاعات کلید امنیتی به یکدیگر می باشد که هر کدام از این اطلاعات توسط یک Resource Record یا اصطلاحا RR مشخص می شوند.

اطلاعات مشخص شده در RR ها در zone های مختلف گروهبندی شده و داخل یک DNS server محلی نگهداری می شوند. این DNS سرور محلی می تواند از طریق معماری توزیع شده ی DNS، به صورت جهانی نیز در دسترس قرار گیرد. DNS هم میتواند از UDP برای انتقال اطلاعات خود بهره گیرد و هم TCP و به صورت پیش فرض از destination port 53 استفاده میکند.

آدرس های DNS از چندین label ساخته شده اند که هر label مشخص کننده ی سلسله مراتبی است که به ترتیب باید به سراغ آن ها رفت. این label ها از راست به چپ بررسی می شوند. به عنوان مثال آدرس .www.example.com دارای چهار label می باشد: www که در این سلسله مراتب leaf محسوب می شود؛ example” که یک دامنه است؛ com که یک TLD یا Top Level Domain می باشد و نهایتا “.” که نشان دهنده ی Root Server است.

زمانی که در مرورگر خود آدرس www.example.com را وارد می کنید، در اولین گام سیستم عامل Cache خود را بررسی می کند تا شاید آدرس IP متناظر با آن را بیابد. در صورتی که هیچ رکوردی پیدا نکرد، recursive query ای را به سمت Recursive Resolver ارسال می کند.

در DNS از دو نوع query استفاده می شود: recursive و iterative. تفاوت این دو query در آن است که:

  • recursive query حتما باید با ارسال یک response پاسخ داده شود
  • iterative query نیازی به دریافت response یا پاسخ ندارد.

منظور از Recursive resolver می تواند به عنوان مثال DNS سروری که ISP برای شما فراهم کرده باشد و یا هر name server دیگری. Recursive Resolver در واقع از سایر DNS سرورهایی که می توانند به سوال آن در رابطه با IP آدرس www.example.com پاسخ دهند، آگاهی دارد. Recursive Resolver ابتدا با بررسی Cache خود اطمینان حاصل می کند که از آدرس IP آن Host اطلاع دارد یا نه. اگر نداشته باشد با بررسی label های آدرس .www.example.com از چپ به راست (اولین برچسب . می باشد) متوجه می شود که اولین مکانی که برای پیدا کردن آدرس IP مربوطه باید به سراغ آن برود Root Server است.

در حال حاضر سیزده Root Server در سراسر دنیا وجود دارد که در بردارنده ی اطلاعات DNS مربوط به Top Level Domain ها  (TLD) می باشند. (لازم به ذکر است که ایران نیز یکی از میزبانان K.root-servers.net می باشد)  TLD ها در واقع دامنه هایی چون .com، .org و … هستند. بنابراین Recursive Resolver با ارسال یک iterative query از Root Server در رابطه به com. سوال می پرسد و Root Server نیز در پاسخ، برای آن آدرس IP مربوط به TLD .com را ارسال می کند.

در گام بعد Recursive Resolver یک iterative request برای TLD ای که آدرس IP آن را از Root Server دریافت نمود، ارسال کرده و در رابطه با example.com می پرسد. TLD ها، DNS Server هایی هستن که اطلاعات DNS مربوط به زیردامنه های خود را نگهداری می کنند (در اینجا example). زمانی که TLD درخواست را دریافت می کند آدرس IP مربوط به example.com را برای Recursive Resolver مربوطه ارسال می نماید.

در مرحله ی بعد Recursive Resolver با ارسال یک iterative query برای example.com آدرس IP متعلق به رکورد www.example.com را خواستار می شود. example.com نیز با ارسال آدرس IP مربوط به رکورد www.example.com به این query پاسخ میدهد. نهایتا Recursive Resolver که اکنون آدرس IP مربوط به www.example.com را یافته آن را برای سیستم شما ارسال کرده و صفحه ی مربوط به این آدرس در مرورگر شما باز می شود (البته با چشم پوشی از چند مرحله ی دیگر که بعد از این مراحل رخ می دهند و ارتباطی با DNS ندارند). تمام این اتفاقات در کم تر از چند ثانیه رخ می دهند. تصویر زیر نمایانگر مراحلی است که شرح داده شد:

DNS Lookup ادامه خواندن “DNSSEC حقیقتی فراموش شده (قسمت اول: تاریخچه)”

پادکست ۲ – تخصص شبکه؛ امروز و فردا!

در این پادکست با دو تن از متخصصین عزیز شبکه، جناب آقای مهندس حسین خسروی (CCIE# 55382, n*CCxP) و جناب آقای مهندس حامد ذوالقدری (CCDE #20150003, 3*CCIE36789) در بحث شیرین تخصص شبکه همراه بودیم.

آقای مهندس خسروی در حال حاضر ساکن کانادا هستند و چندین سال است که به صورت حرفه ای در زمینه ی شبکه مشغول به فعالیت می باشند. ایشان علاوه بر مدارک متعددی که در این حوزه اخذ نموده بودند، در ژانویه ی امسال (۲۰۱۷) موفق به اخذ مدرک CCIE R&S شدند.

آقای مهندس ذوالقدری نیز با اخذ مدارک CCIE در شاخه های R&S، SP و Data Center و هم چنین CCDE، در حال حاضر دانشجوی دکترا در زمینه‌ی Software Defined Networks و ساکن دوبلین بوده و به صورت حرفه ای و در مقام مشاور در طرح های شبکه مشغول به فعالیت می باشند. ادامه خواندن “پادکست ۲ – تخصص شبکه؛ امروز و فردا!”