چرا سایت هک می‌شود؟ دسترسی سرقت‌شده، آسیب‌پذیری نرم‌افزار، پیکربندی نامناسب یا آلوده‌شدن محیط مدیریت می‌تواند مسیر نفوذ ایجاد کند. کوچک‌بودن سایت مصونیت نمی‌آورد؛ بعضی حمله‌ها به‌صورت خودکار سایت‌های آسیب‌پذیر را پیدا می‌کنند و به شهرت برند وابسته نیستند.
هدف مهاجم همیشه تغییر صفحهٔ اصلی نیست
سرقت داده، ارسال هرزنامه، میزبانی صفحهٔ فیشینگ، استخراج رمزارز یا افزودن محتوای اسپم از هدف‌های ممکن است. ممکن است ظاهر صفحهٔ اصلی عادی بماند. همچنین حملهٔ اختلال سرویس الزاماً به معنی ورود مهاجم به پنل یا تغییر فایل‌ها نیست.
قرارگرفتن لینک اسپم در سایت، انتقال قطعی رتبه به مهاجم را ثابت نمی‌کند. برای مالک، مسئلهٔ عملی این است که محتوایی بدون مجوز منتشر شده و علت این تغییر باید پیدا شود؛ حذف همان لینک، پایان بررسی نیست.
چرا سایت هک می‌شود؟ مسیرهای رایج
- رمز تکراری، افشای اطلاعات ورود یا تأیید یک درخواست جعلی.
- هسته، افزونه یا قالب دارای آسیب‌پذیری اصلاح‌نشده.
- فایل نصب دست‌کاری‌شده یا افزونه‌ای با منبع نامعتبر.
- دسترسی بیش از نیاز، حساب رهاشده یا کلید افشاشده.
- نبود جداسازی کافی میان برنامه‌های یک حساب میزبانی.
دو سایت روی یک سرور الزاماً به فایل‌های یکدیگر دسترسی ندارند. مرز حساب، مالکیت فایل و مجوزها تعیین‌کننده‌اند. در مقابل، چند نصب با دسترسی مشترک ممکن است دامنهٔ یک رخداد را بزرگ‌تر کنند؛ جزئیات سرویس را از میزبان بپرسید.
نشانه را با اثبات اشتباه نگیریم
مدیر ناشناس، تغییر غیرمجاز محتوا، ریدایرکت ناخواسته و ارسال ایمیل غیرعادی نیاز به رسیدگی دارند. اما کندی، افت بازدید یا شکست ورود به‌تنهایی هک را ثابت نمی‌کند. خطای افزونه، محدودیت منابع یا تنظیم اشتباه ایمیل هم می‌تواند نشانهٔ مشابه بسازد.
لاگ وب معمولاً درخواست و اطلاعات فنی را ثبت می‌کند؛ هر IP را نمی‌توان مستقیماً به یک شخص نسبت داد. زمان و منطقهٔ زمانی رخداد، URL، تغییر اخیر و نمونهٔ پیام خطا را کنار هم بگذارید تا بررسی بر اساس شواهد باشد.
پیشگیری عملی برای سایت وردپرسی
نسخه‌های پشتیبانی‌شده را از منبع رسمی نصب کنید و به‌روزرسانی‌های امنیتی را پیگیری کنید. حساب هر همکار جدا و دسترسی او متناسب با کار باشد. رمز یکتا و احراز هویت چندعاملی، به‌ویژه برای ایمیل بازیابی و پنل میزبان، اهمیت دارد. راهنمای احراز هویت OWASP چند لایهٔ دفاعی را توضیح می‌دهد.
CAPTCHA فقط می‌تواند بعضی سوءاستفاده‌های خودکار را کاهش دهد؛ آسیب‌پذیری افزونه را ترمیم نمی‌کند. HTTPS از ارتباط محافظت می‌کند و تضمین سلامت کد نیست. تغییر نام کاربری admin یا پیشوند جدول هم جای اصلاح آسیب‌پذیری و کنترل دسترسی را نمی‌گیرد.
مجوز 400 برای تمام فایل‌های تنظیمات نسخهٔ عمومی نیست و ممکن است برنامه را از کار بیندازد. مالکیت و روش اجرای سرویس باید لحاظ شود. راهنمای امنیت وردپرس را با شرایط واقعی میزبان تطبیق دهید و از اعمال دستورهای یکسان روی همهٔ پوشه‌ها خودداری کنید.
اگر احتمال نفوذ جدی است
شواهد را ثبت و دامنهٔ آسیب را با میزبان مشخص کنید. دسترسی غیرمجاز، فایل و محتوای تغییرکرده و راه ورود باید بررسی شوند. نسخهٔ بازیابی را از نظر سلامت ارزیابی کنید و رمزها و نشست‌های درگیر را از محیط سالم رسیدگی کنید. پشتیبان قابل بازیابی، پایش تغییرات و مسئول مشخص برای به‌روزرسانی، روند نگهداری را کامل می‌کنند.
مطالعهٔ مرتبط
بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.
