DDoS برای نجات: چگونه تست های استرس و بار را انجام می دهیم

Variti محافظت در برابر ربات ها و حملات DDoS را توسعه می دهد و همچنین تست استرس و بار را انجام می دهد. در کنفرانس HighLoad++ 2018 در مورد چگونگی ایمن سازی منابع در برابر انواع مختلف حملات صحبت کردیم. به طور خلاصه: بخش هایی از سیستم را ایزوله کنید، از خدمات ابری و CDN استفاده کنید و مرتباً به روز رسانی کنید. اما شما هنوز نمی توانید بدون شرکت های تخصصی محافظت را انجام دهید :)

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

ضبط تصویری گزارش

بسیاری از شرکت ها از قبل می دانند که چگونه تست بار را انجام دهند، اما همه آنها تست استرس را انجام نمی دهند. برخی از مشتریان ما فکر می کنند که سایت آنها آسیب ناپذیر است زیرا آنها یک سیستم لود دارند و به خوبی از حملات محافظت می کنند. ما نشان می دهیم که این کاملا درست نیست.
البته قبل از انجام آزمایشات، از مشتری اجازه می گیریم، امضا و مهر می شود و با کمک ما نمی توان حمله DDoS را بر روی هیچ فردی انجام داد. آزمایش در زمانی انجام می‌شود که مشتری انتخاب می‌کند، زمانی که ترافیک به منبع او حداقل است و مشکلات دسترسی بر مشتریان تأثیری نخواهد داشت. علاوه بر این، از آنجایی که همیشه ممکن است در طول فرآیند آزمایش مشکلی پیش بیاید، ما دائماً با مشتری در تماس هستیم. این به شما این امکان را می دهد که نه تنها نتایج به دست آمده را گزارش دهید، بلکه می توانید چیزی را در طول آزمایش تغییر دهید. پس از اتمام آزمایش، ما همیشه گزارشی تهیه می کنیم که در آن به کاستی های شناسایی شده اشاره می کنیم و توصیه هایی برای رفع نقاط ضعف سایت ارائه می دهیم.

چگونه کار می کنیم

هنگام آزمایش، ما یک بات نت را شبیه سازی می کنیم. از آنجایی که ما با کلاینت‌هایی کار می‌کنیم که در شبکه‌های ما قرار ندارند، برای اطمینان از اینکه آزمایش در دقیقه اول به دلیل ایجاد محدودیت یا حفاظت به پایان نمی‌رسد، بار را نه از یک IP، بلکه از زیرشبکه خودمان تامین می‌کنیم. به علاوه، برای ایجاد یک بار قابل توجه، ما سرور آزمایشی نسبتاً قدرتمند خود را داریم.

فرضیه ها

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

شکست جزئی بهتر از شکست کامل است
ما همیشه توصیه می کنیم که سیستم ها را ناهمگن کنیم. علاوه بر این، ارزش آن را دارد که آنها را در سطح فیزیکی و نه فقط با کانتینر کردن جدا کنیم. در صورت جداسازی فیزیکی، حتی اگر چیزی در سایت از کار بیفتد، احتمال زیادی وجود دارد که کار به طور کامل متوقف نشود و کاربران همچنان به حداقل بخشی از عملکرد دسترسی داشته باشند.

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

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

تفاوت بین تست بار و تنش
تست بار به شما امکان می دهد محدودیت های عملکرد سیستم را شناسایی کنید. تست استرس با هدف یافتن نقاط ضعف در یک سیستم انجام می شود و برای شکستن این سیستم و مشاهده رفتار آن در روند خرابی بخش های خاص استفاده می شود. در این حالت، ماهیت بار معمولاً قبل از شروع تست استرس برای مشتری ناشناخته می ماند.

ویژگی های متمایز حملات L7

