غیرفعال‌سازی XML-RPC در وردپرس: سریع‌ترین راه مقابله با حملات بروت فورس

غیرفعال‌سازی XML-RPC در وردپرس به معنای جلوگیری از دریافت درخواست‌های راه دور به فایل xmlrpc.php سایت شما است که به سرعت می‌تواند حملات brute force، سوءاستفاده‌های pingback و ترافیک غیرضروری ربات‌ها را کاهش دهد. اگر از Jetpack، اپلیکیشن موبایل وردپرس، ابزارهای قدیمی ارسال از راه دور یا هر نوع یکپارچه‌سازی خاصی که از XML-RPC استفاده می‌کند بهره نمی‌برید، غیرفعال کردن XML-RPC یک گام امن و کاربردی برای افزایش امنیت اکثر سایت‌های وردپرسی به شمار می‌آید. بهترین روش، مسدودسازی درخواست‌ها در سطح سرور قبل از اجرای وردپرس است؛ یعنی قطع دسترسی به xmlrpc.php با استفاده از قوانین Apache، LiteSpeed، Nginx یا فایروال وب (WAF) معمولاً نسبت به استفاده از افزونه عملکرد بهتری دارد.

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

XML-RPC چیست و در وردپرس چه کاربردی دارد؟

XML-RPC یک پروتکل قدیمی ارتباط از راه دور است که به سیستم‌های مختلف اجازه می‌دهد با ارسال داده به فرمت XML از طریق HTTP با یکدیگر ارتباط برقرار کنند. در وردپرس، این عملکرد معمولاً از طریق فایل xmlrpc.php در پوشه ریشه اجرا می‌شود. این فایل در گذشته برای ارسال نوشته از طریق اپلیکیشن موبایل وردپرس، مدیریت نظرات از راه دور، عملکرد pingback و تعامل با برخی سرویس‌های شخص ثالث استفاده می‌شد.

با پیشرفت اکوسیستم وردپرس و رواج REST API، اهمیت XML-RPC کاهش یافته است، اما فایل xmlrpc.php هنوز در بسیاری از سایت‌ها قابل دسترسی است. این موضوع به معنی وجود یک نقطه ورودی شناخته شده و قابل شناسایی برای مهاجمان است که به راحتی توسط ربات‌ها هدف قرار می‌گیرد. حتی اگر دامنه شما تازه ثبت شده باشد، ربات‌ها معمولاً در عرض چند دقیقه آدرس xmlrpc.php را جستجو می‌کنند. بنابراین، هنگام راه‌اندازی سایت جدید، اهمیت ایجاد یک پایه امنیتی از ابتدا با استفاده از بررسی دامنه برای دامنه تازه بسیار بالاست.

در چه شرایطی XML-RPC ممکن است ضروری باشد؟

XML-RPC برای همه سایت‌ها غیرضروری نیست. برخی امکانات قدیمی Jetpack، برخی عملیات اپلیکیشن موبایل وردپرس، سرویس‌های اتوماسیون یا ویرایشگرهای قدیمی وبلاگ ممکن است به XML-RPC وابسته باشند. همچنین، برخی یکپارچه‌سازی‌های سفارشی برای ارسال محتوا یا دریافت داده از راه دور ممکن است از xmlrpc.php استفاده کنند. بنابراین قبل از غیرفعال کردن باید جریان کاری سایت خود را بررسی کنید.

یک راه ساده برای بررسی این است که اگر محتوای سایت را فقط از طریق پنل مدیریت وردپرس وارد می‌کنید، از Jetpack استفاده نمی‌کنید، از اپلیکیشن موبایل وردپرس مطلب منتشر نمی‌کنید و توسعه‌دهنده شما هم یکپارچه‌سازی XML-RPC خاصی پیاده نکرده است، به احتمال زیاد نیازی به XML-RPC ندارید. سایت‌های شرکتی، وبلاگ‌ها، سایت‌های کاتالوگی، کسب‌وکارهای کوچک و بسیاری از فروشگاه‌های ووکامرس معمولاً بدون فعال بودن XML-RPC به خوبی کار می‌کنند. با این حال، اگر فرآیندهای حیاتی مانند پرداخت یا ادغام با سرویس‌های حمل و نقل دارید، بهتر است این تغییر را در ساعاتی با ترافیک پایین تست کنید.

