امنیت وردپرس | بلاگ وب‌داده

اقدامات پس از حمله DDoS؛ بازیابی و ایمن‌سازی وردپرس

حمله تمام شده و سایت بالا آمده، اما کار شما تازه شروع می‌شود. در این راهنما قدم‌به‌قدم می‌بینید بعد از یک حمله DDoS چطور سایت وردپرسی را سالم بازیابی و در برابر موج بعدی مقاوم کنید.
اقدامات پس از حمله DDoS مجموعه کارهایی است که درست بعد از فروکش‌کردن یک حمله منع سرویس توزیع‌شده انجام می‌دهید تا سایت وردپرسی را به حالت سالم برگردانید و جلوی تکرار حمله را بگیرید. بازیابی درست به همان اندازه پیشگیری اهمیت دارد؛ چون یک حمله می‌تواند بکاپ‌ها را خراب، منابع سرور را اشغال و مسیرهای نفوذ را باز گذاشته باشد. در ادامه گام‌های تشخیص، بازگردانی، اسکن و سخت‌سازی را با جدول مقایسه، نمونه دستور، معایب صادقانه و پرسش‌های پرتکرار مرور می‌کنیم.
  • اول تثبیت، بعد بررسی: مطمئن شوید حمله واقعاً تمام شده و ترافیک از یک WAF/CDN عبور می‌کند.
  • بازگردانی امن: از آخرین بکاپ سالم بازیابی کنید، نه از نسخه‌ای که در حین حمله گرفته شده.
  • اسکن نفوذ: DDoS گاهی پوششی برای هک است؛ سایت را برای بدافزار و کاربر مشکوک اسکن کنید.
  • سخت‌سازی مسیرها: xmlrpc.php و wp-login.php را محدود و بستر میزبانی را تقویت کنید.
  • واقعیت صادقانه: هیچ اقدام پس از حمله جای یک WAF/CDN همیشه‌فعال را نمی‌گیرد.

پاسخ سریع

بلافاصله پس از حمله: ۱) از پایان حمله مطمئن شوید و ترافیک را پشت یک WAF/CDN ببرید، ۲) از آخرین بکاپ سالم بازگردانی کنید، ۳) سایت را برای بدافزار و کاربر ناشناس اسکن کنید، ۴) مسیرهای پرخطر ورود را محدود کنید. بستر میزبانی امن و پشتیبانی ۲۴ ساعته این مراحل را در وب‌داده ساده‌تر می‌کند.
حتماً این مقاله را باز کرده‌اید چون سایتتان یک بار زیر بار سنگین از دسترس خارج شده و حالا نگرانید که آیا همه‌چیز سالم است و آیا دوباره تکرار می‌شود. خبر خوب این است که با یک روال منظمِ بازیابی، هم می‌توانید از سلامت سایت مطمئن شوید و هم آن را برای دفعه بعد مقاوم‌تر کنید؛ همه را طوری توضیح می‌دهیم که بدون دانش فنی عمیق هم از پسش بربیایید.

اقدامات پس از حمله DDoS از کجا شروع می‌شود؟

حمله DDoS یعنی سیلی از درخواست‌های جعلی که منابع سرور یا پهنای باند را اشباع می‌کند تا سایت برای کاربران واقعی از دسترس خارج شود. برخلاف هک، هدف اصلی DDoS «دزدیدن» چیزی نیست، بلکه «از کار انداختن» است. به همین دلیل بعد از فروکش‌کردن حمله، اغلب داده‌ای دزدیده نشده، اما سه چیز ممکن است آسیب دیده باشد: پایداری سرویس، سلامت فایل‌ها و بکاپ‌ها، و اعتماد کاربران.

یک تشبیه ساده

حمله DDoS مثل این است که صدها نفر همزمان جلوی درِ یک مغازه ازدحام کنند تا مشتری واقعی نتواند وارد شود. وقتی جمعیت پراکنده شد، مغازه دزدی نداده، اما باید بررسی کنید چیزی در هیاهو نشکسته باشد، قفل‌ها سالم باشند و مطمئن شوید همان جمعیت فردا برنمی‌گردد. بازیابی پس از حمله دقیقاً همین بررسی و محکم‌کاری است.
پیش از هر اقدامی باید مطمئن شوید حمله واقعاً تمام شده است. گاهی افت ترافیک موقتی است و مهاجم دوباره شروع می‌کند. علائم پایان حمله شامل بازگشت زمان پاسخ سرور به حالت عادی، کاهش شدید نرخ درخواست در لاگ‌ها و عبور روان کاربران واقعی است. تا وقتی از این موضوع مطمئن نشده‌اید، لایه دفاعی (WAF/CDN) را خاموش نکنید.
نمودار مراحل اقدامات پس از حمله DDoS برای بازیابی سایت وردپرسی

