XML-RPC در وردپرس چیست؟ آموزش غیرفعال‌ سازی و جلوگیری از حملات

27 اسفند 1399

XML-RPC وردپرس چیست؟ آموزش مقابله با حملات XMLRPC

گاهی ممکن است شما با عنوان مدیر وب سایت در لاگ های هاست و ابزار های امنیتی سایت وردپرسی خود تعداد زیادی درخواست به آدرس xmlrpc.php مشاهده کنید که تعداد این درخواست ها به گونه ای هست که اصلا عادی نیست!

وقتی تعداد درخواست های بالایی را به آدرس xmlrpc.php مشاهده کردید نباید در درجه اول به این فکر کنید که وب سایت شما هک شده است! اما بی تفاوت هم از کنار این قضیه عبور نکنید.

فایل xmlrpc.php بخشی از وردپرس است که امکان ارتباط برنامه ها و سرویس های خارجی را به سایت فراهم می کند و از وردپرس 3.5 به بعد به صورت پیش فرض در هسته وردپرس فعال می باشد و می تواند برای مدیریت محتوا٬ انتظار از راه دور و برخی سرویس های متصل به وردپرس مورد استفاده قرار بگیرد.

تا اینجا می توان گفت نه خود xmlrpc.php مورد غیرطبیعی هست نه وظیفه ای که برعهده دارد! در واقع بخشی از هسته وردپرس می باشد اما مشکل از جایی شروع می شود که همین قابلیت به عنوان هدف درخواست های مخرب٬ حملات Brute Force و مصرف غیرعادی منابع سرور قرار بگیرد بنابراین شاید به شکل ساده بتوان گفت اگر به این قابلیت نیاز ندارید فعال بودن آن هم هیچ فایده ای برای شما نخواهد داشت.

با غیرفعال کردن XML-RPC در واقع شما پتانسیل حملات به سایت خود را کاهش می دهید و کمک می کنید تا یک قدم به امنیت بیشتر نزدیک تر شوید.

ما در این آموزش قصد داریم نحوه تشخیص فعال بودن XML-RPC ٬ خطرات احتمالی فعال بودن آن و غیرفعالسازی یا محدود کردن xmlrpc.php را خدمت شما عزیزان توضیح دهیم.

XML-RPC چیست؟

همانطور که گفته شد XML-RPC در واقع یک پروتکل ارتباطی هست که به نرم افزار ها و سرویس های دیگر اجازه می دهد از راه دور با سایت وردپرسی ارتباط بگیرند.

در واقع این قابلیت کمک می کند یک برنامه خارجی به صورت ریموت به سایت وصل شود و بدون ورود مستقیم به پیشخوان وردپرس٬ درخواست هایی مانند انتشار یا ویرایش نوشته٬ مدیریت دیدگاه ها و دریافت اطلاعات سایت را ارسال کند.

در وردپرس این ارتباط از طریق فایل xmlrpc.php انجام می شود که در ریشه اصلی سایت یا همان محل نصب وردپرس قرار دارد و در گذشته به طور گسترده تری برای اتصال اپلیکیشن های موبایل٬ ابزارهای انتشار از راه دور و برخی سرویس های جانبی به وردپرس استفاده می شد.

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

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

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

نحوه تشخیص فعال بودن این قابلیت در سایت های وردپرسی بسیار ساده هست. چون این فایل در ریشه اصلی وردپرس قرار دارد خیلی ساده می توان در مرورگر با آدرس دامنه بررسی کرد این قابلیت فعال می باشد یا خیر.

ساده‌ ترین روش این است که آدرس زیر را در مرورگر باز کنید:

https://example.com/xmlrpc.php

اگر به جای دامنه example.com نام دامنهخود را قرار دهید می توانید بررسی داشته باشید این قابلیت فعال هست یا خیر.

اگر XML-RPC مستقیما قابل دسترسی باشد، معمولا پیامی مشابه زیر مشاهده می‌ کنید:

XML-RPC server accepts POST requests only.

پیامی که مشاهده می کنید در واقع رفتار خود XML-RPC می باشد چون در وردپرس تعریف شده است درخواست های اصلی این سرویس باید با متد POST ارسال شوند. بنابراین وقتی این پیام را مشاهده کردید یعنی این قابلیت فعال هست و هیچ محدودیتی روی آن اعمال شده نیست.

اما در عوض اگر خطای 403 Forbidden دریافت کردید نشان می دهد احتمالا دسترسی به این فایل xmlrpc.php توسط وب سرور٬ فایروال یا افزونه های امنیتی مسدود شده هست و مشکلی ندارد.