چرا XML-RPC در وردپرس برای حملات بروت فورس خطرناک است؟

حملات brute force یعنی تلاش‌های مکرر و خودکار برای حدس زدن نام کاربری و رمز عبور. در وردپرس این تلاش‌ها معمولاً از طریق wp-login.php انجام می‌شود؛ ولی XML-RPC مسیر ساده‌تر و کارآمدتری برای مهاجم فراهم می‌کند. برخی متدهای XML-RPC اجازه می‌دهند چندین تلاش ورود در یک درخواست HTTP واحد ارسال شود. به‌خصوص قابلیت system.multicall به مهاجم اجازه می‌دهد صدها تلاش را در قالب درخواست‌های کمتر و کم‌سر و صدا ارسال کند.

برای مثال، ارسال ۵۰۰ تلاش ورود از طریق wp-login.php به معنای ۵۰۰ درخواست جداگانه است، اما همان تعداد تلاش از طریق XML-RPC می‌تواند با تعداد کمتری درخواست فشرده شود. این موضوع باعث می‌شود افزونه‌های امنیتی و سیستم‌های پایش ساده دیرتر متوجه حمله شوند. در نتیجه مصرف پردازنده افزایش یافته، فرآیندهای PHP مشغول می‌شوند، پایگاه داده با درخواست‌های غیرضروری درگیر می‌شود و کاربران واقعی پاسخ کندتری دریافت می‌کنند. در محیط‌های میزبانی اشتراکی، این نه تنها ریسک امنیتی بلکه یک مشکل عملکردی و مصرف منابع است.

یکی دیگر از ریسک‌های XML-RPC، سوءاستفاده از مکانیزم pingback است. این مکانیزم برای اطلاع دادن به سایت مبدا از لینک‌های داده شده طراحی شده، اما می‌تواند برای تولید ترافیک DDoS یا هدف‌گیری سایت‌های ثالث مورد سوءاستفاده قرار گیرد. بنابراین غیرفعال کردن XML-RPC تنها باعث کاهش تلاش‌های ورود نمی‌شود، بلکه احتمال سو استفاده‌های ناشی از pingback را نیز کاهش می‌دهد.

جدول مقایسه روش‌های غیرفعال‌سازی XML-RPC

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

پیش از شروع: چک‌لیست کنترل

در تنظیمات امنیتی اصل مهم اندازه‌گیری و داشتن برنامه بازگشت است. خاموش کردن XML-RPC معمولاً بی‌خطر است ولی هر تغییر باید با دقت و بدون آزمون کورکورانه در سایت زنده انجام شود. چک‌لیست زیر احتمال بروز خطا را کاهش می‌دهد.

• از فایل‌ها و پایگاه داده نسخه پشتیبان جدید (حداکثر ۲۴ ساعت گذشته) داشته باشید. قبل از به‌روزرسانی وردپرس، تنظیمات امنیتی یا تغییر افزونه، بکاپ ضروری است.
• بررسی کنید که آیا از Jetpack، اپ موبایل وردپرس، ابزار ارسال از راه دور یا یکپارچه‌سازی خاص استفاده می‌کنید یا نه.
• تعداد درخواست‌های xmlrpc.php را در لاگ‌های دسترسی بررسی کنید. اگر در هر دقیقه ده‌ها یا صدها درخواست هست، ممکن است تحت حمله باشید.
• تغییرات را در ساعات کم ترافیک انجام دهید. به‌خصوص در فروشگاه‌های ووکامرس، بخش سبد خرید، پرداخت و ثبت نام را بعد از تغییر تست کنید.
• یک راه بازگشت داشته باشید. امکان غیرفعال کردن قانون یا حذف آن با استفاده از مدیریت فایل، FTP یا SSH آماده باشد.

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

