جدید!
سرور ابری ساعتی فعال شد. ۱۰۰ هزار تومان اعتبار هدیه بگیرید
به اشتراک بگذارید
امنیت وردپرس | بلاگ وبداده
اقدامات پس از حمله DDoS؛ بازیابی و ایمنسازی وردپرس
حمله تمام شده و سایت بالا آمده، اما کار شما تازه شروع میشود. در این راهنما قدمبهقدم میبینید بعد از یک حمله DDoS چطور سایت وردپرسی را سالم بازیابی و در برابر موج بعدی مقاوم کنید.
اقدامات پس از حمله DDoS مجموعه کارهایی است که درست بعد از فروکشکردن یک حمله منع سرویس توزیعشده انجام میدهید تا سایت وردپرسی را به حالت سالم برگردانید و جلوی تکرار حمله را بگیرید. بازیابی درست به همان اندازه پیشگیری اهمیت دارد؛ چون یک حمله میتواند بکاپها را خراب، منابع سرور را اشغال و مسیرهای نفوذ را باز گذاشته باشد. در ادامه گامهای تشخیص، بازگردانی، اسکن و سختسازی را با جدول مقایسه، نمونه دستور، معایب صادقانه و پرسشهای پرتکرار مرور میکنیم.
- اول تثبیت، بعد بررسی: مطمئن شوید حمله واقعاً تمام شده و ترافیک از یک WAF/CDN عبور میکند.
- بازگردانی امن: از آخرین بکاپ سالم بازیابی کنید، نه از نسخهای که در حین حمله گرفته شده.
- اسکن نفوذ: DDoS گاهی پوششی برای هک است؛ سایت را برای بدافزار و کاربر مشکوک اسکن کنید.
- سختسازی مسیرها:
xmlrpc.phpوwp-login.phpرا محدود و بستر میزبانی را تقویت کنید. - واقعیت صادقانه: هیچ اقدام پس از حمله جای یک WAF/CDN همیشهفعال را نمیگیرد.
پاسخ سریع
بلافاصله پس از حمله: ۱) از پایان حمله مطمئن شوید و ترافیک را پشت یک WAF/CDN ببرید، ۲) از آخرین بکاپ سالم بازگردانی کنید، ۳) سایت را برای بدافزار و کاربر ناشناس اسکن کنید، ۴) مسیرهای پرخطر ورود را محدود کنید. بستر میزبانی امن و پشتیبانی ۲۴ ساعته این مراحل را در وبداده سادهتر میکند.
حتماً این مقاله را باز کردهاید چون سایتتان یک بار زیر بار سنگین از دسترس خارج شده و حالا نگرانید که آیا همهچیز سالم است و آیا دوباره تکرار میشود. خبر خوب این است که با یک روال منظمِ بازیابی، هم میتوانید از سلامت سایت مطمئن شوید و هم آن را برای دفعه بعد مقاومتر کنید؛ همه را طوری توضیح میدهیم که بدون دانش فنی عمیق هم از پسش بربیایید.
اقدامات پس از حمله DDoS از کجا شروع میشود؟
حمله DDoS یعنی سیلی از درخواستهای جعلی که منابع سرور یا پهنای باند را اشباع میکند تا سایت برای کاربران واقعی از دسترس خارج شود. برخلاف هک، هدف اصلی DDoS «دزدیدن» چیزی نیست، بلکه «از کار انداختن» است. به همین دلیل بعد از فروکشکردن حمله، اغلب دادهای دزدیده نشده، اما سه چیز ممکن است آسیب دیده باشد: پایداری سرویس، سلامت فایلها و بکاپها، و اعتماد کاربران.
یک تشبیه ساده
حمله DDoS مثل این است که صدها نفر همزمان جلوی درِ یک مغازه ازدحام کنند تا مشتری واقعی نتواند وارد شود. وقتی جمعیت پراکنده شد، مغازه دزدی نداده، اما باید بررسی کنید چیزی در هیاهو نشکسته باشد، قفلها سالم باشند و مطمئن شوید همان جمعیت فردا برنمیگردد. بازیابی پس از حمله دقیقاً همین بررسی و محکمکاری است.
پیش از هر اقدامی باید مطمئن شوید حمله واقعاً تمام شده است. گاهی افت ترافیک موقتی است و مهاجم دوباره شروع میکند. علائم پایان حمله شامل بازگشت زمان پاسخ سرور به حالت عادی، کاهش شدید نرخ درخواست در لاگها و عبور روان کاربران واقعی است. تا وقتی از این موضوع مطمئن نشدهاید، لایه دفاعی (WAF/CDN) را خاموش نکنید.
مراحل بازیابی فوری سایت وردپرس پس از حمله
بازیابی را با نظم پیش ببرید؛ هر مرحله پیشنیاز مرحله بعد است. عجله در بازگردانی بدون اطمینان از پایان حمله، فقط چرخه را تکرار میکند.
گام اول: تایید پایان حمله و تحلیل لاگ
اولین کار، نگاهکردن به لاگ دسترسی سرور است تا بفهمید حمله از چه 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;
}در نهایت، اگر سایت شما مرتب با پیکهای ترافیکی سنگین روبهروست، انتخاب زیرساختی که برای مدیریت این پیکها ساخته شده تفاوت زیادی ایجاد میکند؛ در اینباره مطلب مدیریت ترافیک ورودی با سرور مجازی را ببینید.
نقش میزبانی و پشتیبانی وبداده در بازیابی
بخش بزرگی از سرعت بازیابی پس از حمله، به بستر میزبانی و کیفیت پشتیبانی برمیگردد: اینکه چقدر سریع بکاپ سالم در دسترس است، آیا امکان تغییر IP و مسدودسازی شبکهای وجود دارد، و آیا کسی در لحظه بحران کنارتان هست. ما در وبداده تلاش کردهایم اینها را در دسترس نگه داریم:
✅ زیرساخت سرورهای نسل جدید HPE (Gen11 و Gen10) برای پایداری زیر بار سنگین.
✅ دیتاسنترهای متنوع در ایران، هلند و آلمان برای انتخاب نزدیکترین و مقاومترین لوکیشن.
✅ امکان بکاپ و بازگردانی سریع در هاست سیپنل برای برگشت به نسخه سالم.
✅ پشتیبانی فنی ۲۴ ساعته برای کمک در مسدودسازی حمله، تغییر IP و اسکن سایت.
✅ دیتاسنترهای متنوع در ایران، هلند و آلمان برای انتخاب نزدیکترین و مقاومترین لوکیشن.
✅ امکان بکاپ و بازگردانی سریع در هاست سیپنل برای برگشت به نسخه سالم.
✅ پشتیبانی فنی ۲۴ ساعته برای کمک در مسدودسازی حمله، تغییر IP و اسکن سایت.
تجربه پشتیبانی وبداده
در تیم پشتیبانی وبداده بارها پیش آمده که سایت مشتری زیر بار غیرعادی از دسترس خارج شده است. روال ما ثابت است: اول با تحلیل لاگ منبع ترافیک را مشخص میکنیم، سپس ترافیک بد را در سطح شبکه محدود و در صورت نیاز IP را تغییر میدهیم، و در پایان سایت را از آخرین بکاپ سالم بازمیگردانیم. همین روال چندلایه، تفاوت میان چند دقیقه و چند ساعت قطعی را رقم میزند.
اگر بهدنبال بستری مطمئن برای وردپرس هستید که در برابر پیک و حمله پایدارتر باشد، میتوانید هاست سیپنل وبداده را ببینید و برای تصویر کاملتر امنیت، راهنمای تامین امنیت سرور را مرور کنید.
معایب و محدودیتهایی که باید بدانید
صادقانه بگوییم، اقدامات پس از حمله ذاتاً واکنشی هستند و هیچکدام جای پیشگیری را نمیگیرند. نخست، بازیابی زمانی انجام میشود که خسارت (قطعی و افت اعتماد کاربر) از قبل وارد شده است. دوم، تغییر IP فقط حملاتی را متوقف میکند که مستقیم IP را هدف گرفتهاند؛ اگر مهاجم دامنه را هدف بگیرد و IP جدید هم لو برود، این کار بیاثر است. سوم، حالت Under Attack کلادفلر باعث تاخیر چندثانیهای برای همه بازدیدکنندگان و افت موقت تجربه کاربری و سئو میشود، پس برای وضعیت دائمی مناسب نیست. چهارم، بستن کامل xmlrpc میتواند بعضی سرویسها را مختل کند. جمعبندی: این اقدامات برای بازگرداندن سلامت سایت لازماند، اما باید در نهایت به یک استراتژی پیشگیرانه دائمی (WAF/CDN همیشهفعال) ختم شوند.
پرسشهای پرتکرار
از کجا بفهمم حمله DDoS واقعاً تمام شده است؟
به لاگ دسترسی سرور و زمان پاسخ سایت نگاه کنید. اگر نرخ درخواست به حالت عادی برگشته، زمان پاسخ سرور کوتاه شده و کاربران واقعی روان وارد میشوند، حمله فروکش کرده است. تا وقتی از این موضوع مطمئن نشدهاید، لایه دفاعی مثل حالت Under Attack را خاموش نکنید.
آیا حمله DDoS به معنی هکشدن سایت من است؟
لزوماً نه. هدف DDoS از کار انداختن سرویس است، نه سرقت داده. اما گاهی مهاجمان از شلوغی حمله بهعنوان پوشش برای نفوذ استفاده میکنند. برای اطمینان، بعد از حمله حتماً سایت را برای بدافزار اسکن کنید و کاربران مدیر ناشناس را بررسی و حذف کنید.
بعد از حمله باید حتماً از بکاپ بازگردانی کنم؟
اگر سایت سالم بالا آمده و اسکن بدافزار چیزی نشان نداد، بازگردانی الزامی نیست. اما اگر فایلها آسیب دیده، بدافزار پیدا شده یا سایت ناپایدار است، بازگردانی از آخرین بکاپِ پیش از حمله امنترین راه است. همیشه پیش از بازگردانی، از وضعیت فعلی هم یک نسخه بگیرید.
تغییر IP سرور واقعاً حمله را متوقف میکند؟
فقط زمانی که حمله مستقیم به IP سرور نشانه رفته باشد. با تغییر IP و بهروزرسانی DNS، ترافیک حمله به آدرس قدیمی میرود و سایت آزاد میشود. اما اگر مهاجم دامنه را هدف بگیرد یا IP جدید لو برود، این روش کارایی ندارد و باید به فایروال ابری تکیه کنید.
بستن xmlrpc.php به سایتم آسیب میزند؟
برای اکثر سایتها خیر. اما اگر از اپ موبایل وردپرس، Jetpack قدیمی یا افزونهای که از این فایل استفاده میکند بهره میبرید، ممکن است آن سرویسها مختل شوند. در این حالت بهجای بستن کامل، دسترسی را با فایروال ابری محدود یا نرخ درخواست را کم کنید.
افزونه امنیتی برای مقابله با DDoS کافی است؟
بهتنهایی نه. افزونههای امنیتی مثل Wordfence داخل وردپرس و با PHP کار میکنند، یعنی درخواست بد قبلاً به سرور رسیده و منابع مصرف شده است. برای مهار سیل حجیم، لایه لبه (WAF/CDN ابری) که پیش از رسیدن به سرور فیلتر میکند بسیار مؤثرتر است؛ افزونه مکمل خوبی برای لایه آخر است.
حالت Under Attack کلادفلر را همیشه روشن نگه دارم؟
خیر. این حالت برای بازدیدکنندگان تاخیر چندثانیهای ایجاد میکند و تجربه کاربری و سئو را موقتاً افت میدهد؛ خود کلادفلر آن را یکی از آخرین راهحلها هنگام حمله میداند. بعد از پایان حمله آن را خاموش کنید و به تنظیمات امنیتی معمول و قواعد هدفمند برگردید.
چطور جلوی حمله بعدی را بگیرم؟
با یک استراتژی چندلایه دائمی: فایروال و CDN ابری همیشهفعال، پنهان نگهداشتن IP اصلی سرور، سختسازی مسیرهای ورود و xmlrpc، بهروزرسانی مرتب، رمز قوی و ورود دومرحلهای، و انتخاب میزبانی با حفاظت شبکهای مناسب. بازیابی واکنشی است؛ پیشگیری چندلایه راهحل بلندمدت است.
بعد از حمله چه چیزهایی را بهعنوان شواهد نگه دارم؟
لاگهای دسترسی سرور در بازه حمله، زمان دقیق شروع و پایان، نمونهای از IPها و مسیرهای پرتکرار، و هر پیام یا هشداری که از هاست یا فایروال دریافت کردهاید. این شواهد برای بررسی با پشتیبانی هاست و جلوگیری از تکرار حمله ارزشمندند.
جمعبندی و چکلیست بازیابی
دیدیم که کار واقعی بعد از فروکشکردن حمله شروع میشود. مسیر درست این است: اول از پایان حمله مطمئن شوید و لاگها را تحلیل کنید، ترافیک را پشت یک WAF/CDN ببرید، از آخرین بکاپ سالم بازگردانی کنید، سایت را برای بدافزار و کاربر مشکوک اسکن کنید و در پایان مسیرهای پرخطر را سختسازی کنید. مهمترین پیام را فراموش نکنید: بازیابی، سلامت امروز سایت را برمیگرداند، اما تنها یک دفاع چندلایه و همیشهفعال است که جلوی حمله فردا را میگیرد.
چکلیست سریع بازیابی
✅ از پایان حمله مطمئن شوید و لاگ دسترسی را برای یافتن IP و مسیرهای حمله تحلیل کنید.
✅ ترافیک را پشت WAF/CDN ببرید و IP اصلی سرور را پنهان نگه دارید.
✅ در صورت نیاز با هاست تماس بگیرید، IP را تغییر دهید و از بکاپِ پیش از حمله بازگردانی کنید.
✅ سایت را برای بدافزار اسکن و کاربران مدیر ناشناس را حذف کنید و رمزها را عوض کنید.
✅ xmlrpc و wp-login را محدود، و هسته/قالب/افزونهها را بهروز کنید.
✅ برای آینده، یک دفاع چندلایه و همیشهفعال برقرار و ترافیک را مانیتور کنید.
✅ ترافیک را پشت WAF/CDN ببرید و IP اصلی سرور را پنهان نگه دارید.
✅ در صورت نیاز با هاست تماس بگیرید، IP را تغییر دهید و از بکاپِ پیش از حمله بازگردانی کنید.
✅ سایت را برای بدافزار اسکن و کاربران مدیر ناشناس را حذف کنید و رمزها را عوض کنید.
✅ xmlrpc و wp-login را محدود، و هسته/قالب/افزونهها را بهروز کنید.
✅ برای آینده، یک دفاع چندلایه و همیشهفعال برقرار و ترافیک را مانیتور کنید.
در صورتی که سوالی داشتید میتوانید در بخش نظرات با ما در ارتباط باشید.
منابع: راهنمای رسمی Under Attack mode و Respond to DDoS attacks در مستندات Cloudflare، و تحلیل Should You Disable XML-RPC on WordPress در وبلاگ Wordfence.