بررسی XML-RPC با curl:

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

در صورت دسترسی به Terminal می‌ توانید از دستور زیر نیز استفاده کنید:

curl -I https://example.com/xmlrpc.php

البته وضعیت HTTP به تنظیمات وب‌ سرور، CDN و افزونه‌ های امنیتی بستگی دارد؛ بنابراین فقط بر اساس یک Status Code درباره فعال یا غیرفعال بودن XML-RPC نتیجه‌گیری نکنید.

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

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

اما اینکه واقعا فعال بودن این قابلیت تا چه اندازه می تواند خطرناک باشد را می توان به شکل زیر گفت:

1- اجرای حملات Brute Force با تعداد درخواست کمتر:

همانطور که در بالا به صورت خلاصه به آن اشاره شد حملات بروت فورس یکی از مواردی هست که باز بودن قابلیت XML-RPC می تواند به همراه داشته باشد.

حملات بروت فورس در واقع حمله ای هست که مهاجم با تعداد زیادی درخواست همزمان تلاش می کند نام کاربری و رمز عبور ورود به پیشخوان وردپرس را پیدا کند و عموما این کار توسط ربات ها انجام می شود و از پسورد های ساده و نام های کاربری پیش فرض در شروع استفاده می شود.

در واقع از مهم ترین ریسک های XML-RPC استفاده از آن برای امتحان نام کاربری و رمز عبور می باشد.

مهاجم می تواند به جای تمرکز کردن روی صفحه ورود وردپرس٬ درخواست های احراز هویت را مستقیم به xmlrpc.php ارسال کند و با این روش به پیشخوان دسترسی پیدا کند.

این موضوع زمانی شرایط بحرانی به خود می گیرد که از متدهایی مانند system.multicall استفاده شود. این متد اجازه می دهد که چند فراخوانی XML-RPC در قالب یک درخواست واحد ارسال شود به عبارت دیگر مهاجم می تواند تعداد زیادی ترکیب نام کاربری و رمز عبور را در تعداد درخواست های کمتر HTTP آزمایش کند.

این روش ممکن است تشخیص حمله را دشوارتر کند چون تعداد درخواست هایی که در سرور یا Access Log ثبت شده است در واقعا نشان دهنده تعداد واقعی تلاش های ورود نیست!

یعنی ممکن است کاربر تنها چند درخواست به xmlrpc.php را ببیند و تصور کند که این درخواست ها عادی بوده است در صورتی که در همین چند درخواست می توانست هزاران درخواست برای ورود وجود داشته باشد.

نباید تنها با محدود کردن تعداد درخواست ها به wp-login.php تصور کرد که جلوی حملات Brute Force گرفته شده است!

2- مصرف شدید CPU و منابع سرور:

هر بار که درخواستی به xmlrpc.php می رسد سرور موظف هست آن را پردازش کند و نباید این پردازش را با فایل هایی مانند CSS ٬ JavaScript یا تصاویر یکی بدانید! چون برخلاف این موارد که توسط وب سرور پاسخ داده می شود درخواست های xmlrpc.php باید مستقیم وارد چرخه اجرای PHP و وردپرس شود و منابعی که مصرف می کند به مراتب بالاتر از درخواست های ساده CSS می باشد.

فرض کنید یک ربات مهاجم در مدت زمان کوتاه هزاران درخواست را به این فایل ارسال کند و بخواهد با حملات بروت فورس به نام کاربری و پسورد شما دسترسی پیدا کند یا اصلا هدف پر کردن منابع سخت افزاری هاست به منظور داون کردن سایت باشد!

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

در سایت هایی که منابع آن ها محدود هست این درخواست ها به سرعت می تواند باعث افزایش Load سرور٬ کند شدن سایت یا پنل پیشخوان و افزایش زمان لود صفحات شود و خطا هایی نظیر Service Unavailable 503 دور از انتظار نیست.

به همین دلیل حمله به XML-RPC فقط یک مسئله امنیتی نیست و می‌ تواند مستقیما روی سرعت و پایداری سایت هم اثر بگذارد.

3- سواستفاده از Pingback:

قابلیت Pingback برای این طراحی شده هست که وقتی سایتی به یک نوشته وردپرسی لینک می دهد سایت مقصد از آن مطلع شود و این ویژگی از طریق XML-RPC و متدهایی مانند pingback.ping کار می کند.

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

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

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

4- دور زدن برخی محافظت‌ های صفحه ورود:

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