روش ۱: غیرفعال‌سازی XML-RPC با .htaccess در Apache یا LiteSpeed

در سایت‌هایی که از Apache یا LiteSpeed استفاده می‌کنند، رایج‌ترین روش افزودن قانون مسدودسازی xmlrpc.php در فایل .htaccess واقع در پوشه ریشه سایت است. از آنجا که LiteSpeed از قوانین .htaccess سازگار با Apache پشتیبانی می‌کند، این روش در بسیاری از میزبانی‌ها قابل استفاده است. بزرگ‌ترین مزیت این روش، رد درخواست‌ها پیش از بارگذاری هسته وردپرس است.

مراحل گام به گام

• وارد کنترل پنل میزبانی خود شده و فایل منیجر را باز کنید یا با FTP به پوشه public_html متصل شوید.
• فایل .htaccess را پیدا کرده و از آن نسخه پشتیبان بگیرید. اگر فایل نمایش داده نمی‌شود، گزینه نمایش فایل‌های مخفی را فعال کنید.
• بدون حذف قوانین مرتبط با وردپرس، در بالای فایل قانون مسدودسازی XML-RPC را اضافه کنید.
• قانون باید به گونه‌ای باشد که تمام دسترسی‌ها به xmlrpc.php را مسدود کند.
• فایل را ذخیره کنید و سپس در مرورگر آدرس yourdomain.com/xmlrpc.php را بررسی نمایید.

در محیط Apache 2.4 و LiteSpeed معمولاً از دستور Require all denied برای فایل xmlrpc.php استفاده می‌شود. در Apache 2.2 قدیمی‌تر معمولاً Deny from all به کار می‌رود، اما توصیه می‌شود از نسخه‌های به‌روز سرور استفاده کنید. اگر هنوز از Apache قدیمی استفاده می‌کنید، این موضوع علاوه بر XML-RPC، ریسک‌های امنیتی دیگری نیز دارد.

در صورت موفقیت، آدرس xmlrpc.php باید پیغام ۴۰۳ Forbidden، ۴۰۴ Not Found یا پیام مشابهی برگرداند و هرگز نباید متنی مانند XML-RPC server accepts POST requests نمایش داده شود؛ در این صورت فایل هنوز قابل دسترسی است.

روش ۲: مسدودسازی XML-RPC در Nginx

در Nginx فایل .htaccess کار نمی‌کند زیرا این وب‌سرور قوانین دایرکتوری محور را نمی‌خواند. بنابراین باید قانون در تنظیمات server block سایت اضافه شود. اگر از میزبانی مدیریت شده استفاده می‌کنید و به این تنظیمات دسترسی ندارید، بهتر است از تیم پشتیبانی میزبانی درخواست کنید که دسترسی به xmlrpc.php را مسدود کنند.

در Nginx معمولاً از بلاک location = /xmlrpc.php برای رد درخواست یا بازگرداندن پاسخ ۴۰۳ یا ۴۰۴ استفاده می‌شود. از نظر امنیت، پاسخ ۴۰۳ ممنوع به شکل واضح دسترسی را رد می‌کند، اما پاسخ ۴۰۴ فایل را غیرموجود جلوه می‌دهد که برای کاهش اطلاعات به مهاجمین بهتر است. پس از افزودن قانون، باید پیکربندی Nginx تست و سرویس مجدداً راه‌اندازی شود. توجه داشته باشید هر اشتباه در فایل پیکربندی می‌تواند باعث از دسترس خارج شدن کل سایت شود.

اگر VPS یا سرور اختصاصی Nginx دارید، بعد از تغییرات لاگ‌های دسترسی را بررسی کنید تا ببینید درخواست‌های xmlrpc.php با کد ۴۰۳ یا ۴۰۴ پاسخ داده می‌شوند یا خیر. در صورت ادامه تلاش‌های مکرر از یک یا چند IP، می‌توانید از ابزارهای fail2ban، محدودیت نرخ درخواست یا قوانین WAF برای لایه دوم دفاع استفاده کنید. برای راهنمایی‌های جامع‌تر در مدیریت سرور به امنیّت سرور VPS مراجعه کنید.