ما معمولاً انواع بار را به بارهای در سطوح L7 و L3&4 تقسیم می کنیم. L7 یک بار در سطح برنامه است، اغلب به معنای فقط HTTP است، اما منظور ما هر بار در سطح پروتکل TCP است.
حملات L7 دارای ویژگی های متمایز خاصی هستند. اولا، آنها مستقیماً به برنامه می آیند، یعنی بعید است که از طریق شبکه منعکس شوند. چنین حملاتی از منطق استفاده می کنند و به همین دلیل، CPU، حافظه، دیسک، پایگاه داده و سایر منابع را بسیار کارآمد و با ترافیک کم مصرف می کنند.

HTTP Flood

در مورد هر حمله ای، ایجاد بار آسان تر از کنترل است، و در مورد L7 نیز این موضوع صادق است. تشخیص ترافیک حمله از ترافیک قانونی همیشه آسان نیست، و اغلب این کار را می توان با فرکانس انجام داد، اما اگر همه چیز به درستی برنامه ریزی شده باشد، نمی توان از لاگ ها فهمید که حمله کجاست و درخواست های قانونی کجا هستند.
به عنوان اولین مثال، یک حمله HTTP Flood را در نظر بگیرید. نمودار نشان می دهد که چنین حملاتی معمولاً بسیار قدرتمند هستند؛ در مثال زیر، تعداد اوج درخواست ها از 600 هزار در دقیقه فراتر رفته است.

HTTP Flood ساده ترین راه برای ایجاد بار است. به طور معمول، نوعی ابزار تست بار مانند ApacheBench را می گیرد و یک درخواست و یک هدف را تعیین می کند. با چنین رویکرد ساده ای، احتمال زیادی وجود دارد که در حافظه پنهان سرور اجرا شود، اما دور زدن آن آسان است. به عنوان مثال، اضافه کردن رشته های تصادفی به درخواست، که سرور را مجبور می کند دائماً یک صفحه جدید را ارائه دهد.
همچنین، در فرآیند ایجاد بار، عامل کاربر را فراموش نکنید. بسیاری از عوامل کاربر ابزارهای تست محبوب توسط مدیران سیستم فیلتر می شوند و در این مورد ممکن است بار به سادگی به backend نرسد. شما می توانید با درج یک هدر کم و بیش معتبر از مرورگر در درخواست، نتیجه را به میزان قابل توجهی بهبود بخشید.
به همان اندازه که حملات HTTP Flood ساده هستند، معایبی نیز دارند. اولاً برای ایجاد بار به مقدار زیادی نیرو نیاز است. ثانیاً، شناسایی چنین حملاتی بسیار آسان است، به خصوص اگر از یک آدرس آمده باشند. در نتیجه، درخواست‌ها بلافاصله یا توسط مدیران سیستم یا حتی در سطح ارائه‌دهنده فیلتر می‌شوند.

چه چیزی را جستجو کنیم

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

کجا نگاه کن