عموما برای این کار از محدودیت هایی مانند CAPTCHA ٬ محدودیت های دفعات ورود٬ تغییر آدرس پیش فرض پیشخوان یا مسدود سازی IP استفاده می کنند.

اما نباید فراموش کنید صرفا انجام دادن این کارها باعث نمی شود ورود به پیشخوان شما به محدودیت کامل رو به رو باشد و مهاجمان نتوانند در آن لاگین کنند.

همانطور که به صورت خلاصه خدمت شما عرض شد XML-RPC مسیر جداگانه ای برای ارسال درخواست احراز هویت دارد. بنابراین اگر فقط صفحه ورود محافظت شده باشد ولی xmlrpc.php بدون محدودیت باقی مانده باشد خیلی ساده مهاجم می تواند به تلاش های خود برای دستیابی به رمز عبور و نام کاربری شما ادامه دهد.

برای مثال ممکن است مدیر سایت تصور کند چون روی صفحه ورود CAPTCHA فعال است، حملات خودکار متوقف شدند ولی این در حالی است که ربات‌ ها همچنان روی XML-RPC درخواست ارسال می‌ کنند.

این موضوع باعث می‌ شود XML-RPC در بعضی سایت‌ ها به یک مسیر جایگزین برای حملاتی تبدیل شود که در ظاهر روی صفحه ورود مهار شدند.

5- ایجاد ترافیک غیرعادی و فشار روی وب‌ سرور:

درخواست هایی که به شکل مخرب به این قابلیت زده می شود تنها شامل خطر برای دستیابی به رمز عبور و نام کاربری و همچنین بالا بردن منابع سخت افزاری نمی شود.

ربات ها با درخواست های غیرعادی می توانند خیلی سریع حجم بالایی از Request ها را به این فایل ارسال کنند.

این حجم بالا دیگر تنها php ٬ سی پیو و رم را درگیر نمی کند و خوب وب سرور هم دچار مشکل در پاسخگویی به درخواست ها می شود.

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

6- بزرگ شدن Access Log و دشوار شدن بررسی:

هر درخواستی که به xmlrpc.php زده می شود در Access Log وب سرور ثبت می شود و وقتی حمله شدید باشد ممکن در مدت زمان کوتاه هزاران و حتی چندصد هزار رکورد فقط برای این فایل ایجاد شود.

افزایش حجم لاگ دو مشکل ایجاد می کند:

اول اینکه باعث می شود فضای بیشتری در دیسک مصرف شود و در سرور هایی که تنظیمات مناسب برای فایل های لاگ اعمال نشده است به شدت می تواند دردسر ساز شود.

دوم اینکه دیگر نمی توان از این فایل های لاگ برای بررسی مشکلات احتمالی و موارد مهم استفاده کرد چون پیدا کردن خطا ها و درخواست های مشکوک دیگر سخت می شود.

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

نحوه غیرفعال کردن XML-RPC در وردپرس:

اگر اطمینان دارید که سایت شما به این قابلیت نیاز ندارد بهترین گزینه این است که دسترسی به xmlrpc.php را از سمت وب سرور ببندید.

با این کار درخواست های مربوط به این فایل قبل از اینکه به وردپرس برسند مسدود می شوند.

روش انجام این کار برای وب سرور هایی نظیر LiteSpeed و Apache بسیار ساده است.

1- غیرفعال کردن XML-RPC در htacces.:

هاست وردپرس برای افزایش عملکرد و راندمان بهتر پاسخگویی درخواست ها عموما از وب سروری نظیر لایت اسپید استفاده می کند.

اگر هاست شما هم دارای لایت اسپید هست و از Cpanel یا DirectAdmin استفاده می کنید برای بستن این قابلیت تنها کافی هست ابتدا وارد File Manager هاست شوید و به پوشه اصلی سایت بروید. در بیشتر هاست‌ ها این پوشه همان:

public_html

می باشد که وردپرس در این مسیر نصب شده هست. اگر شما از دامنه اضافه یا روی ساب دامنه برای نصب وردپرس استفاده کردید دقیقا باید وارد همان مسیر شوید.

در این قسمت فایل زیر را پیدا کنید:

.htaccess

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

حالا فایل .htaccess را ویرایش کنید و کد زیر را به آن اضافه کنید:

<Files "xmlrpc.php">
    Require all denied
</Files>

سپس فایل را ذخیره کنید.

این کد به وب‌ سرور می‌گوید که اجازه دسترسی به فایل xmlrpc.php را به کاربران اینترنت ندهد.