روش ۳: غیرفعال‌سازی XML-RPC با افزونه‌های امنیتی

برای کاربرانی که تمایلی به دستکاری فایل‌های سرور ندارند، افزونه‌های امنیتی راهکاری سریع و ساده هستند. افزونه‌هایی مانند Wordfence، Solid Security و All-In-One Security معمولاً قابلیت غیرفعال کردن XML-RPC، خاموش کردن pingback یا مسدودسازی تلاش‌های ورود از طریق XML-RPC را دارند. این روش برای وبلاگ‌های کوچک و سایت‌های شرکتی پایه مناسب است.

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

نکات مهم هنگام استفاده از افزونه

• افزونه امنیتی را فقط از مخزن رسمی وردپرس یا سایت رسمی سازنده دانلود کنید.
• از افزونه‌های بدون به‌روزرسانی طولانی‌مدت استفاده نکنید. نگهداری و سازگاری در سال ۲۰۲۶ نشانه امنیت است.
• چند افزونه امنیتی برای یک کار مشابه نصب نکنید؛ تداخل ممکن است مشکلات ورود، کش و دسترسی به فایل ایجاد کند.
• بعد از تنظیمات XML-RPC، صفحه سلامت سایت، فرم‌ها، ورود کاربران و فرآیند پرداخت را تست کنید.
• لاگ‌های افزونه را به صورت منظم بررسی کنید و در صورت حملات مکرر بلاک IP یا افزودن قوانین WAF را در نظر بگیرید.

روش ۴: مسدودسازی با WAF، CDN و فایروال میزبانی

فایروال برنامه وب (WAF) یکی از مؤثرترین لایه‌ها برای فیلتر کردن درخواست‌های مخرب پیش از رسیدن به برنامه است. سرویس‌هایی مانند Cloudflare می‌توانند درخواست‌های xmlrpc.php را در لایه CDN فیلتر کنند. همچنین قوانین ModSecurity یا WAF اختصاصی میزبانی نیز همین عملکرد را دارند. این لایه برای قطع درخواست‌های رباتی بسیار موثر است.

در قانون WAF باید دقت شود که فقط درخواست‌هایی که URI آنها حاوی xmlrpc.php است هدف قرار گیرد و یا درخواست مسدود یا به چالش کشیده شود. اگر به XML-RPC نیاز ندارید، بلاک کامل بهترین گزینه است. در صورت نیاز محدود، می‌توان دسترسی را فقط به IPهای خاص مجاز کرد. به عنوان مثال اگر سرویس اتوماسیون با IP ثابت دارید، آن IP در لیست سفید قرار می‌گیرد و بقیه درخواست‌ها رد می‌شوند. این روش تعادلی میان امنیت و دسترسی مناسب ایجاد می‌کند.

استفاده از WAF همراه با HTTPS معنادارتر است، زیرا سایت‌های بدون HTTPS در معرض افشای اطلاعات ورود قرار دارند. بنابراین علاوه بر غیرفعال‌سازی XML-RPC باید کل سایت را روی HTTPS اجرا کنید، هدرهای امنیتی مانند HSTS را فعال نمایید و مدت اعتبار گواهی را پیگیری کنید. در این زمینه گواهی‌نامه SSL و نصب SSL رایگان منابع مفیدی هستند.

چگونه پس از غیرفعال‌سازی XML-RPC تست کنیم؟

بعد از اعمال تغییر، تنها باز شدن سایت کافی نیست. باید چک کنید که XML-RPC واقعاً غیرفعال شده، سیستم ورود بدون مشکل کار می‌کند، عملکردهای کاربری اصلی مختل نشده‌اند و لاگ‌ها نتایج مورد انتظار را نشان می‌دهند. روند تست زیر ساده و کارآمد است.

