اشتباهات امنیتی رایج در وردپرس
آیا مطمئنید سایت وردپرسیتان با همان عادتهای امنیتی سال گذشته امن است؟ این ده اشتباه رایج، مسئول بیشترین پروندههای هک وردپرس هستند؛ ببینید کدامشان در سایت شما پنهان مانده.
سالها پیش، یک سایت مشتری را که تازه تحویل داده بودم، دو ماه بعد هک شد. آن روز خیلی به خودم فشار آوردم چون مطمئن بودم همهچیز را چک کردهام. بعد از بررسی مشخص شد در فایل wp-config.php یک خط دیتابیس خاموش مانده بود و کاربر admin همان نام کاربری پیشفرض بود. از آن روز، هر پروژهای که تحویل میدهم، اول یک لیست ذهنی از همین اشتباهات رایج را روی آن اجرا میکنم. این مقاله همان لیست است — نه برای ترساندن، بلکه بهعنوان چکلیستی که هر چند ماه یک بار روی سایت خودم هم اجرا میکنم.
چرا اشتباهات امنیتی، حتی وقتی همهچیز را چک کردهاید، برمیگردند
در راهنمای امنیت وردپرس برای مبتدیان درباره اصول پایه نوشتهام، اما این مقاله یک هدف متفاوت دارد. تمرکزم روی الگوهای رفتاریای است که در بازبینی صدها سایت وردپرسی دیدهام — الگوهایی که حتی افراد باتجربه هم گرفتارشان میشوند، چون امنیت یک وضعیت ثابت نیست؛ یک عادت است که اگر رهایش کنید، فرسوده میشود. هکرها از ضعفهای شما استفاده نمیکنند، از ضعفهایی که شما دیگر به آنها نگاه نمیکنید استفاده میکنند.
امنیت، حالتِ رسیدن به هدف نیست؛ عادتِ ماندن در مسیر است. هر بار که فکر میکنید کارتان تمام شده، کارتان تازه شروع شده.
اشتباه اول: کاربر admin پیشفرض
این قدیمیترین و پایدارترین اشتباه است. در نصبهای خودکار وردپرس، خیلی از کاربران نام کاربری admin را انتخاب میکنند چون سریع است. حالا به این عدد نگاه کنید: در حملههای Brute Force که روی سایتهای وردپرسی میبینم، اولین چند صد تلاش همیشه روی نام کاربری admin است. یعنی شما نصف کار را برای مهاجم انجام دادهاید؛ فقط رمز مانده.
خبر خوب این است که تغییر نام کاربری ادمین در وردپرس ساده است. یک کاربر جدید با نام غیرقابل حدس بسازید، نقش Administrator به آن بدهید، با آن وارد شوید و کاربر قدیمی را حذف کنید (و محتوایش را به کاربر جدید منتقل کنید). روش دقیقش را در امنسازی ورود ادمین وردپرس گامبهگام توضیح دادهام.
اشتباه دوم: رمز عبور ضعیف و بیتوجهی به 2FA
هیچوقت از رمزی که در جای دیگری استفاده کردهاید استفاده نکنید. این جمله تکراری است، ولی در پروندههای هکی که بررسی میکنم، همیشه یک رمز تکراری در جایی از زنجیره پیدا میشود. اما لایه مهمتر: رمز قوی هم اگر دزدیده شود، هیچ کاری برایتان نمیکند. اینجاست که 2FA (Two-Factor Authentication) یا احراز هویت دو مرحلهای وارد میشود.
در پروژههایی که مشتری مقاومت میکند و میگوید 2FA برای من سخت است، همیشه یک مثال میزنم: اگر رمز شما در یک نشت دادهای فاش شود، بدون 2FA همان شب سایت شما در خطر است؛ با 2FA، مهاجم نهفقط رمز، بلکه گوشی شما را هم لازم دارد. برای فعالسازی در وردپرس، مسیرش در فعالسازی 2FA برای کاربران وردپرس آمده و اگر میخواهید تهدید را عمیقتر بشناسید، مقاله دفع حملات Brute Force را بخوانید.
اشتباه سوم: نصب قالب و افزونه از منبع ناشناس
این همان اشتباهی است که در پروندههای پاکسازی، ریشه بیش از نیمی از آلودگیها بوده. کاربر یک قالب پولی معروف را «رایگان» از یک سایت ناشناس دانلود میکند و چند ماه بعد متوجه میشود یک backdoor (درب پشتی) در فایلهای قالب نشسته که برایش لینکهای کازینویی میسازد. نکته تلخ این است که تشخیص این نوع آلودگی برای کاربر عادی تقریباً غیرممکن است، چون کد در لایههای عمیق پنهان میشود.
قاعدهای که خودم سالهاست رعایت میکنم: فقط از مخزن رسمی وردپرس یا سایت خود سازنده. اگر افزونه پولی است، یا بخرید یا جایگزین رایگان معتبرش را پیدا کنید. هیچ لینک تلگرامی و سایت «دانلود رایگان» ارزش ریسک ندارد. برای تشخیص نشانههای یک قالب یا افزونه آلوده، بررسی امنیت قالب و افزونه را ببینید و برای درک ریشه خطر، آسیبپذیری افزونههای وردپرس نقطه شروع خوبی است.
قالب نال، فقط یک قالب دزدیدهشده نیست؛ یک کلید یدکی است که سازندهاش هنوز دارد.
اشتباه چهارم: آپدیت نکردن به بهانه ترس
جملهای که زیاد میشنوم: نمیخواهم آپدیت کنم چون ممکن است سایت بههم بریزد. این ترس بیدلیل نیست — آپدیتها گاهی چیزهایی میشکنند — ولی استراتژی درست، «آپدیت نکن» نیست؛ «آپدیت را در محیط استجینگ تست کن، بعد روی سایت زنده بگذار» است. آپدیتِ معوق، شایعترین حفرهای است که در سایتهای وردپرسی دیدهام.
در همین راستا، دو نکته عملی: اول، وردپرس آپدیتهای امنیتی خودکار برای نسخههای جزئی دارد؛ آنها را خاموش نکنید. دوم، برای قالب و افزونههای حیاتی، قبل از آپدیت روی سایت زنده، یک استجینگ بسازید و همانجا تست کنید. اگر آمادگی این کار را ندارید، مقاله توسعه وردپرس با محیط لوکال و مسیر ساخت استجینگ را در همین سایت آوردهام.
اشتباه پنجم: بکاپ بدون تست بازیابی
این اشتباه، از آنهایی است که تا لحظه فاجعه دیده نمیشود. تا وقتی سایت سالم است، همه فکر میکنند بکاپ دارند. اما وقتی هک میشوند و میروند بکاپ روز قبل را بازیابی کنند، متوجه میشوند فایل بکاپ خراب است، یا دیتابیس داخلش نیست، یا آنقدر قدیمی است که بخش زیادی از محتوا را از دست میدهد.
قاعدهای که به همه مشتریان میگویم: بکاپی که یک بار بازیابیاش را تمرین نکردهاید، بکاپ نیست. حداقل هر سه ماه یک بار، در یک محیط جدا، بکاپ را بازیابی کنید و مطمئن شوید محتوا و دیتابیس سالم برمیگردند. فهرست ابزارهای معتبر را در بهترین افزونههای پشتیبانگیری وردپرس آوردهام.
اشتباه ششم: دستکاری فایلهای هسته و قالب والد
یکی از پرتکرارترین عادتهای بدی که در پروژههای قدیمی میبینم این است که توسعهدهنده کدی را مستقیم در فایل functions.php قالب والد یا فایلهای هسته وردپرس مینویسد. مشکل اول این است که آپدیت بعدی، تمام این تغییرات را پاک میکند؛ مشکل دوم و مهمتر، این است که اگر کد مشکلی داشته باشد، هیچ راهی برای تشخیص سریعاش نیست و کل سایت ممکن است از کار بیفتد.
راهحل تمیز: هر سفارشیسازی در یک Child Theme (قالب فرزند). قبلاً درباره قالب چایلد وردپرس مفصل نوشتهام؛ کافی است بدانید هر تغییری در قالب والد، در روز آپدیت به یک فاجعه تبدیل میشود و در روز مهاجرت، به یک دردسر بزرگ.
اشتباه هفتم: wp-config بیدفاع
فایل wp-config.php قلب تنظیمات وردپرس است: اطلاعات دیتابیس، کلیدهای امنیتی و تنظیمات دیباگ همه آنجا هستند. اگر این فایل از بیرون قابل خواندن باشد یا کسی بتواند به آن دسترسی پیدا کند، تمام زحمات امنیتی شما بیاثر میشود. در بازبینیها دو مشکل رایج دیدهام: اول، مجوزهای فایل که اغلب روی ۶۴۴ یا بالاتر مانده، در حالی که باید ۶۰۰ یا ۶۴۰ باشد. دوم، ماندن WP_DEBUG روی true در سایت زنده که پیامهای خطا را به کاربر نمایش میدهد و مسیرهای فایل را لو میدهد.
راهنمای کامل سختسازی این فایل در چگونه فایل wp-config را امن کنیم آمده. اگر فقط یک کار میتوانید بکنید، مطمئن شوید WP_DEBUG روی سایت زنده false است.
اشتباه هشتم: باز گذاشتن ویرایشگر پیشخوان
وردپرس بهصورت پیشفرض اجازه میدهد از داخل پیشخوان، فایلهای PHP قالب و افزونهها را ویرایش کنید. این ویژگی برای توسعه راحت است، اما برای سایت زنده یک در باز است. اگر حساب ادمین هک شود، مهاجم نهفقط میتواند محتوا را تغییر دهد، بلکه میتواند کد دلخواه در سایت تزریق کند.
غیرفعال کردنش یک خط کد است: در wp-config.php این خط را اضافه کنید:
define( 'DISALLOW_FILE_EDIT', true );
اگر تیم شما به ویرایشگر پیشخوان وابسته است، این محدودیت را در محیط استجینگ نگه دارید و روی سایت زنده فعال کنید.
اشتباه نهم: بیتوجهی به فعالیت کاربران
بسیاری از هکها با یک کاربر قانونی شروع میشوند که دیگر برای سایت کار نمیکند ولی حسابش هنوز فعال است. یا یک نویسنده که دسترسیاش مدتها پیش باید محدود میشد و نشد. در بازبینیهای امنیتی، من بهطور منظم فهرست کاربران را مرور میکنم: هر کاربری که در شش ماه گذشته وارد نشده و در آینده نزدیک هم قرار نیست وارد شود، باید غیرفعال یا حذف شود. همچنین نقشها را مرور کنید — هیچ نویسندهای نباید نقش Administrator داشته باشد؛ فقط کسی که واقعاً به آن نیاز دارد.
یک لایه تکمیلی، لاگ فعالیت کاربران است. با یک افزونه ساده میتوانید ببینید چه کسی چه زمانی چه کاری انجام داده. روزی که مشکلی پیش بیاید، همین لاگها هستند که به شما میگویند از کجا شروع شده.
اشتباه دهم: پاسخدهی با عجله بعد از هک
واکنش خیلی از صاحبان سایت بعد از هک این است که سریع وارد پیشخوان میشوند و شروع میکنند به پاک کردن فایلهای عجیب. این کار، در تجربه من، معمولاً وضع را بدتر میکند. اگر بکاپ «لحظه جرم» نداشته باشید، نمیتوانید ریشه نفوذ را پیدا کنید و پاکسازی سطحی، دو هفته بعد دوباره به همان نقطه برمیگردد.
ترتیب درست را در راهنمای پاکسازی سایت هکشده وردپرس گامبهگام آوردهام. بهطور خلاصه: اول بکاپ «لحظه جرم» بگیرید، دوم سایت را موقتاً روی حالت تعمیرات ببرید، سوم لاگهای دسترسی و فایلهای تغییریافته را بررسی کنید، چهارم پاکسازی و در پایان چرخه رمزها. شناخت نشانههای اولیه هک هم در علائم هک و بدافزار در وردپرس آمده است.
سه تذکر از دفترچه تجربه
اگر بخواهم این ده اشتباه را در سه تذکر فشرده کنم: اول، امنیت یک محصول نیست که یک بار بخرید؛ یک روال است که هر چند ماه اجرا میکنید. دوم، شایعترین حفرهها در سادهترین جاها هستند — یک نام کاربری، یک رمز تکراری، یک افزونۀ قدیمی — نه در حملات پیچیده. سوم، وقتی شک دارید که آیا سایتتان امن است یا نه، بهترین کار دعوت یک چشم سوم است؛ گاهی خودتان آن نقاط کور را نمیبینید.
پیشنهاد عملی من برای همین هفته: یکی از ده مورد بالا را انتخاب کنید و همین امروز روی سایت خودتان بررسی کنید. لازم نیست همهچیز را همزمان درست کنید؛ اما همین که یکی از این درها را ببندید، احتمال موفقیت هر حملهای را بهطور محسوسی پایین آوردهاید. اگر یکی از این اشتباهات را در سایت خودتان کشف کردید و راهحل جالبی برایش پیدا کردید، در دیدگاه بنویسید — تجربه شما میتواند نقطه شروع یک مقاله جدید در وردپرسکار باشد. 🔐