وقتی یک منبع را قبل از آزمایش اسکن می کنیم، البته ابتدا به خود سایت نگاه می کنیم. ما به دنبال انواع فیلدهای ورودی، فایل های سنگین هستیم - به طور کلی، هر چیزی که می تواند برای منبع مشکل ایجاد کند و عملکرد آن را کند کند. ابزارهای توسعه پیش پا افتاده در گوگل کروم و فایرفاکس در اینجا کمک می کنند و زمان پاسخگویی صفحه را نشان می دهند.
ما همچنین زیر دامنه ها را اسکن می کنیم. به عنوان مثال، یک فروشگاه اینترنتی خاص به نام abc.com وجود دارد و دارای یک زیر دامنه admin.abc.com است. به احتمال زیاد، این یک پنل مدیریت با مجوز است، اما اگر روی آن بارگذاری کنید، می تواند برای منبع اصلی مشکل ایجاد کند.
این سایت ممکن است دارای یک زیر دامنه api.abc.com باشد. به احتمال زیاد، این منبعی برای برنامه های کاربردی تلفن همراه است. برنامه را می توان در فروشگاه App یا Google Play پیدا کرد، یک نقطه دسترسی ویژه نصب کرد، API را کالبدشکافی کرد و حساب های آزمایشی را ثبت کرد. مشکل این است که مردم اغلب فکر می کنند هر چیزی که توسط مجوز محافظت می شود در برابر حملات انکار سرویس مصون است. ظاهراً مجوز بهترین CAPTCHA است، اما اینطور نیست. ساختن 10 تا 20 حساب آزمایشی آسان است، اما با ایجاد آنها، به عملکردهای پیچیده و پنهانی دسترسی پیدا می کنیم.
به طور طبیعی، ما به تاریخ نگاه می کنیم، به robots.txt و WebArchive، ViewDNS، و به دنبال نسخه های قدیمی منبع می گردیم. گاهی اوقات اتفاق می‌افتد که توسعه‌دهندگان، مثلاً mail2.yandex.net را منتشر کرده‌اند، اما نسخه قدیمی، mail.yandex.net، باقی می‌ماند. این mail.yandex.net دیگر پشتیبانی نمی شود، منابع توسعه به آن اختصاص داده نمی شود، اما همچنان به مصرف پایگاه داده ادامه می دهد. بر این اساس، با استفاده از نسخه قدیمی، می توانید به طور موثر از منابع باطن و هر چیزی که در پشت طرح است استفاده کنید. البته، همیشه این اتفاق نمی افتد، اما ما هنوز هم اغلب با آن مواجه می شویم.
به طور طبیعی، ما تمام پارامترهای درخواست و ساختار کوکی را تجزیه و تحلیل می کنیم. مثلاً می‌توانید مقداری ارزش را در یک آرایه JSON در داخل یک کوکی بریزید، تعداد زیادی تودرتو ایجاد کنید و منبع را برای مدت طولانی غیرمنطقی کار کنید.

بار جستجو

اولین چیزی که هنگام تحقیق در مورد یک سایت به ذهن خطور می کند این است که پایگاه داده را بارگذاری کنید، زیرا تقریباً همه جستجو دارند و تقریباً برای همه متأسفانه محافظت ضعیفی از آن وجود دارد. به دلایلی، توسعه دهندگان توجه کافی به جستجو ندارند. اما یک توصیه در اینجا وجود دارد - شما نباید درخواست هایی از یک نوع داشته باشید، زیرا ممکن است با کش کردن مواجه شوید، همانطور که در مورد سیل HTTP وجود دارد.
ایجاد پرس و جوهای تصادفی در پایگاه داده نیز همیشه مؤثر نیست. بسیار بهتر است که فهرستی از کلمات کلیدی مرتبط با جستجو ایجاد کنید. اگر به مثال یک فروشگاه آنلاین برگردیم: فرض کنید سایت لاستیک خودرو را می فروشد و به شما امکان می دهد شعاع لاستیک ها، نوع خودرو و سایر پارامترها را تنظیم کنید. بر این اساس، ترکیب کلمات مرتبط پایگاه داده را مجبور می کند تا در شرایط بسیار پیچیده تری کار کند.
علاوه بر این، ارزش استفاده از صفحه بندی را دارد: بازگرداندن صفحه ماقبل آخر نتایج جستجو برای جستجو بسیار دشوارتر از صفحه اول است. یعنی با کمک صفحه بندی می توانید بار را کمی متنوع کنید.
مثال زیر بار جستجو را نشان می دهد. مشاهده می شود که از همان ثانیه اول تست با سرعت ده درخواست در ثانیه سایت از کار افتاد و پاسخی نداد.

اگر جستجو وجود ندارد؟

