آمار حملات DDoS در سال 1394

با توجه به پایان سال 1394 تصمیم بر این گرفتیم که گزارش آمار حملات DDoS به شبکه های سنترال هاستینگ را طی سال گذشته منتشر کنیم.
طبق مقالات سایت های معتبر امنیتی بین المللی پیش بینی می شد که در شروع سال میلادی 2016 ( زمستان 1394) شاهد افزایش حملات DDoS خواهیم بود ؛ اما این سیر صعودی حملات بر روی وب سایت های فارسی زبان برای ما نیز کمی عجیب بود.

مطالب گذشته:
سال جدید با دنیای جدید هکر و انتظار افزایش جنگ های مجازی
افزایش حملات DDoS در ماه آخر میلادی
بازگشت جوخه مارمولک (Lizard Squad)
انجام حملات DDoS با سرویس های ابری

در زمستان 94 رکورد بزرگترین حملات به سرور های سنترال هاستینگ از زمان فعالیت ثبت شد؛ بزرگترین حمله به حجم 114گیگابیت بر ثانیه و حدود 9.800.000 پکت در ثانیه رخ داد و حدود یک ساعت به طول انجامید.
این حمله به قدری بزرگ محسوب می شود که واقعا می توان آن را به عنوان یک رکود در بین سایت های ایرانی ثبت کرد. این حجم حمله حدود 1/3 پهنای باند کل کشور است!

log2016-1

علاوه بر حمله فوق؛ حملات زیادی نیز با حجم ها و pps های بالا رخ داد که ما مجبور به ارتقا DDoS Protection شبکه برای جلوگیری از این حملات شده ایم.

همچنین علاوه بر افزایش فدرت حملات؛ شاهد افزایش کمی حملات نیز بوده ایم؛ ما در سال 1394 بالغ بر 10000 حمله DDoS را شناسایی کرده ایم. تصویر زیر نشان دهنده تعداد حملات DDoS در سال 1394 بر روی سرویس های سنترال هاستینگ است.

Book1

 

نکته: آمار حملات لایه 7 – HTTP در نمودار فوق حدودی می باشد و امکان ارائه آمار دقیق به دلیل مسایل فنی وجود نداشته ؛ این رقم یک حداقل است که بر اساس لاگ ها و شواهد به دست آمده است.

این حملات با شروع سال جدید میلادی در زمستان 94 به اوج خود رسید که گمان می رود به دلیل در دسترس قرار گرفتن ابزار های جدید و بوتر های کارامد تر است؛ همچنین با توجه به افزایش قدرت حملات UDP  پیشبینی می شود یک باگ جدید در سرویس دهندگان اینترنت توسط هکر ها کشف شده باشد که هنوز پتچ نشده است.
در سال 2012 وجود باگ در DNS سرور های شرکت ها و ISP های بزرگ منجر به استفاده ابزاری از آن سرور ها برای حملات بزرگ DDoS  می شد؛ به طوری که رکود بزرگترین حملات در آن سال شکست و تقریبا هیچ راه حلی برای این حملات وجود نداشت اما گروهی تصمیم به ایجاد پروژه ای عظیم گرفتند و نام آن را Open Resolver Project گذاشتند که در قالب تاسیس سایتی شروع به فعالیت کرد؛( جهت نمایش سایت اینجا کلیک کنید).همانطور که مشخص است وظیفه این سایت شناسایی و معرفی  DNS resolvers های باز بود که مورد سو استفاده قرار می گرفتند؛به مرور زمان این سایت به هدف نهایی خود رسید؛ افراد و شرکت هایی که مسئول این سرور ها بودند توسط این سایت و گزارش های کاربران متوجه وجود باگ های خود شدند آنها را برطرف نمودند و بعد از مدتی به صورت چشم گیری این حملات کاهش یافت اما آیا امکان دارد یک باگ جدید دوباره امنیت اینترنت را به خطر بی اندازد؟ احتمال اینکه یک باگ جدید دوباره شبکه ها و سرور ها را تهدید کند همیشه وجود دارد.

معرفی حمله TCP SYN ACK Flood

ddos-force-attack

در ادامه معرفی حملات قصد داریم متود جدیدی از حملات DDoS با عنوان TCP SYN ACK Flood را مورد بررسی قرار دهیم؛ این نوع حملات همانطور که مشخص است مبتنی بر یک ارتباط TCP به همراه SYN ACK فعال است؛ قبل از شروع معرفی باید با مراحل سه گانه اتصال TCP آشنا شوید:

اول کلاینت یک بسته SYN به سرور می فرستد.
دوم سرور یک بسته SYN ACK به کلاینت  می فرستد.
سوم کلاینت یک بسته ACK به سرور می فرستد.

هنگامی که این سه مرحله به اتمام برسد یک ارتباط مشروع و قانونی بین سرور و کلاینت برقرار می شود که می توانند به تبادل اطلاعات بپردازند. حمله TCP SYN ACK flood پکت های زیادی به صورت TCP ارسال می کند که شامل SYN و ACK فعال است؛ این نوع حمله بسیار شبیه به SYN flood است.

به خواندن ادامه دهید

معرفی حمله Ping of Death

امروز قصد داریم یک متود متفاوت و البته قدیمی به نام Ping of Death از حملات DDoS را  معرفی کنیم.

در اواخر دهه 90 میلادی یک آسیب پذیری در اکثر سیستم عامل ها کشف شد،اگر یک سیستم عامل مجبور به پردازش یک بسته بزرگتر از 65535 بایت بود ؛ این امر باعث به وجود آمدن مشکلاتی از قبیل buffer overruns یا هنگ کردن سیستم عامل و یا ریبوت کامل سیستم عامل می شد؛ البته این روش دیگر کارآیایی ندارد و سیستم عامل های امروزی چنین باگی ندارند اما در آن زمان این یک مشکل عمده محسوب می شد.

این مشکل به عنوانping of death یا پینگ مرگ معروف شد؛دلیل آن هم این بود که راهی برای کرش کردن سیستم عامل از راه دور با استفاده از ارسال رکوئست های ICMP  به آی پی قربانی یا همان پینگ با ارسال پکت هایی با حجم خاص به وجود آمده بود. حجم استاندارد یک پکت پینگ 64 بایت است.

request-time-out

مطلب زیر از ویکی پدیا برای شما بازنشر شده است :

همانطور که در RFC 791 تعریف شده‌است، بیشترین طول بسته‌ی پروتکل اینترنت نسخه ۴ که شامل سرآیند آی پی (به انگلیسی: IP header) نیز باشد، ۶۵۵۳۵ بایت است، محدوده نشان داده شده با استفاده از محدوده‌ی سرآیند آی‌پی به عرض ۱۶ بیت است که طول کل بسته را شرح می‌دهد. لایه‌ی زیرین پیوند داده‌ها محدودیت‌هایی روی بیشترین اندازه‌ی فریم می‌گذارد(MTU را ببینید). در اترنت معمولاً ۱۵۰۰ بایت است. در چنین حالتی، یک بسته‌ی آی‌پی بزرگ به چندین بسته‌ی آی‌پی تقسیم می‌شود (که با نام قطعه‌های آی‌پی شناخته می‌شود)، به طوری که هر قطعه‌ی آی‌پی با حد قرارداد شده مطابقت خواهد داشت. گیرنده‌ی قطعه‌های آی‌پی، آن‌ها را دوباره سر هم خواهد کرد تا به بسته‌ی کامل آی‌پی مبدل شود و طبق معمول به پردازش آن ادامه خواهد داد. هنگامی که قطعه‌قطعه کردن انجام شد، هر قطعه آی‌پی نیاز دارد اطلاعاتی در مورد قسمتی از بسته‌ی آی‌پی اصلی که در آن وجود دارد، حمل کند. این اطلاعات در فیلد افست قطعه در سرآیند آی‌پی نگهداری می‌شود. طول این فیلد ۱۳ بیت است و شامل افست داده‌ها در قطعه آی‌پی فعلی، در بسته‌ی آی‌پی اصلی می‌باشد. افست در واحدی از ۸ بایت داده می‌شود. این مسئله اجازه‌ی داشتن بیشترین افست یعنی ۶۵۵۲۸ را می‌دهد. یعنی هر قطعه آی‌پی با بیشترین افست، نباید داده‌های بیشتر از ۷ بایت داشته باشد، در غیر این صورت از حد مجاز تعیین شده برای بیشترین طول بسته تجاوز خواهد کرد. یک کاربر مخرب می‌تواند یک قطعه آی‌پی با بیشترین افست و با داده‌هایی خیلی بیشتر از ۸ بایت(به همان بزرگی که لایه‌ی فیزیکی اجازه می‌دهد) ارسال کند. هنگامی که گیرنده تمام قطعه‌های آی‌پی را سر هم می‌کند، با یک بسته آی‌پی بزرگتر از ۶۵۵۳۵ بایت به کار خود خاتمه می‌دهد. این احتمالاً منجر به سرریز در بافرهای حافظه‌ای می‌شود که گیرنده برای بسته در نظر گرفته‌است و می‌تواند منجر به مشکلات بسیاری شود. همانطور که از توصیف بالا مشهود است، مشکل هیچ ربطی به ICMP ندارد. این مشکلی در زمینه‌ی دوباره سر هم کردن قطعه‌های آی پی است که می‌تواند شامل هر نوع پروتکلی مانند(IGMP, UDP, TCP, …) باشد. راه حل این مشکل، اضافه کردن کنترل‌هایی در روند سر هم کردن قطعات است. این کنترل برای هر قطعه‌ی ورودی آی‌پی اطمینان حاصل می‌کند که افست قطعه و کل طول فیلدها در سرآیند آی‌پی هر قطعه آی‌پی، کوچکتر از ۶۵۵۳۵ است. اگر جمع بزرگتر شد، بنابراین بسته نامعتبر است و قطعه‌ی آی‌پی نادیده گرفته می‌شود. این کنترل توسط دیوار آتش انجام می‌شود، برای محافظت از میزبان‌هایی که این مشکل را درست نکرده‌اند. راه حل دیگر برای این مسئله، استفاده از یک میانگیر حافظه بزرگتر از ۶۵۵۳۵ بایت برای دوباره سر هم کردن بسته‌است.(این اساساً نادیده گرفتن مشخصات است، چرا که پشتیبانی از بسته‌هایی را اضافه می‌کند که بزرگتر از اندازه‌ی مجاز هستند).