• آدرس yourdomain.com/xmlrpc.php را در مرورگر باز کنید. انتظار می‌رود پاسخ ۴۰۳، ۴۰۴ یا صفحه خالی دریافت کنید و نباید متن XML-RPC server accepts POST requests نمایش داده شود.
• با حساب کاربری عادی وارد پنل مدیریت وردپرس شوید و بررسی کنید که صفحه ورود مستقل از XML-RPC کار می‌کند.
• فرم تماس، فرم نظرات، ثبت نام و مراحل پرداخت ووکامرس را تست کنید.
• کد وضعیت پاسخ درخواست‌های xmlrpc.php در لاگ‌های سرور را بررسی کنید. کد ۴۰۳ یا ۴۰۴ نشان دهنده عملکرد صحیح قانون است.
• اگر افزونه امنیتی دارید، لاگ رویدادها را بررسی و کاهش یا مسدود شدن تلاش‌های رباتی را مشاهده کنید.

برای تست تخصصی‌تر می‌توانید درخواست POST از طریق ترمینال ارسال کنید، اما برای اکثر مالکان سایت بررسی مرورگر و لاگ کافی است. اگر پس از تغییر اتصال Jetpack قطع شد، اپ موبایل نتوانست مطلب ارسال کند یا یکپارچه‌سازی خطا داد، یعنی سایت به XML-RPC نیاز دارد. در این شرایط بهتر است به جای غیرفعال‌سازی کامل، دسترسی بر اساس IP یا محدودیت نرخ درخواست در نظر گرفته شود.

آیا غیرفعال کردن XML-RPC کافی است؟ اقدامات امنیتی مکمل

غیرفعال‌سازی XML-RPC یک گام سریع و مؤثر برای مقابله با حملات brute force است اما به تنهایی امنیت کامل را تضمین نمی‌کند. مهاجمین همچنان می‌توانند از طریق wp-login.php، REST API، افزونه‌های ضعیف، قالب‌های قدیمی یا رمزهای لو رفته حمله کنند. بنابراین باید امنیت وردپرس را به صورت چندلایه در نظر گرفت.

اقدامات ضروری

• استفاده از رمزهای قوی و نام کاربری یکتا. استفاده نکردن از admin به عنوان نام کاربری هنوز یک اقدام ساده اما مؤثر است.
• فعال‌سازی تأیید هویت دو مرحله‌ای (2FA). افزودن 2FA برای حساب‌های مدیریتی به شدت ریسک نشت رمز را کاهش می‌دهد.
• محدود کردن تعداد تلاش‌های ورود. برای wp-login.php از محدودیت نرخ یا افزونه‌های امنیتی استفاده کنید.
• به‌روزرسانی مداوم هسته وردپرس، افزونه‌ها و قالب‌ها. افزونه‌های قدیمی بیشترین عامل نفوذ هستند.
• حذف افزونه‌ها و قالب‌های استفاده نشده. افزونه‌های غیرفعال قدیمی می‌توانند ریسک ایجاد کنند.
• بررسی دسترسی‌های فایل و پوشه‌ها. مجوزهای غیرضروری نوشتن می‌توانند اجازه آپلود فایل مخرب دهند.
• تهیه نسخه پشتیبان منظم و آزمایش بازگردانی. نسخه پشتیبان بدون تست به معنای فرضیه است.
• استفاده از زیرساخت میزبانی قابل اعتماد با حساب ایزوله، نسخه PHP به‌روز، فایروال وب و پشتیبانی بکاپ.

برای مثال اگر فقط XML-RPC را ببندید ولی رمز مدیر سایت همچنان ۱۲۳۴۵۶ باشد، ضعیف‌ترین حلقه امنیتی باز می‌ماند. از طرف دیگر ترکیب رمز قوی، 2FA، به‌روزرسانی، WAF و هاست امن، بخش عمده‌ای از حملات رباتی را بی‌اثر می‌کند. این رویکرد در سئوی ۲۰۲۶ هم اهمیت دارد زیرا سایت‌های ناامن ممکن است به خاطر هدایت‌های مخرب، تولید صفحات اسپم و آلودگی ایندکس، رتبه ارگانیک خود را از دست بدهند.

تأثیر غیرفعال‌سازی XML-RPC بر عملکرد و سئو