اگر جستجو وجود نداشته باشد، این بدان معنا نیست که سایت حاوی فیلدهای ورودی آسیب‌پذیر دیگری نیست. این فیلد ممکن است مجوز باشد. امروزه، توسعه دهندگان دوست دارند برای محافظت از پایگاه داده ورود در برابر حمله جدول رنگین کمان، هش های پیچیده ایجاد کنند. این خوب است، اما چنین هش هایی منابع CPU زیادی را مصرف می کنند. جریان زیادی از مجوزهای نادرست منجر به خرابی پردازنده می شود و در نتیجه سایت از کار می افتد.
وجود انواع فرم ها برای نظر و بازخورد در سایت دلیلی است برای ارسال متون بسیار بزرگ به آنجا یا ایجاد یک سیل عظیم. گاهی اوقات سایت ها فایل های پیوست شده را می پذیرند، از جمله با فرمت gzip. در این حالت یک فایل 1 ترابایتی را برداشته و با استفاده از gzip به چند بایت یا کیلوبایت فشرده کرده و به سایت ارسال می کنیم. سپس از حالت فشرده خارج می شود و جلوه بسیار جالبی به دست می آید.

استراحت API

من می خواهم کمی به خدمات محبوبی مانند Rest API توجه کنم. ایمن سازی Rest API بسیار دشوارتر از یک وب سایت معمولی است. حتی روش‌های بی‌اهمیت محافظت در برابر نیروی brute force و سایر فعالیت‌های غیرقانونی برای Rest API کار نمی‌کنند.
شکستن API Rest بسیار آسان است زیرا مستقیماً به پایگاه داده دسترسی دارد. در عین حال، شکست چنین خدماتی عواقب بسیار جدی برای تجارت به همراه دارد. واقعیت این است که Rest API معمولاً نه تنها برای وب سایت اصلی، بلکه برای برنامه تلفن همراه و برخی از منابع داخلی کسب و کار استفاده می شود. و اگر همه اینها سقوط کند، تأثیر آن بسیار قوی تر از شکست یک وب سایت ساده است.

بارگیری محتوای سنگین

اگر به ما پیشنهاد شود که برخی از وب‌سایت‌های برنامه تک صفحه‌ای معمولی، صفحه فرود یا کارت ویزیت را آزمایش کنیم که عملکرد پیچیده‌ای ندارند، به دنبال محتوای سنگین می‌گردیم. به عنوان مثال، تصاویر بزرگی که سرور ارسال می کند، فایل های باینری، اسناد pdf - ما سعی می کنیم همه اینها را دانلود کنیم. چنین تست هایی سیستم فایل را به خوبی بارگذاری می کنند و کانال ها را مسدود می کنند و بنابراین موثر هستند. یعنی حتی اگر سرور را زمین نگذارید، یک فایل حجیم را با سرعت کم دانلود کنید، به سادگی کانال سرور مورد نظر را مسدود می کنید و سپس انکار سرویس رخ می دهد.
نمونه ای از چنین آزمایشی نشان می دهد که با سرعت 30 RPS سایت دیگر پاسخ نمی دهد یا خطاهای 500 سرور ایجاد می کند.

راه اندازی سرورها را فراموش نکنید. اغلب می توانید متوجه شوید که شخصی یک ماشین مجازی خریده، Apache را در آنجا نصب کرده، همه چیز را به طور پیش فرض پیکربندی کرده، یک برنامه PHP نصب کرده است و در زیر می توانید نتیجه را مشاهده کنید.

در اینجا بار به ریشه رفت و تنها 10 RPS بود. ما 5 دقیقه صبر کردیم و سرور از کار افتاد. درست است که به طور کامل مشخص نیست که چرا او سقوط کرد، اما این فرض وجود دارد که او به سادگی حافظه بیش از حد داشت و بنابراین دیگر پاسخ نداد.

مبتنی بر موج