مراحل بازیابی فوری سایت وردپرس پس از حمله

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

گام اول: تایید پایان حمله و تحلیل لاگ

اولین کار، نگاه‌کردن به لاگ دسترسی سرور است تا بفهمید حمله از چه IP‌ها و به چه مسیرهایی بوده و آیا هنوز ادامه دارد. در سرورهای لینوکسی می‌توانید با چند دستور ساده پرتکرارترین IP‌ها و تعداد درخواست به مسیرهای حساس مثل xmlrpc.php و wp-login.php را ببینید:
# بررسی لاگ دسترسی برای یافتن IPهای پرتکرارِ مهاجم (لینوکس)
# ۲۰ IP با بیشترین درخواست را نشان می‌دهد:
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# شمارش درخواست‌ها به xmlrpc.php و wp-login.php
grep -E 'xmlrpc.php|wp-login.php' /var/log/nginx/access.log | wc -l
اگر یک یا چند IP تعداد غیرعادی درخواست داشتند، همان‌ها منبع اصلی حمله بوده‌اند. این اطلاعات هم برای مسدودسازی و هم به‌عنوان شواهد حادثه به کار می‌آید. لاگ‌ها و زمان‌بندی حمله را جایی ذخیره کنید؛ ممکن است برای بررسی با هاست یا مراجع لازم شود.

گام دوم: عبور ترافیک از WAF/CDN و حالت Under Attack

اگر هنوز ترافیک سایت مستقیم به سرور می‌رسد، آن را پشت یک فایروال ابری و شبکه توزیع محتوا (CDN) ببرید. سرویس‌هایی مثل کلادفلر یک «حالت زیر حمله» (Under Attack Mode) دارند که به‌جای نمایش مستقیم صفحه، ابتدا یک بررسی کوتاه مرورگری از بازدیدکننده می‌گیرد و ربات‌ها را فیلتر می‌کند.

نقل‌قول از مستندات رسمی کلادفلر

کلادفلر درباره این حالت می‌گوید: «حالت Under Attack بررسی‌های امنیتی اضافه‌ای برای کاهش حملات DDoS لایه ۷ انجام می‌دهد؛ کاربران معتبر به سایت دسترسی پیدا می‌کنند و ترافیک مشکوک مسدود می‌شود. این حالت به‌عنوان یکی از آخرین راه‌حل‌ها هنگامی که یک دامنه زیر حمله است طراحی شده.» منبع: Under Attack mode — Cloudflare Docs
نکته مهم: پس از فعال‌کردن CDN، مطمئن شوید IP اصلی سرور (origin) دیگر مستقیم از اینترنت در دسترس نیست و فقط از طریق IP‌های ابری قابل‌دسترسی است؛ در غیر این صورت مهاجم می‌تواند فایروال را دور بزند و مستقیم سرور را هدف بگیرد.

گام سوم: تماس با هاست، تغییر IP و بازگردانی از بکاپ

با پشتیبانی میزبان خود تماس بگیرید؛ ارائه‌دهنده می‌تواند ترافیک حمله را در سطح شبکه مسدود (null-route) کند و آخرین بکاپ سالم را در اختیارتان بگذارد. اگر حمله مستقیم به IP سرور بوده، تغییر IP و به‌روزرسانی رکوردهای DNS می‌تواند حمله را متوقف کند. برای بازگردانی، همیشه از نسخه‌ای استفاده کنید که پیش از حمله گرفته شده، نه نسخه‌ای که در حین بحران ذخیره شده است. اگر با فرایند بکاپ و اسنپ‌شات آشنا نیستید، راهنمای بکاپ رایگان و اسنپ‌شات فوری در هاست سی‌پنل کمک‌کننده است.

قبل از بازگردانی، بکاپ لحظه‌ای بگیرید

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

گام چهارم: اسکن بدافزار و بررسی کاربران

گاهی حمله DDoS پوششی برای پنهان‌کردن یک نفوذ واقعی است. بعد از پایداری سایت، با یک افزونه امنیتی معتبر مثل Wordfence یا Sucuri کل سایت را برای بدافزار اسکن کنید. همچنین فهرست کاربران وردپرس را باز کنید و هر حساب مدیرِ ناشناسی را که خودتان نساخته‌اید حذف کنید، و رمز عبور همه مدیران را عوض کنید. این کار مطمئن می‌شود که مهاجم دری برای بازگشت باز نگذاشته باشد.