حملات XML-RPC به طور مستقیم عامل رتبه‌بندی نیستند اما اثرات غیرمستقیم زیادی دارند. ترافیک رباتی بالا منابع سرور را مصرف می‌کند، زمان پاسخ‌دهی صفحات را افزایش می‌دهد، امتیاز Core Web Vitals را کاهش می‌دهد و تجربه کاربری واقعی را ضعیف می‌کند. همچنین سایت‌هایی که مرتباً با محدودیت منابع مواجه می‌شوند ممکن است خطاهای ۵۰۰، تایم‌اوت و قطعی‌های مکرر داشته باشند. گوگل‌بات نیز صفحات کند یا خطادار را با احتیاط بیشتری کراول می‌کند.

برای مثال فرض کنید صفحه اصلی سایت شما معمولاً با زمان پاسخ ۳۰۰ میلی‌ثانیه بارگذاری می‌شود اما وقتی xmlrpc.php در هر دقیقه ۱۰۰۰ درخواست دریافت می‌کند، پردازش‌های PHP اشباع شده و زمان پاسخ به بیش از ۲ ثانیه می‌رسد. این باعث کندی بارگذاری، کاهش نرخ تبدیل و نوسان در گزارش‌های خزیدن گوگل می‌شود. مسدودسازی XML-RPC در سطح سرور این بار اضافی را پیش از رسیدن به برنامه قطع می‌کند و به ثبات عملکرد کمک می‌کند.

از نظر سئو، سایت امن و سریع تنها به کیفیت محتوا وابسته نیست بلکه باید زیرساخت فنی قوی داشته باشد. HTTPS، نسخه PHP به‌روز، دیسک سریع، کش درست، قالب تمیز و کاهش سطح حمله باید همزمان رعایت شوند. به همین خاطر تنظیمات امنیتی وردپرس باید در اولویت تیم‌های فنی، سئو و محتوا باشد. در بلاگ Hostragons این موضوع با مطالبی مثل بهینه‌سازی سرعت وردپرس و چک‌لیست سئوی فنی به خوبی پوشش داده شده است.

اگر نتوانستید XML-RPC را به طور کامل غیرفعال کنید چه؟ راهکارهای جایگزین

در برخی پروژه‌ها امکان غیرفعال‌سازی کامل XML-RPC وجود ندارد. برای مثال اگر جریان انتشار موبایل، اتوماسیون سازمانی یا یکپارچه‌سازی قدیمی به این پروتکل وابسته باشد. در این شرایط هدف، باز نهادن درب کاملاً باز نیست بلکه کنترل دسترسی است. نخستین گزینه، فهرست سفید IP است؛ یعنی فقط آدرس‌های IP سرویس‌های مورد اعتماد اجازه دسترسی دارند و بقیه رد می‌شوند.

گزینه دوم، اعمال محدودیت نرخ درخواست است. یعنی جلوگیری از ارسال تعداد زیاد درخواست xmlrpc.php در مدت کوتاه توسط یک IP. این روش به اندازه غیرفعال‌سازی کامل مطمئن نیست اما حجم حملات را کاهش می‌دهد. گزینه سوم، غیرفعال کردن متدهای pingback و اجازه فقط به متدهای ضروری است. این به پیکربندی پیشرفته‌تر و کنترل توسعه‌دهنده نیاز دارد.

چهارمین گزینه، افزودن لایه امنیتی جداگانه به XML-RPC است. مثلاً احراز هویت HTTP Basic، VPN، محدودیت IP سازمانی یا چالش WAF. این روش‌ها ریسک نقاط دسترسی عمومی را کاهش می‌دهند. ولی در نهایت بهترین راهکار بلندمدت، انتقال یکپارچه‌سازی‌های قدیمی به روش‌های مدرن‌تر مانند REST API است.

نقشه راه سریع برای کاربران Hostragons