در یکی دو سال اخیر، حملات موج بسیار محبوب شده اند. این به دلیل این واقعیت است که بسیاری از سازمان‌ها قطعات خاصی از سخت‌افزار را برای محافظت از DDoS خریداری می‌کنند که برای شروع فیلتر کردن حمله، به زمان مشخصی برای جمع‌آوری آمار نیاز دارد. یعنی در 30-40 ثانیه اول حمله را فیلتر نمی کنند، زیرا داده ها را جمع می کنند و یاد می گیرند. بر این اساس، در این 30-40 ثانیه می توانید آنقدر روی سایت راه اندازی کنید که منبع برای مدت طولانی باقی بماند تا زمانی که همه درخواست ها پاک شوند.
در مورد حمله زیر، یک فاصله 10 دقیقه ای وجود داشت، پس از آن یک بخش جدید و اصلاح شده از حمله وارد شد.

یعنی دفاع یاد گرفت، شروع به فیلترینگ کرد، اما یک قسمت جدید و کاملا متفاوت از حمله رسید و دفاع دوباره شروع به یادگیری کرد. در واقع، فیلتر کردن کار نمی کند، محافظت بی اثر می شود و سایت در دسترس نیست.
حملات موج با مقادیر بسیار بالا در اوج مشخص می شود، در مورد L7 می تواند به صد هزار یا یک میلیون درخواست در ثانیه برسد. اگر در مورد L3&4 صحبت کنیم، اگر در بسته ها حساب کنید، ممکن است صدها گیگابیت ترافیک یا، بر این اساس، صدها mpps وجود داشته باشد.
مشکل چنین حملاتی همگام سازی است. حملات از طریق یک بات نت انجام می شود و به درجه بالایی از همگام سازی برای ایجاد یک اسپایک بسیار بزرگ یک بار مصرف نیاز دارند. و این هماهنگی همیشه جواب نمی دهد: گاهی اوقات خروجی نوعی اوج سهموی است که نسبتاً رقت انگیز به نظر می رسد.

نه تنها HTTP

علاوه بر HTTP در L7، ما دوست داریم از پروتکل های دیگر نیز بهره برداری کنیم. به عنوان یک قاعده، یک وب سایت معمولی، به خصوص یک میزبان معمولی، دارای پروتکل های ایمیل و خروجی MySQL است. پروتکل‌های ایمیل نسبت به پایگاه‌های داده بار کمتری دارند، اما می‌توان آن‌ها را نیز کاملاً کارآمد بارگذاری کرد و در نهایت با یک CPU بیش از حد بر روی سرور به پایان رسید.
ما با استفاده از آسیب‌پذیری SSH 2016 کاملاً موفق بودیم. اکنون این آسیب پذیری تقریباً برای همه برطرف شده است، اما این بدان معنا نیست که نمی توان بار را به SSH ارسال کرد. می توان. صرفاً تعداد زیادی مجوز وجود دارد، SSH تقریباً کل CPU سرور را می خورد و سپس وب سایت از یک یا دو درخواست در هر ثانیه از بین می رود. بر این اساس، این یک یا دو درخواست مبتنی بر گزارش‌ها را نمی‌توان از یک بار قانونی تشخیص داد.
بسیاری از اتصالاتی که در سرورها باز می کنیم نیز مرتبط باقی می مانند. قبلاً Apache در این مورد مقصر بود، اکنون nginx در واقع مقصر است، زیرا اغلب به صورت پیش فرض پیکربندی شده است. تعداد اتصالاتی که nginx می تواند باز نگه دارد محدود است، بنابراین ما این تعداد اتصال را باز می کنیم، nginx دیگر اتصال جدید را قبول نمی کند و در نتیجه سایت کار نمی کند.
خوشه آزمایشی ما دارای CPU کافی برای حمله به SSL handshake است. در اصل، همانطور که تمرین نشان می دهد، بات نت ها گاهی اوقات دوست دارند این کار را نیز انجام دهند. از یک طرف، واضح است که شما نمی توانید بدون SSL کار کنید، زیرا نتایج گوگل، رتبه بندی، امنیت. از طرف دیگر، SSL متاسفانه یک مشکل CPU دارد.