جدول مقایسه لایه‌های مقابله با DDoS

هر لایه نقش خودش را دارد؛ بازیابی پایدار از ترکیب این‌ها به‌دست می‌آید، نه یک راه‌حل تنها:
لایه دفاعیکجا کار می‌کندجلوی چه چیزی را می‌گیردمحدودیت
WAF و CDN ابریلبه شبکه، پیش از سرورسیل درخواست لایه ۷، ربات‌هانیاز به پیکربندی درست DNS و پنهان‌ماندن origin
حفاظت شبکه هاستسطح دیتاسنتر/شبکهحملات حجمی لایه ۳ و ۴به توان و سیاست ارائه‌دهنده وابسته است
افزونه امنیتی وردپرسداخل وردپرس (PHP)brute force، محدودسازی وروددیرتر از لبه شبکه عمل می‌کند؛ منابع سرور را مصرف می‌کند
سخت‌سازی سروروب‌سرور (Nginx/Apache)سوءاستفاده xmlrpc، سیل ورودنیاز به دسترسی به تنظیمات سرور

جمع‌بندی جدول

مؤثرترین دفاع، یک WAF/CDN ابری در لبه است که ترافیک بد را پیش از رسیدن به سرور فیلتر می‌کند. حفاظت شبکه هاست و سخت‌سازی سرور آن را کامل می‌کنند و افزونه امنیتی لایه آخر داخل وردپرس است. تکیه بر یک لایه به‌تنهایی، همان اشتباهی است که حمله بعدی را ممکن می‌کند.

سخت‌سازی وردپرس برای جلوگیری از حمله بعدی

بازیابی بدون سخت‌سازی، یعنی آماده‌شدن برای حمله بعدی. مهم‌ترین کاری که پس از یک حمله باید انجام دهید، بستن مسیرهایی است که بیشترین سوءاستفاده از آن‌ها می‌شود. در کنار موارد زیر، مرور راهنمای جامع تامین امنیت سرور مجازی برای یک نگاه کامل‌تر توصیه می‌شود.
  • محدود یا بستن xmlrpc.php: ویژگی pingback این فایل بردار شناخته‌شده حملات تقویتی و brute force است.
  • محدودسازی نرخ ورود: با rate limit در سطح وب‌سرور یا افزونه، سیل تلاش‌های ورود خودکار را مهار کنید.
  • به‌روزرسانی کامل: هسته، قالب و افزونه‌ها را به آخرین نسخه برسانید تا آسیب‌پذیری شناخته‌شده‌ای باقی نماند.
  • ورود دومرحله‌ای و رمز قوی: برای همه حساب‌های مدیر، به‌ویژه بعد از تعویض رمزها.
  • مانیتورینگ ترافیک: هشدار برای پیک‌های غیرعادی تا حمله بعدی را زودتر تشخیص دهید.
درباره xmlrpc.php، به‌گفته کارشناسان امنیت وردپرس، بستن در سطح وب‌سرور بر بستن با افزونه ترجیح دارد چون درخواست در چند میکروثانیه و بدون درگیرکردن PHP رد می‌شود. اگر از اپ موبایل وردپرس یا نسخه‌های قدیمی Jetpack استفاده نمی‌کنید، می‌توانید این فایل را کامل ببندید:
# .htaccess: بستن xmlrpc.php برای قطع سوءاستفاده pingback و brute force پس از حمله (Apache 2.4+)
# هشدار: اگر از اپ موبایل وردپرس یا Jetpack قدیمی استفاده می‌کنید این قطعه را اعمال نکنید
<Files "xmlrpc.php">
    Require all denied
</Files>

هشدار سازگاری xmlrpc

بستن کامل xmlrpc.php ممکن است اپ موبایل وردپرس، Jetpack قدیمی و برخی افزونه‌های اتصال بیرونی را مختل کند. اگر به این‌ها نیاز دارید، به‌جای بستن کامل، فقط دسترسی به آن را با فایروال ابری محدود کنید یا نرخ درخواستش را کاهش دهید. منبع: Wordfence — Should You Disable XML-RPC
برای مهار سیل تلاش‌های ورود هم می‌توانید در Nginx نرخ درخواست به صفحه wp-login.php را محدود کنید تا هیچ IP‌ای نتواند در ثانیه ده‌ها بار تلاش ورود کند:
# Nginx: محدودکردن نرخ درخواست به صفحه ورود برای مهار سیل ورود خودکار پس از حمله
# ۱) در بلاک http این zone را تعریف کنید:
limit_req_zone $binary_remote_addr zone=wplogin:10m rate=10r/m;

