امنیت

بررسی و مقابله با حمله منع سرویس (DDoS)

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

عدم پذیرش سرویس

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

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

برای اینکه بفهمم مشکل از کجاست و بفهمم چطور می‌تونم جلوش رو بگیرم، سراغ لاگ سرویس آپاچی رفتم.

با دستور بالا به صورت زنده ترافیکی که روی سایت بود رو مشاهده کردم. آدرس لاگی که می‌بینید، پیش‌فرض وبمینه و شما باید در شرایط مشابه، از آدرسی استفاده کنید که در وب‌سرورتون تنظیم شده.

ترافیک سرور

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

جلوگیری از حمله عدم پذیرش سرویس

برای اینکه بتونم دقیق‌تر منشا حمله رو تشخیص بدم و جلوش رو بگیرم، ابتدا از دستور زیر، همه ترافیک از نوع pingback رو از لاگ اصلی جدا کرده و توی یک فایل دیگه به اسم wp_attack ریختم.

در قدم اول و برای مقابله کوتاه مدت در برابر حمله، از دستور زیر ip هایی که بیشترین بازدید رو داشتند، پیدا کردم.

همونطور که می‌بینید ۲۰ ردیف اول از ip هایی که بیشترین بازدید رو داشتند جدا کردم. بازدیدها حدود یک هزار تا ۳ هزارتا متغیره.

لیست IP

با دستوری مشابه دستور زیر و از طریق IPtables، این IP ها رو به فایروال اضافه کردم تا همه اتصال‌ها از سمتشون برگشت بخوره.

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

با استفاده از ماژول rewrite در آپاچی، User Agent ترافیک ورودی رو چک کرده و در صورتی که واژه‌های WordPress و Pingback from رو داشت، ممنوعش کردم. (اگر سایتم از SSL/TLS استفاده نمی‌کرد و https نداشت، می‌تونستم از فایروال برای برگشت دادن اتصال‌های مشکوک استفاده کنم.)

نکته اینه که این کار در عملکرد پلاگین Jetpack اختلال ایجاد می‌کنه.

برای تست، خودم سعی کردم یک ترافیک مشابه برای سایتم بفرستم که می‌بینید با خطای ۴۰۳ مواجه شدم.

reject

آمار حمله عدم پذیرش سرویس

بعد از مقابله با حمله، برام جالب بود که آمار این حمله رو داشته باشم.

تعداد کانکشن‌های این حمله عدم پذیرش سرویس تا قبل از مقابله باهاش، به ۲,۲۱۰,۷۲۶ رسیده بود. بیشترین شدت حمله هم به ۲۵۸ کانکشن در ثانیه رسیده بود.

اوج حمله

از تصویر بالا می‌بینید که حمله‌کننده‌ها دیروز هم تلاش کرده بودند برای از دسترس خارج کردن بلاگ من اما موفق نشده بودند.

در این حمله بیش از سی و سه هزار IP شرکت داشتند. توزیع تعداد اتصال برای هر IP نشون می‌ده که اکثر شرکت‌کننده‌ها در این حمله، کمتر از ۱۰ اتصال داشتند. یک اوج دومی هم در تعداد اتصال حدود ۵۰ تا دیده می‌شه.

چارت

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

نسخه وردپرس

توی لیست بلند بالای نسخه‌های وردپرس، سایت‌های زیادی وجود داشتند که از سال ۲۰۱۳ و ۲۰۱۴ به‌روز نشدند و هنوز از نسخه ۳ استفاده می‌کنند.

وردپرس از نسخه ۳.۹ برای مقابله با سو استفاده از pingback اطلاعاتی رو به User Agent اضافه کرده و IP حمله‌کننده‌های اصلی رو هم به مقصد ترافیک (در این حمله، سایت من) اعلام می‌کنه. با دستور زیر، اون بخش از اطلاعات ترافیک که مربوط به IP اصلی بود رو جدا کردم.

هرچند که تعداد IP های شروع کننده حمله ۳۳۷۷ تا بود اما بخش اصلی حمله از سوی مجموعه‌ای IP در روسیه بود.

اصلی IP

واسطه حمله نباشیم

برای جلوگیری از سواستفاده از سایتمون برای حمله به سایت دیگران، می‌تونیم این امکان PingBack رو غیرفعال کنیم. روش‌های مختلفی براش وجود داره، از جمله اضافه کردن یک تابع به فایل function.php اما راحت‌ترین کاری که می‌تونم پیشنهاد بدم، نصب پلاگین‌های امنیتی وردپرسه. این جوری با یک تیر چند نشون رو می‌زنید و نکته‌های امنیتی دیگه وردپرس هم اصلاح می‌کنید.

یکی از این پلاگین‌ها، iThemes Security است که پشتیانی خوبی داره و با نسخه‌های جدید وردپرس هم هم‌خوانی داره. پس از نصب و فعال‌سازی، از بخش WordPress Tweaks می‌تونید از گزینه‌های مربوط به XML-RPC برای غیرفعال کردن Pingback استفاده کنید.

itheme

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

استاندارد

6 دیدگاه برای «بررسی و مقابله با حمله منع سرویس (DDoS)»

  1. من همیشه از طریق .htaccess توی آپاچی و site.conf توی انجین‌اکس میزنم xmlrpc رو کامل میبندم…

    راستی سایتت با تور باز نمیشه، ما رو به خطر ننداز… ؛)

    • آره با htaccess هم می‌شه رول نوشت و ریجکت کرد ترافیک رو.
      تور هم الان متوجه شدم. فکر کنم کار یکی از بلک‌لیست‌هاییه که برای فایروال استفاده کردم. باید مرور کنم ببینم کدومشون داره نودهای خروجی تور رو بلک‌لیست می‌کنه.

  2. TheSoul گفت:

    من نوعی که وبلاگم روی هاست هست، اصلی ترین کاری که باید بکنم همون نصب پلاگین و غیر فعال سازی موردی که فرمودین هست، بقیه موارد بر دوش متولی مدیر سروری هست. نتیجه گیریم درسته؟

  3. TheSoul گفت:

    من نوعی که وبلاگم روی هاست هست، اصلی ترین کاری که باید بکنم همون نصب پلاگین و غیر فعال سازی موردی که فرمودین هست، بقیه موارد بر دوش مدیر سرور هست. نتیجه گیریم درسته؟

    کامنت قبلیم ایراد دستوری داشت اصلاح کردم :/

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

This site uses Akismet to reduce spam. Learn how your comment data is processed.