L3&4

وقتی در مورد حمله در سطوح L3&4 صحبت می کنیم، معمولاً در مورد حمله در سطح پیوند صحبت می کنیم. چنین باری تقریباً همیشه از یک بار قانونی قابل تشخیص است، مگر اینکه یک حمله SYN-flood باشد. مشکل حملات SYN-flood برای ابزارهای امنیتی حجم زیاد آنهاست. حداکثر مقدار L3&4 1,5-2 ترابیت بر ثانیه بود. پردازش این نوع ترافیک حتی برای شرکت های بزرگ از جمله اوراکل و گوگل بسیار دشوار است.
SYN و SYN-ACK بسته هایی هستند که هنگام برقراری اتصال استفاده می شوند. بنابراین، تشخیص SYN-flood از یک بار قانونی دشوار است: مشخص نیست که آیا این SYN است که برای ایجاد یک اتصال آمده است یا بخشی از یک سیل.

UDP-سیل

به طور معمول، مهاجمان توانایی های ما را ندارند، بنابراین می توان از تقویت برای سازماندهی حملات استفاده کرد. یعنی مهاجم اینترنت را اسکن می‌کند و سرورهای آسیب‌پذیر یا پیکربندی نادرست را پیدا می‌کند که برای مثال، در پاسخ به یک بسته SYN، با سه SYN-ACK پاسخ می‌دهند. با جعل آدرس منبع از آدرس سرور مورد نظر، می توان با یک بسته، قدرت را مثلاً سه برابر افزایش داد و ترافیک را به سمت قربانی هدایت کرد.

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

SYN-flood مشکل

SYN-flood احتمالاً جالب‌ترین نوع حمله از دیدگاه توسعه‌دهندگان است. مشکل این است که مدیران سیستم اغلب از مسدود کردن IP برای محافظت استفاده می کنند. علاوه بر این، مسدود کردن IP نه تنها بر مدیران سیستم که با استفاده از اسکریپت ها عمل می کنند، بلکه متأسفانه برخی از سیستم های امنیتی را نیز تحت تأثیر قرار می دهد که با پول زیادی خریداری می شوند.
این روش می تواند به یک فاجعه تبدیل شود، زیرا اگر مهاجمان آدرس های IP را جایگزین کنند، شرکت زیرشبکه خود را مسدود می کند. هنگامی که فایروال خوشه خود را مسدود می کند، خروجی در تعاملات خارجی با شکست مواجه می شود و منبع از کار می افتد.
علاوه بر این، مسدود کردن شبکه خود کار دشواری نیست. اگر دفتر کارفرما دارای شبکه وای فای باشد یا عملکرد منابع با استفاده از سیستم های نظارتی مختلف سنجیده شود، آدرس IP این سیستم مانیتورینگ یا وای فای دفتر مشتری را می گیریم و از آن به عنوان منبع استفاده می کنیم. در پایان، به نظر می رسد منبع در دسترس است، اما آدرس های IP هدف مسدود شده است. بنابراین، شبکه Wi-Fi کنفرانس HighLoad که محصول جدید این شرکت در آن ارائه می شود، ممکن است مسدود شود و این مستلزم هزینه های تجاری و اقتصادی خاصی است.
در طول آزمایش، نمی‌توانیم از تقویت از طریق memcached با هیچ منبع خارجی استفاده کنیم، زیرا توافق‌هایی برای ارسال ترافیک فقط به آدرس‌های IP مجاز وجود دارد. بر این اساس، از تقویت از طریق SYN و SYN-ACK استفاده می کنیم، زمانی که سیستم به ارسال یک SYN با دو یا سه SYN-ACK پاسخ می دهد و در خروجی حمله دو یا سه برابر می شود.

ابزارهای

