پیش از این در مورد ابزارهای حمله منع سرویس نوشته بودم. حمله‌های منع سرویس ساده و توزیع شده، از اون نمونه حمله‌هاست که اکثر مدیران سایت تجربه‌اش کردند. روز گذشته، وبلاگ من هم تحت حمله DDoS بود که تا زمان مقابله با بخش اصلی حمله و برگشت وبلاگ به سرویس، بیش از دو میلیون درخواست به سرور ارسال شده بود. در ادامه از این تجربه و روشی که برای مقابله استفاده کردم می‌نویسم.
امروز در زمان کار روی یک پروژه بودم و متوجه شدم تعداد ایمیل‌های دریافتیم به طرز عجیبی زیاد شده. ایمیل‌ها از سمت سرور و سرویس‌های چک کردن دردسترس بودن سایت و غیره بود. سرویس آپاچی از کار افتاده بود. همچنین وبمین که برای مدیریت سرور ازش استفاده می‌کنم قادر به سرویس‌دهی نبود. فشار به حدی روی سرور زیاد بود که SSH هم وصل نمی‌شد. گراف‌های سی‌پی‌یو، مموری و ترافیک ورودی و خروجی، نشون می‌داد که ترافیک خیلی زیادی، به نسبت منابع سرور و ترافیک معمول سایت من، روی سایته و احتمالا با حمله منع سرویس، از نوع توزیع شده و در لایه اپلیکیشن طرفم.
از اتصال مجازی سرویس‌دهنده سرور (دیجیتال اوشن) استفاده کردم و به هر ترفندی بود، موفق شدم سرویس آپاچی رو کامل قطع کنم تا فشار ترافیک ورودی، به سرور منتقل نشه. هرچند که به خاطر تنظیماتی که خودم انجام دادم، آپاچی بعد از مدت کوتاهی به سرویس برمی‌گشت و فشار روی سرور مجدد بالا می‌رفت.
برای اینکه بفهمم مشکل از کجاست و بفهمم چطور می‌تونم جلوش رو بگیرم، سراغ لاگ سرویس آپاچی رفتم.
1 | tail -f HOME/logs/access_log |
با دستور بالا به صورت زنده ترافیکی که روی سایت بود رو مشاهده کردم. آدرس لاگی که می‌بینید، پیش‌فرض وبمینه و شما باید در شرایط مشابه، از آدرسی استفاده کنید که در وب‌سرورتون تنظیم شده.
مشاهده ترافیک سایت نشون داد که حدسم در حمله منع سرویس توزیع شده در لایه ۷ درست بود. حمله کننده به جای اینکه خودش به صورت مستقیم سایت من رو هدف بگیره، با سواستفاده از یکی از امکانات وردپرس، از هزاران سایت دیگه استفاده کرده بود. pingback که به صورت پیش‌فرض در وردپرس فعاله، به سایت‌های وردپرسی امکان می‌ده که از لینک‌های به مطالبشون مطلع بشن و با چک کردن و تاییدش، اون رو نمایش بدن. در این حمله، با سواستفاده از امکان pingback در وردپرس، سایت‌های دیگه رو فریب می‌دادند که از سایت من بازدید کنند.
جلوگیری از حمله عدم پذیرش سرویس
برای اینکه بتونم دقیق‌تر منشا حمله رو تشخیص بدم و جلوش رو بگیرم، ابتدا از دستور زیر، همه ترافیک از نوع pingback رو از لاگ اصلی جدا کرده و توی یک فایل دیگه به اسم wp_attack ریختم.
1 | cat access_log | grep "verifying pingback from" > wp_attack |
در قدم اول و برای مقابله کوتاه مدت در برابر حمله، از دستور زیر ip هایی که بیشترین بازدید رو داشتند، پیدا کردم.
1 | cat wp_attack | awk '{print $1}' | sort -n | uniq -c | sort -nr | head -20 |
همونطور که می‌بینید ۲۰ ردیف اول از ip هایی که بیشترین بازدید رو داشتند جدا کردم. بازدیدها حدود یک هزار تا ۳ هزارتا متغیره.
با دستوری مشابه دستور زیر و از طریق IPtables، این IP ها رو به فایروال اضافه کردم تا همه اتصال‌ها از سمتشون برگشت بخوره.
1 | iptables -I INPUT -s 144.217.71.219 -j DROP |
با مقابله با این IP ها، فشار روی سرور خیلی کم شد و تونستم قبل از شروع موج جدید با IP های متفاوت، با تغییر تنظیمات آپاچی، کلیه ترافیکی که از Pingback سایت‌های وردپرسی استفاده شده بود رو قطع کنم.
با استفاده از ماژول rewrite در آپاچی، User Agent ترافیک ورودی رو چک کرده و در صورتی که واژه‌های WordPress و Pingback from رو داشت، ممنوعش کردم. (اگر سایتم از SSL/TLS استفاده نمی‌کرد و https نداشت، می‌تونستم از فایروال برای برگشت دادن اتصال‌های مشکوک استفاده کنم.)
1 2 3 | RewriteEngine On RewriteCond %{HTTP_USER_AGENT} "^WordPress.*verifying pingback" [NC] RewriteRule . - [F,L] |
نکته اینه که این کار در عملکرد پلاگین Jetpack اختلال ایجاد می‌کنه.
برای تست، خودم سعی کردم یک ترافیک مشابه برای سایتم بفرستم که می‌بینید با خطای ۴۰۳ مواجه شدم.
آمار حمله عدم پذیرش سرویس
بعد از مقابله با حمله، برام جالب بود که آمار این حمله رو داشته باشم.
تعداد کانکشن‌های این حمله عدم پذیرش سرویس تا قبل از مقابله باهاش، به ۲,۲۱۰,۷۲۶ رسیده بود. بیشترین شدت حمله هم به ۲۵۸ کانکشن در ثانیه رسیده بود.
از تصویر بالا می‌بینید که حمله‌کننده‌ها دیروز هم تلاش کرده بودند برای از دسترس خارج کردن بلاگ من اما موفق نشده بودند.
در این حمله بیش از سی و سه هزار IP شرکت داشتند. توزیع تعداد اتصال برای هر IP نشون می‌ده که اکثر شرکت‌کننده‌ها در این حمله، کمتر از ۱۰ اتصال داشتند. یک اوج دومی هم در تعداد اتصال حدود ۵۰ تا دیده می‌شه.
مورد دیگه‌ای که برام جالب بود چک کنم، نسخه وردپرس سایت‌های حمله‌کننده بود. در مجموع ۴۶۷ نسخه مختلف وردپرس در حمله شرکت داشتند. در تصویر می‌بینید که حمله‌کننده‌ها الزاما سایت‌هایی با وردپرس قدیمی و به‌روزنشده نیست. آخرین نسخه کنونی وردپرس ۴.۹.۱ است که دومین رتبه رو در شرکت‌کننده‌های در حمله داشته.
توی لیست بلند بالای نسخه‌های وردپرس، سایت‌های زیادی وجود داشتند که از سال ۲۰۱۳ و ۲۰۱۴ به‌روز نشدند و هنوز از نسخه ۳ استفاده می‌کنند.
وردپرس از نسخه ۳.۹ برای مقابله با سو استفاده از pingback اطلاعاتی رو به User Agent اضافه کرده و IP حمله‌کننده‌های اصلی رو هم به مقصد ترافیک (در این حمله، سایت من) اعلام می‌کنه. با دستور زیر، اون بخش از اطلاعات ترافیک که مربوط به IP اصلی بود رو جدا کردم.
1 | cat wp_attack | awk 'match($0, /from ([^,]+)/) { print substr( $0, RSTART, RLENGTH )}' | awk '{print $2}' | sort -n | uniq -c | sort -nr | head -20 |
هرچند که تعداد IP های شروع کننده حمله ۳۳۷۷ تا بود اما بخش اصلی حمله از سوی مجموعه‌ای IP در روسیه بود.
واسطه حمله نباشیم
برای جلوگیری از سواستفاده از سایتمون برای حمله به سایت دیگران، می‌تونیم این امکان PingBack رو غیرفعال کنیم. روش‌های مختلفی براش وجود داره، از جمله اضافه کردن یک تابع به فایل function.php اما راحت‌ترین کاری که می‌تونم پیشنهاد بدم، نصب پلاگین‌های امنیتی وردپرسه. این جوری با یک تیر چند نشون رو می‌زنید و نکته‌های امنیتی دیگه وردپرس هم اصلاح می‌کنید.
یکی از این پلاگین‌ها، iThemes Security است که پشتیانی خوبی داره و با نسخه‌های جدید وردپرس هم هم‌خوانی داره. پس از نصب و فعال‌سازی، از بخش WordPress Tweaks می‌تونید از گزینه‌های مربوط به XML-RPC برای غیرفعال کردن Pingback استفاده کنید.
همچنین اگر دسترسی تغییر تنظیمات فایروال سرور رو دارید، می‌تونید از لیست‌های به‌روز شده IP های با عملکرد مخرب برای قطع دسترسیشون استفاده کنید و دستور حمله رو دریافت نکنید. به زودی در این مورد می‌نویسم.
