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

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

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

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

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

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

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 حقیقتی فراموش شده (قسمت اول: تاریخچه)”

اینترنت برای همه!

شنیدین میگن ” ما گفتیم این کار انجام بشه ولی نه دیگه اینطوری! 😐” این دقیقا عبارتی هست که Internet Society در واکنش به این خبر بانمک و البته نه چندان خوشایند گفته.

خلاصه ی خبر این بوده که چندتا از زندانیان در زندانی در اوهایو تونستن دوتا کامپیوتر رو  از طریق قطعات مختلفی که از گوشه و کنار جمع کردن، سرهم کنن و با مخفی کردن اون در سقف و اتصالش به شبکه ی زندان، بتونن به راحتی به اینترنت متصل بشن و به کارای خلافکارانه ی خودشون اونم تو اتاق گرم و نرمشون در زندان!!!! بپردازن. اینجاست که صدای Internet Society اینطوری درمیاد که: “ما گفتیم اینترنت برای همه ولی دیگه نه این شکلی! 😕” 😄

اینترنت برای همه
تصویر: وبسایت in.techradar.com

ادامه خواندن “اینترنت برای همه!”

از کار افتادن جعبه های امنیتی سیسکو بعد از ۲۱۳ و نیم روز!

باگ سیسکو
تصویر: وبسایت techmaster.co.uk

این روزها انتشار خبری دوباره سیسکو را بر راس اخبار قرار داد، خبری که شاید چندان هم برای سیسکو خوشایند نبود و آن خبر، از کار افتادن سری های خاصی از ASA ها (Adaptive Security Appliance) و FTD ها (Firepower Threat Defense )، بعد از مدت  زمان ۲۱۳ روز و ۱۲ ساعت از فعالیت آن ها بود!

سیسکو در تاریخ ۳۰ مارس با انتشار  داکیومنتی به وجود مشکلی در  ASA ها و FTD هایی که از ورژن های نرم افزاری خاصی استفاده می کردند اذعان نمود و اعلام داشت که صاحبان آن ها باید هرچه سریعتر سیستم خود را راه اندازی مجدد گردانند. در این فایل اعلام شده که این مشکل به سبب باگی نرم افزاری (و نه امنیتی) در این سری های خاص از ASA ها و FTD ها می باشد که  سبب می شود این دستگاه ها بعد از مدت زمان ۵۱۲۴ ساعت (۲۱۳ روز و ۱۲ ساعت) به صورت خودکار دیگر قادر به انتقال ترافیک نباشند. ادامه خواندن “از کار افتادن جعبه های امنیتی سیسکو بعد از ۲۱۳ و نیم روز!”

” Bro ” ابزاری قدرتمند برای آنالیز شبکه

Bro NSM

به عنوان یک ادمین شبکه یا حتی کسی که به حوزه ی شبکه علاقه داره حتما در رابطه با حملات DDoS و Mirai شنیدید.
ابزارهای Open Source زیادی وجود دارن که میتونید از اون ها به عنوان IDS در ساختار شبکتون استفاده کنید که یکی از اون ها ابزار قدرتمند و رایگانی هست به اسم  Bro Network Security Monitor.

Bro در واقع یک طرح آکادمیک/صنعتی هست که نتیجه ی سال ها تلاش و تحقیق بوده و تونسته بسیار موفق عمل کنه. چیزی که Bro رو از سایر IDS های رایج از دید کارشناسان مستثنی میکنه اینه که Bro در صورت توسعه قابلیت تولید طیف وسیعی از داده های NSM رو داره. داده های NSM به صورت کلی در این شش دسته قرار میگیرند: ادامه خواندن “” Bro ” ابزاری قدرتمند برای آنالیز شبکه”