# ۲) در بلاک server، مسیر ورود را محدود کنید:
location = /wp-login.php {
    limit_req zone=wplogin burst=3 nodelay;
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}
در نهایت، اگر سایت شما مرتب با پیک‌های ترافیکی سنگین روبه‌روست، انتخاب زیرساختی که برای مدیریت این پیک‌ها ساخته شده تفاوت زیادی ایجاد می‌کند؛ در این‌باره مطلب مدیریت ترافیک ورودی با سرور مجازی را ببینید.
تنظیمات سخت‌سازی وردپرس و محدودسازی xmlrpc و wp-login پس از حمله

نقش میزبانی و پشتیبانی وب‌داده در بازیابی

بخش بزرگی از سرعت بازیابی پس از حمله، به بستر میزبانی و کیفیت پشتیبانی برمی‌گردد: اینکه چقدر سریع بکاپ سالم در دسترس است، آیا امکان تغییر IP و مسدودسازی شبکه‌ای وجود دارد، و آیا کسی در لحظه بحران کنارتان هست. ما در وب‌داده تلاش کرده‌ایم این‌ها را در دسترس نگه داریم:
✅ زیرساخت سرورهای نسل جدید HPE (Gen11 و Gen10) برای پایداری زیر بار سنگین.
✅ دیتاسنترهای متنوع در ایران، هلند و آلمان برای انتخاب نزدیک‌ترین و مقاوم‌ترین لوکیشن.
✅ امکان بکاپ و بازگردانی سریع در هاست سی‌پنل برای برگشت به نسخه سالم.
✅ پشتیبانی فنی ۲۴ ساعته برای کمک در مسدودسازی حمله، تغییر IP و اسکن سایت.

تجربه پشتیبانی وب‌داده

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

معایب و محدودیت‌هایی که باید بدانید

صادقانه بگوییم، اقدامات پس از حمله ذاتاً واکنشی هستند و هیچ‌کدام جای پیشگیری را نمی‌گیرند. نخست، بازیابی زمانی انجام می‌شود که خسارت (قطعی و افت اعتماد کاربر) از قبل وارد شده است. دوم، تغییر IP فقط حملاتی را متوقف می‌کند که مستقیم IP را هدف گرفته‌اند؛ اگر مهاجم دامنه را هدف بگیرد و IP جدید هم لو برود، این کار بی‌اثر است. سوم، حالت Under Attack کلادفلر باعث تاخیر چندثانیه‌ای برای همه بازدیدکنندگان و افت موقت تجربه کاربری و سئو می‌شود، پس برای وضعیت دائمی مناسب نیست. چهارم، بستن کامل xmlrpc می‌تواند بعضی سرویس‌ها را مختل کند. جمع‌بندی: این اقدامات برای بازگرداندن سلامت سایت لازم‌اند، اما باید در نهایت به یک استراتژی پیشگیرانه دائمی (WAF/CDN همیشه‌فعال) ختم شوند.

پرسش‌های پرتکرار

جمع‌بندی و چک‌لیست بازیابی

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

چک‌لیست سریع بازیابی

✅ از پایان حمله مطمئن شوید و لاگ دسترسی را برای یافتن IP و مسیرهای حمله تحلیل کنید.
✅ ترافیک را پشت WAF/CDN ببرید و IP اصلی سرور را پنهان نگه دارید.
✅ در صورت نیاز با هاست تماس بگیرید، IP را تغییر دهید و از بکاپِ پیش از حمله بازگردانی کنید.
✅ سایت را برای بدافزار اسکن و کاربران مدیر ناشناس را حذف کنید و رمزها را عوض کنید.
✅ xmlrpc و wp-login را محدود، و هسته/قالب/افزونه‌ها را به‌روز کنید.
✅ برای آینده، یک دفاع چندلایه و همیشه‌فعال برقرار و ترافیک را مانیتور کنید.
در صورتی که سوالی داشتید می‌توانید در بخش نظرات با ما در ارتباط باشید.
منابع: راهنمای رسمی Under Attack mode و Respond to DDoS attacks در مستندات Cloudflare، و تحلیل Should You Disable XML-RPC on WordPress در وبلاگ Wordfence.
به اشتراک بگذارید
وب داده
وب داده

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

مقاله‌ها: 47

نوشته‌ای مرتبط

پاسخی بگذارید

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