معرفی حمله SYN Flood

حملات SYN flood یکی از شایع ترین حملات DDoS در لایه 4 شبکه مدل OSI که مثل حمله ACK و دیگر حملات TCP مبتنی بر یک اتصال TCP است که یک اتصال TCP طبق مطالب گذشته دارای سه مرحله است:

اول کلاینت یک بسته SYN به سرور می فرستد.
دوم سرور یک بسته SYN ACK به کلاینت  می فرستد.
سوم کلاینت یک بسته ACK به سرور می فرستد.

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

در یک حمله SYN flood که اکثرا با آی پی های جعلی انجام می شود مرحله اول اتصال انجام می شود؛ یعنی درخواست SYN ارسال می شود ولی مرحله دوم اتصال انجام نمی شود و سرور در انتظار تکمیل ارتباط می ماند و به نوعی کانکشن نیمه باز می ماند، اگر میزان کانکشن های نیمه باز افزایش یابد محدودیت کانکشن ها تمام می شود و هیچ جای خالی برای ایحاد یک کانکشن جدید بین سرور و کاربران واقعی آنها نمی ماند و به اصطلاح سرور DOWN می شود.

در مثال زیر پکت های ارسالی به سرور فرضی با آی پی 10.100.101.102 را مشاهده می کند که تحت حمله SYN flood  قرار گرفته است:

به خواندن ادامه دهید

معرفی حمله TCP ACK Flood

در راستای معرفی و واشکافی حملات DDoS ؛ امروز قصد داریم به بررسی حمله TCP ACK Flood بپردازیم؛ این حمله بخشی از یک اتصال TCP به حساب می آید.
معمولا در یک اتصال TCP سه مرحله داریم در معرفی حملات HTTP Flood آنها را توضیح داده ایم :

اول کلاینت یک بسته SYN به سرور می فرستد.
دوم سرور یک بسته SYN ACK به کلاینت  می فرستد.
سوم کلاینت یک بسته ACK به سرور می فرستد.

این مراحل با اصطلاح three-way handshake نیز شناخته می شود.

یک حمله ACK Flood شامل یک دسته کامل از بسته های TCP به همراه بیت ACK  فعال بر روی آن است. این نوع از حمله دارای  تفاوت هایی در مقایسه با SYN flood است.

اول به شما نشان می دهیم که لاگ یک حمله ACK Flood به چه صورت است ؛ در لاگ زیر یک حمله بر روی آی پی فرضی 10.100.101.102  و پورت 80 بر روی انجام است.

[.] در اینجا به معنی یک پکت TCP است.

به خواندن ادامه دهید