وردپرس بیش از هر سیستم مدیریت محتوای دیگری استفاده می‌شود، و برای همین هدف اول ربات‌های خودکار است. ولی خود هستهٔ وردپرس معمولاً مشکل نیست: بیشتر حفره‌ها در افزونه‌ها و قالب‌ها پیدا می‌شوند، و بیشتر سایت‌های هک‌شده نسخهٔ قدیمی یک افزونه داشتند یا رمز ضعیف. یعنی با چند عادت ساده، جلوی بیشتر حمله‌ها گرفته می‌شود.
یک مثال واقعی: LiteSpeed Cache
مرداد ۱۴۰۳ (اوت ۲۰۲۴) در افزونهٔ LiteSpeed Cache، با بیش از ۵ میلیون نصب فعال در آن زمان، حفره‌ای پیدا شد (CVE-2024-28000) که به هر بازدیدکنندهٔ بدون ورود اجازه می‌داد خودش را مدیر سایت کند. نسخهٔ ۶٫۴ آن را رفع کرد، ولی حمله‌ها کمتر از یک روز بعد از انتشار جزئیات شروع شد. سایت‌هایی که آپدیت خودکار داشتند در امان ماندند؛ بقیه در معرض خطر بودند.
درس: مشکل این نیست که افزونهٔ معروف حفره دارد؛ همهٔ نرم‌افزارها گاهی حفره دارند. مشکل، دیر آپدیت کردن است.
۱. آپدیت، خودکار
- آپدیت‌های امنیتی و جزئی هستهٔ وردپرس به‌طور پیش‌فرض خودکار نصب می‌شوند؛ خاموششان نکنید.
- در صفحهٔ افزونه‌ها، کنار هر افزونه گزینهٔ «فعال کردن به‌روزرسانی خودکار» هست. برای افزونه‌های امنیتی و ساده روشنش کنید.
- برای افزونه‌های بزرگ (صفحه‌ساز، ووکامرس) قبل از آپدیت بکاپ بگیرید، یا اول روی نسخهٔ آزمایشی (staging) امتحان کنید.
- افزونه و قالبی را که استفاده نمی‌کنید پاک کنید، نه فقط غیرفعال. فایل‌های افزونهٔ غیرفعال هم روی سرور است و ممکن است از آن سوءاستفاده شود.
- افزونه‌ای که بیش از یک سال آپدیت نشده، جایگزین کنید.
- هرگز افزونه یا قالب نال‌شده نصب نکنید؛ در این مقاله توضیح داده‌ایم چرا.
۲. کاربرها و رمز
- نام کاربری
adminنداشته باشید؛ ربات‌ها اول همین را امتحان می‌کنند. - رمز طولانی و تصادفی، و یک مدیر رمز (password manager) برای نگه‌داری‌اش.
- ورود دومرحله‌ای برای همهٔ مدیرها. افزونهٔ Two Factor (از مشارکت‌کنندگان خود وردپرس) یا بخش ورود دومرحله‌ای افزونه‌های امنیتی مثل Wordfence این کار را می‌کنند.
- کمترین نقش لازم: نویسنده نقش «نویسنده» بگیرد، نه «مدیر». کاربرهای قدیمی و همکارانی که رفته‌اند را حذف کنید.
- نمایش نام کاربری را با «نام نمایشی» عوض کنید تا نام ورود در صفحهٔ نویسنده دیده نشود.
۳. محافظت از صفحهٔ ورود
- محدودیت تلاش ورود: افزونه‌ای مثل Limit Login Attempts Reloaded، یا همین امکان در افزونه‌های امنیتی، بعد از چند رمز غلط IP را موقتاً مسدود می‌کند.
- عوض کردن آدرس wp-login: جلوی ربات‌های ساده را می‌گیرد و لاگ‌ها را خلوت می‌کند، ولی جای رمز قوی و ورود دومرحله‌ای را نمی‌گیرد.
- xmlrpc.php: رابط قدیمی‌ای است که ربات‌ها برای امتحان هزاران رمز در یک درخواست از آن استفاده می‌کنند. اگر از Jetpack یا اپ موبایل وردپرس استفاده نمی‌کنید، آن را در
.htaccessریشهٔ سایت ببندید:
<Files xmlrpc.php>
Require all denied
</Files>۴. wp-config.php و دسترسی فایل‌ها
این دو خط را در wp-config.php، بالای خط «That's all, stop editing» اضافه کنید:
// no theme/plugin file editor in the dashboard
define( 'DISALLOW_FILE_EDIT', true );
// force HTTPS for login and dashboard
define( 'FORCE_SSL_ADMIN', true );DISALLOW_FILE_EDITویرایشگر کد داخل پیشخوان را حذف می‌کند. اگر کسی رمز مدیر را به دست بیاورد، نمی‌تواند از همان‌جا کد مخرب در قالب بنویسد.- کلیدهای امنیتی (Salts): بعد از هر نفوذ یا اگر رمزها لو رفته، مقادیر
AUTH_KEYو بقیه را با خروجیhttps://api.wordpress.org/secret-key/1.1/salt/عوض کنید. همهٔ کاربران از سیستم خارج می‌شوند. - دسترسی فایل‌ها: پوشه‌ها ۷۵۵، فایل‌ها ۶۴۴، و
wp-config.php۶۰۰ یا ۶۴۰ (اگر با ۶۰۰ سایت بالا نیامد). هرگز ۷۷۷.
cd ~/public_html
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 600 wp-config.php۵. اجرای PHP در uploads ممنوع
پوشهٔ wp-content/uploads فقط باید عکس و فایل داشته باشد. ولی وقتی حفره‌ای اجازهٔ آپلود بدهد، مهاجم معمولاً یک فایل PHP (شل) همین‌جا می‌گذارد. با یک فایل .htaccess در خود این پوشه، اجرای PHP در آن بسته می‌شود:
# wp-content/uploads/.htaccess
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>۶. فایروال و اسکن
- Wordfence فایروال و اسکنر بدافزار در خود وردپرس دارد: فایل‌های هسته را با نسخهٔ اصلی مقایسه می‌کند و درخواست‌های مخرب شناخته‌شده را می‌بندد.
- جایگزین‌ها: Kadence Security (که قبلاً Solid Security و iThemes Security نام داشت) و Sucuri Security. فقط یکی را نصب کنید؛ افزونه‌های امنیتی با هم تداخل می‌کنند.
- فایروال در سطح CDN (WAF) حمله را قبل از رسیدن به هاست می‌گیرد و بار سرور را هم کم می‌کند.
- HTTPS برای کل سایت، با SSL رایگان هاست.
- و بکاپ بیرون از سرور: آخرین خط دفاع. در مقالهٔ بکاپ و انتقال آمده است.
سایت هک شده؟ پاک‌سازی قدم‌به‌قدم
نشانه‌های رایج: هدایت بازدیدکننده (اغلب فقط روی موبایل یا فقط از گوگل) به سایت دیگر، لینک‌ها و برگه‌های اسپم که در نتایج گوگل با جست‌وجوی site:example.ir دیده می‌شوند، کاربر مدیر ناشناس، هشدار «این سایت ممکن است خطرناک باشد» در مرورگر، یا تعلیق هاست به خاطر ارسال اسپم.
- از وضعیت فعلی بکاپ بگیرید، حتی آلوده؛ برای بررسی و اینکه اگر چیزی خراب شد، برگردید.
- همهٔ رمزها را عوض کنید: cPanel، FTP، دیتابیس (و در
wp-config.php)، و همهٔ کاربران مدیر وردپرس. کلیدهای Salt را هم عوض کنید. - کاربرهای ناشناس را حذف کنید:
wp user list --role=administrator - هسته را تمیز دوباره نصب کنید و بررسی کنید فایلی دست‌کاری نشده باشد:
cd ~/public_html
wp core verify-checksums
wp core download --force --skip-content
wp plugin verify-checksums --all- افزونه‌ها و قالب را از منبع اصلی دوباره نصب کنید. افزونه‌ای که منشأ نفوذ بوده را تا آمدن نسخهٔ امن حذف کنید.
- uploads را بگردید: در این پوشه نباید هیچ فایل PHP باشد:
find wp-content/uploads -name "*.php". دنبال کدهای مبهم مثلeval(base64_decodeهم در قالب و افزونه‌ها بگردید. - کارهای زمان‌بندی‌شده را ببینید:
wp cron event list، و Cron Jobs در cPanel. - اگر گوگل هشدار داده، بعد از پاک‌سازی در Search Console → Security issues درخواست بازبینی بدهید.
- راه نفوذ را پیدا کنید و ببندید (افزونهٔ قدیمی، رمز لو رفته، قالب نال‌شده)؛ وگرنه چند روز بعد دوباره هک می‌شوید.
منابع
- WordPress Developer — Hardening WordPress developer.wordpress.org/advanced-administration/security/hardening
- NVD — CVE-2024-28000 (LiteSpeed Cache) nvd.nist.gov/vuln/detail/CVE-2024-28000
- WordPress.org — Secret key generator api.wordpress.org/secret-key/1.1/salt
- WP-CLI — wp core verify-checksums developer.wordpress.org/cli/commands/core/verify-checksums