اگر سایت وردپرسی خود را روی Hostragons میزبانی می‌کنید، ابتدا نیازسنجی کنید و ساده‌ترین روش ممکن را انتخاب کنید. در هاست اشتراکی یا بسته‌های میزبانی وردپرس ویرایش فایل .htaccess از طریق مدیریت فایل کافی است. در سرورهای VPS یا اختصاصی می‌توانید از Nginx، Apache، LiteSpeed و WAF به صورت ترکیبی استفاده کنید.

ترتیب انجام کار به این شکل است: ابتدا بکاپ بگیرید، سپس سرویس‌های استفاده‌کننده از XML-RPC را شناسایی کنید، بعد روی سطح سرور مسدودسازی انجام دهید، تست‌ها را کامل کنید و لاگ‌ها را حداقل ۲۴ ساعت زیر نظر بگیرید. اگر تلاش‌های حمله ادامه داشت، قوانین WAF، بلاک IP و محدودیت تعداد ورود را اضافه کنید. در مرحله نهایی 2FA، به‌روزرسانی، بکاپ منظم و SSL را تکمیل نمایید.

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

سؤالات متداول

آیا غیرفعال کردن XML-RPC باعث اختلال در سایت وردپرسی من می‌شود؟

در بیشتر سایت‌های استاندارد وردپرسی خیر، مشکلی ایجاد نمی‌کند. پنل مدیریت، قالب، محتوا، فرم‌ها و بخش کاربری معمولاً تحت تأثیر قرار نمی‌گیرند. اما اگر از Jetpack، اپ موبایل وردپرس یا یکپارچه‌سازی‌های خاص XML-RPC استفاده می‌کنید ممکن است به مشکل بخورید. بنابراین پیش از غیرفعال‌سازی حتما نیازسنجی و تست عملکرد انجام دهید.

چطور بفهمم XML-RPC سایت من غیرفعال است یا نه؟

آدرس yourdomain.com/xmlrpc.php را در مرورگر باز کنید. اگر متنی مانند XML-RPC server accepts POST requests دیدید یعنی فایل فعال است. دریافت پاسخ ۴۰۳، ۴۰۴ یا رد دسترسی یعنی غیرفعال‌سازی موفق بوده است. برای اطمینان بیشتر، کدهای وضعیت درخواست‌های xmlrpc.php را در لاگ‌های سرور چک کنید.

آیا غیرفعال کردن XML-RPC کل حملات brute force را متوقف می‌کند؟

این کار بخش عمده‌ای از تلاش‌های brute force از طریق XML-RPC را قطع می‌کند، اما تمام خطرات را از بین نمی‌برد. مهاجمین می‌توانند از طریق wp-login.php یا روش‌های دیگر تلاش کنند. بنابراین باید اقدامات تکمیلی مانند رمز قوی، 2FA، محدودیت تلاش ورود، WAF و به‌روزرسانی منظم را انجام دهید.

اگر از Jetpack استفاده می‌کنم XML-RPC را باید ببندم؟

برخی ویژگی‌های Jetpack به اتصال XML-RPC نیاز دارند. اگر Jetpack فعال است، قبل از غیرفعال‌سازی بررسی کنید کدام ماژول‌ها استفاده می‌شوند. می‌توانید به جای بستن کامل، دسترسی فقط برای IPهای Jetpack را مجاز کنید یا قوانین WAF با کنترل دقیق تعریف نمایید.

استفاده از افزونه بهتر است یا مسدودسازی در سرور؟

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

خلاصه کوتاه و گام بعدی

غیرفعال‌سازی XML-RPC در وردپرس، در سایت‌هایی که به آن نیاز ندارند، یکی از سریع‌ترین روش‌های کاهش حملات brute force، سوءاستفاده از pingback و ترافیک رباتی غیرضروری است. بهترین روش، مسدود کردن دسترسی به xmlrpc.php در سطح سرور یا WAF و سپس ایجاد حفاظت چندلایه با ورود امن، 2FA، به‌روزرسانی، SSL و بکاپ منظم است. اگر قصد بررسی زیرساخت سایت خود را دارید، می‌توانید راه‌حل‌های میزبانی و امنیتی وردپرس Hostragons را مطالعه کرده و با یک چک‌لیست ساده امروز اولین قدم را بردارید.