افزایش امنیت وردپرس حاصل چند لایهٔ مکمل است: نرمافزار نگهداریشده، دسترسی محدود، ورود محافظتشده، پایش و امکان بازیابی. نصب یک افزونه یا گرفتن گواهی HTTPS بهتنهایی سایت را در برابر همهٔ حملهها ایمن نمیکند. هدف، کمکردن احتمال رخداد و محدودکردن خسارت احتمالی است.
برنامهٔ افزایش امنیت وردپرس از کجا شروع میشود؟
ابتدا فهرست هسته، قالبها، افزونهها، حسابهای دارای دسترسی و سرویسهای متصل را تهیه کنید. مشخص کنید چه کسی مسئول بهروزرسانی، دریافت هشدار و پیگیری اختلال است. ابزار بدون مسئول پیگیری، ممکن است فقط انبوهی اعلان تولید کند.
برای فروشگاه، سلامت سفارش و اطلاعات مشتری مهم است؛ برای وبلاگ، جلوگیری از تغییر غیرمجاز مطالب و حساب نویسندگان نیز اهمیت دارد. اولویتها را با نوع داده و فعالیت سایت تعیین کنید، نه آمار قدیمی تعداد سایتهای هکشده.
میزبانی، نرمافزار و منابع معتبر
از میزبان دربارهٔ جداسازی حسابها، نسخههای پشتیبانیشدهٔ PHP و پایگاه داده، ثبت رخداد و روند رسیدگی به آلودگی سؤال کنید. داشتن بکاپ یا اسکن بدافزار، بهخودیخود دفاع در برابر DDoS نیست. دامنهٔ هر خدمت باید در توضیح سرویس روشن باشد.
هسته، افزونه و قالب را از مخزن رسمی یا فروشندهٔ اصلی تهیه کنید. معتبر بودن منبع خطر را کاهش میدهد، اما به معنی بینقصبودن دائمی نرمافزار نیست. بستههای بدون پشتیبانی و افزونههای غیرضروری را شناسایی کنید و پس از بررسی وابستگیها کنار بگذارید.
اصلاحات امنیتی را بیدلیل عقب نیندازید. برای تغییرات مهم، سازگاری را در محیط آزمایشی بررسی و مسیر بازگشت را مشخص کنید. ویرایش مستقیم فایل قالب والد میتواند هنگام بهروزرسانی از بین برود؛ این مشکل را با رهاکردن دائمی قالب قدیمی حل نکنید.
حسابها و حداقل دسترسی لازم
برای هر همکار حساب جدا بسازید و فقط اختیارات مورد نیاز کارش را بدهید. نویسندهٔ مقاله معمولاً به مدیریت افزونهها یا تنظیمات سایت نیاز ندارد. راهنمای نقشهای وردپرس تفاوت نویسنده، ویرایشگر و مدیر را توضیح میدهد؛ افزونههای فروشگاهی نیز میتوانند نقشهای دیگری اضافه کنند.
پس از پایان همکاری، دسترسی را بازبینی کنید و مالکیت محتوا را با دقت منتقل کنید. رمز طولانی و یکتا را در مدیر رمز معتبر نگه دارید؛ رمز واقعی را در ابزار ناشناس تولید یا بررسی نکنید. برای مدیران، احراز هویت دومرحلهای و مسیر بازیابی قابلاعتماد در نظر بگیرید.
HTTPS چه چیزی را محافظت میکند؟
HTTPS ارتباط مرورگر و سرور را با TLS محافظت میکند؛ در گفتار رایج هنوز از اصطلاح SSL استفاده میشود. گواهی معتبر، تمدید درست و نبود محتوای مختلط را بررسی کنید. گواهی میتواند رایگان یا پولی باشد و پرداخت هزینه شرط ذاتی رمزگذاری نیست.
این لایه جلوی اجرای افزونهٔ آسیبپذیر، سرقت حساب از دستگاه آلوده یا انتشار محتوای مخرب توسط مدیر متخلف را نمیگیرد. برای اتصال مدیریت و انتقال فایل نیز روش امن و مورد پشتیبانی میزبان را انتخاب کنید.
Wordfence و Sucuri چه تفاوتی دارند؟
| ابزار | نقش و محدودیت |
|---|---|
| Wordfence Free | فایروال در سطح سایت، اسکن و ابزارهای ورود؛ قواعد و امضاهای جدید با تأخیر نسبت به نسخهٔ پولی میرسند. |
| Sucuri Security | پایش رخداد، بررسی یکپارچگی فایل و اسکن بیرونی؛ فایروال ابری و خدمات پولی را باید جدا از افزونهٔ رایگان بررسی کرد. |
طبق توضیح Wordfence Free، قواعد فایروال و امضاهای بدافزار با تأخیر ۳۰روزه ارائه میشوند؛ بنابراین دو نسخه را تقریباً یکسان ندانید. اسکن نیز معادل بررسی تضمینی همهٔ فایلها پیش از آپلود نیست.
صفحهٔ رسمی Sucuri قابلیتهای افزونه و پیشنهاد پولی را جدا معرفی میکند. اسکن بیرونی همهٔ فایلها و دیتابیس خصوصی سرور را نمیبیند. هیچکدام تضمین نمیکنند تمام حملههای آینده پیشبینی یا تمام ردپاها همیشه حفظ شوند.
کپچا، محدودیت ورود و پایش
محدودیت تلاش ورود و کپچا میتوانند سوءاستفادهٔ خودکار را کم کنند، اما جای وصلهٔ امنیتی یا کنترل دسترسی را نمیگیرند. تنظیم بسیار سخت ممکن است کاربران واقعی پشت یک IP مشترک را قفل کند. خطاهای ورود، تغییر مدیران و تغییر غیرمنتظرهٔ فایلها را با زمینهٔ رخداد بررسی کنید.
چند ابزار همپوشان را بدون نیاز فعال نکنید؛ تداخل فایروال، کش و محدودیت ورود میتواند عیبیابی را دشوار کند. انتخاب ابزار باید با منابع هاست و توان نگهداری تیم تناسب داشته باشد.
بازیابی و رسیدگی به رخداد
تناوب پشتیبانگیری را با میزان تغییر داده تعیین کنید و بازیابی را آزمایش کنید. نسخهای که کنار سایت آلوده و با همان دسترسی نگهداری میشود ممکن است همزمان آسیب ببیند. هنگام رخداد، علت نفوذ، حسابها و نسخهٔ سالم داده را بررسی کنید؛ صرفاً بازگرداندن ظاهر سایت کافی نیست. راهنمای امنسازی وردپرس مبنای تکمیل این برنامه است.
مطالعهٔ مرتبط
بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شدهاند.