برای بررسی نتیجه، آدرس XML-RPC سایت خود را در مرورگر باز کنید:

https://example.com/xmlrpc.php

اگر تنظیمات به‌ درستی اعمال شده باشد، معمولاً با خطای 403 Forbidden یا پیام عدم دسترسی رو به‌ رو خواهید شد.

این روش برای وب سرور آپاچی و لایت اسپید مشترک هست و تفاوتی ندارد از کدام وب سرور استفاده می کنید با این روش روی هر دو وب سرور می توانید درخواست ها را ببندید.

اگر کد Require all denied کار نکرد چه کنیم؟

در خیلی از سرورها ممکن است از نسخه های قدیمی Apache استفاده شود که در این شرایط باید از ساختار های قدیمی دستورات .htaccess استفاده شود که در این شرایط که اگر کد قبلی کار نکرد از کد زیر استفاده کنید.

<Files "xmlrpc.php">
    Order Allow,Deny
    Deny from all
</Files>

اما اگر سرور شما از Apache 2.4 یا نسخه‌ های جدیدتر استفاده می‌ کند، بهتر است همان روش اول یعنی:

Require all denied

را استفاده کنید.

2- محدود کردن XML-RPC با افزونه وردپرس:

اگر به هر دلیلی به هاست دسترسی ندارید یا نمی خواهید مستقیم فایل .htaccess را ویرایش کنید بهتر است از افزونه های امنیتی برای محدود کردن XML-RPC استفاده کنید.

این روش برای کاربرانی که با کنترل پنل های هاست آشنایی ندارند هم مناسب تر است.

یکی از گزینه‌ ها Wordfence Security است. این افزونه بخشی برای کنترل ورود از طریق XML-RPC دارد و می‌ تواند درخواست‌ هایی که برای احراز هویت از XML-RPC استفاده می‌ کنند مسدود کند.

بعد از نصب و فعال‌ سازی Wordfence، وارد پیشخوان وردپرس شوید و از منوی:

Wordfence → Login Security → Settings

به بخش تنظیمات XML-RPC بروید.

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

نکته: مهم این است که این گزینه خود فایل xmlrpc.php را به‌ طور کامل نمی‌ بندد٬ بلکه بخش احراز هویت XML-RPC را غیرفعال می‌ کند. بنابراین با روشی که قبلا در .htaccess توضیح دادیم تفاوت دارد.

در روش .htaccess دسترسی به فایل از سمت وب‌ سرور مسدود می‌ شود، اما Wordfence می‌تواند فقط بخش‌ های حساس مربوط به ورود را محدود کند.

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

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

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

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

بعد از اعمال تغییرات فقط به باز شدن یا نشدن xmlrpc.php اکتفا نکنید.

موارد زیر را نیز بررسی کنید:

وارد مدیریت وردپرس شوید.

یک نوشته آزمایشی ویرایش کنید.

Cron و عملیات عادی سایت را بررسی کنید.

در صورت استفاده از Jetpack اتصال آن را بررسی کنید.

برنامه موبایل یا سرویس انتشار از راه دور را تست کنید.

خطاهای Error Log را بررسی کنید.

Cache سایت و CDN را پاک کنید.

دوباره Access Log را بررسی کنید.

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

جمع‌ بندی:

قابلیت XML-RPC اگرچه در بسیاری از سایت ها فعال می باشد اما اکثر کاربران وردپرسی از آن استفاده نمی کنند و کاربرد واقعی ندارد.

اگر هیچ سرویس یا قابلیتی از این ویژگی استفاده نمی کنند باز گذاشتن فایل xmlrpc.php تنها یک مسیر اضافه برای دریافت درخواست های ناخواسته ایجاد می کند.

بستن این فایل در سطح وب سرور می تواند گزینه مناسبی برای جلوگیری از این درخواست ها باشد و اگر هم به این قابلیت نیاز دارید بهتر است به جای غیرفعالسازی کامل٬ دسترسی آن را مطابق با آموزش هایی که دادیم محدود کنید تا هم سرویس مورد نیاز به کار خود ادامه دهد و هم درخواست های مشکوک بسته شوند.

در نهایت، هدف از غیرفعال یا محدود کردن XML-RPC این نیست که به‌ تنهایی امنیت وردپرس را تضمین کند٬ بلکه یکی از اقداماتی است که در کنار رمز عبور قوی، بروزرسانی وردپرس و افزونه‌ ها، فایروال و کنترل تلاش‌ های ورود می‌ تواند سطح امنیت سایت را بالاتر ببرد.

Rate this post