یکی از ابزارهای اصلی که برای بار کاری L7 استفاده می کنیم Yandex-tank است. به طور خاص، یک فانتوم به عنوان یک تفنگ استفاده می شود، به علاوه چندین اسکریپت برای تولید کارتریج و برای تجزیه و تحلیل نتایج وجود دارد.
Tcpdump برای تجزیه و تحلیل ترافیک شبکه و Nmap برای تجزیه و تحلیل سرور استفاده می شود. برای ایجاد بار در سطح L3&4، از OpenSSL و کمی جادوی خودمان با کتابخانه DPDK استفاده می شود. DPDK یک کتابخانه از اینتل است که به شما امکان می دهد با دور زدن پشته لینوکس با رابط شبکه کار کنید و در نتیجه کارایی را افزایش دهید. طبیعتاً ما از DPDK نه تنها در سطح L3&4، بلکه در سطح L7 نیز استفاده می کنیم، زیرا به ما امکان می دهد جریان بار بسیار بالایی را در محدوده چند میلیون درخواست در ثانیه از یک ماشین ایجاد کنیم.
ما همچنین از مولدهای ترافیک و ابزارهای ویژه ای استفاده می کنیم که برای آزمایش های خاص می نویسیم. اگر آسیب پذیری تحت SSH را به خاطر بیاوریم، مجموعه فوق قابل سوء استفاده نیست. اگر به پروتکل ایمیل حمله کنیم، از ابزارهای ایمیل استفاده می کنیم یا به سادگی روی آنها اسکریپت می نویسیم.

یافته ها

به عنوان جمع بندی می خواهم بگویم:

• علاوه بر تست بار کلاسیک، انجام تست استرس نیز ضروری است. ما یک مثال واقعی داریم که در آن پیمانکار فرعی شریک فقط آزمایش بار را انجام داده است. نشان داد که منبع می تواند بار معمولی را تحمل کند. اما پس از آن یک بار غیرعادی ظاهر شد، بازدیدکنندگان سایت شروع به استفاده از منبع کمی متفاوت کردند و در نتیجه پیمانکار فرعی دراز کشید. بنابراین، حتی اگر از قبل از حملات DDoS محافظت شده باشید، ارزش آن را دارد که به دنبال آسیب‌پذیری باشید.
• لازم است برخی از قسمت های سیستم را از قسمت های دیگر جدا کرد. اگر جستجو دارید، باید آن را به ماشین های جداگانه منتقل کنید، یعنی حتی به داکر هم نخواهید رسید. زیرا اگر جستجو یا مجوز ناموفق باشد، حداقل چیزی به کار خود ادامه خواهد داد. در مورد فروشگاه آنلاین، کاربران به یافتن محصولات در کاتالوگ ادامه می‌دهند، از تجمیع‌کننده می‌روند، اگر قبلاً مجاز هستند خرید می‌کنند یا از طریق OAuth2 مجوز می‌دهند.
• از انواع خدمات ابری غافل نشوید.
• از CDN نه تنها برای بهینه‌سازی تأخیرهای شبکه، بلکه به‌عنوان وسیله‌ای برای محافظت در برابر حملات در فرسودگی کانال و سیل به ترافیک ساکن استفاده کنید.
• استفاده از خدمات حفاظتی تخصصی ضروری است. شما نمی توانید از خود در برابر حملات L3&4 در سطح کانال محافظت کنید، زیرا به احتمال زیاد کانال کافی ندارید. همچنین بعید است که با حملات L7 مقابله کنید، زیرا آنها می توانند بسیار بزرگ باشند. به علاوه، جستجوی حملات کوچک هنوز در انحصار سرویس های ویژه، الگوریتم های ویژه است.
• به طور منظم به روز کنید. این نه تنها در مورد کرنل، بلکه برای دیمون SSH نیز صدق می کند، به خصوص اگر آنها را به بیرون باز کنید. در اصل، همه چیز باید به روز شود، زیرا بعید است که بتوانید آسیب پذیری های خاص را به تنهایی ردیابی کنید.

منبع: www.habr.com