مقایسهٔ افزونه‌های امنیتی وردپرس؛ کدام برای شما مناسب است؟
- مقایسهٔ افزونه‌های امنیتی وردپرس با سه کلاس ابزار
- کلاس اول؛ دیوار آتش روی سطح درخواست
- کلاس دوم؛ اسکنر بدافزار و پایش یکپارچگی فایل
- کلاس سوم؛ بستههای سختسازی و قفل‌های مدیریتی
- چهار معیار مقایسه؛ هشدار کاذب، بار منابع، پوشش و بازیابی
- واقعیت هاست ایرانی؛ منابع محدود و آستانهٔ تحمل
- جدول تصمیم؛ کدام کلاس برای شما مناسب است؟
- جمع‌بندی؛ نصب کمتر، پایش منظم
وردپرس تقریباً ۴۳ درصد از کل وب را قدرت می‌دهد (W3Techs، تاریخ گردآوری: آبان ۱۴۰۵) و همین محبوبیت، آن را هدف پرتکرار اسکن‌های خودکار و تلاش‌های ورود قرار می‌دهد. سمت مقابل، بازار افزونه‌های امنیتی شلوغ است: صفحهٔ هر محصول فهرستی از قابلیت‌ها می‌چیند و درصد و عدد می‌دهد، اما هیچ‌کدام نمی‌گویند برای سایت شما کدام کلاس ابزار واقعاً لازم است. نتیجه، الگوی آشنایی است؛ چند افزونهٔ هم‌پوشان هم‌زمان نصب می‌شود، منابع هاست پر می‌شود و سایت کندتر از قبل به کار ادامه می‌دهد.
در مقایسهٔ بهترین افزونه‌های امنیتی از دید نیاز، انتخاب را از سمت نیازها بستیم؛ این‌جا از سمت ابزار می‌آییم و سه کلاس اصلی را می‌شکافیم تا بدانید هر کلاس چه میکند، چه نمی‌کند و چه هزینه‌ای روی کارایی می‌گذارد. نقشهٔ کامل این مقایسه‌ها در هاب افزونهها و ابزارهای وردپرس کنار هم نشسته است. اگر نمی‌دانید وضعیت فعلی دامنه‌تان کجاست، ممیزی رایگان دامنه نقطهٔ شروع داده‌محور است.
مقایسهٔ افزونه‌های امنیتی وردپرس با سه کلاس ابزار
سه کلاس ابزار امنیتی در بازار وردپرس مرز روشنی دارند. کلاس اول، دیوار آتش، درخواست‌ها را پیش از رسیدن به کد اصلی سایت می‌سنجد و قانونهای بد را دور می‌ریزد. کلاس دوم، اسکنر، فایل‌های سایت را با نسخهٔ سالم مقایسه میکند و تغییر مشکوک و فایل تزریق‌شده را گزارش می‌دهد. کلاس سوم، بستهٔ سختسازی، کارش باز کردن قفل‌های پیش‌فرض خطرناک است؛ محدودسازی تلاش ورود، بستن ویرایشگر فایل و سخت‌گیری پیکربندی.
چرا کلاس و نه اسم؟ چون اسم‌ها هر سال عوض می‌شوند و کلاس‌ها می‌مانند. افزونه‌ای که امروز دیوار آتش پرادعا است، سال بعد جذب یا متروک می‌شود؛ اما درخواستِ «فیلتر درخواست پیش از کد» ثابت است. هر افزونهٔ امنیتی هم معمولاً ترکیبی از چند کلاس را در خود دارد و همین ترکیب‌ها مقایسه را گیج میکند؛ وقتی کلاس‌ها را جدا کنید، می‌توانید بگویید دقیقاً برای کدام لایه پول و منابع می‌دهید و کدام لایه را با ابزار دیگری پوشش می‌دهید.
کلاس اول؛ دیوار آتش روی سطح درخواست
دیوار آتش (WAF) سطح درخواست را نگه می‌دارد: درخواست‌های شناخته‌شدهٔ مخرب، الگوهای تزریق و موج تلاش ورود را پیش از آن‌که به PHP و دیتابیس برسند رد میکند. برای الگوی رایج تلاش‌های ورود دسته‌جمعی، این کلاس اولین سپر است؛ سناریوی کامل و تنظیم قفل‌ها را در آموزش گام‌به‌گام جلوگیری از حملهٔ بروت‌فورس باز کرده‌ایم و دیوار آتش همان جا لایهٔ جلویی می‌شود. به تجربهٔ ما همین پیش‌فیلتر است که فشار ورودهای خودکار را پیش از رساندن به سرور کم میکند، چون درخواست ردشده هزینهٔ اجرای کد ندارد.
مرز این کلاس را هم باید صادقانه گفت: قانونهای دیوار آتش عمومی‌اند و منطق کسب‌وکار شما را نمی‌شناسند. فرم چندمرحله‌ای، درگاه بانکی یا جستجوی پیشرفته‌ای که الگوی عجیب دارد، می‌تواند قربانی قانون سخت‌گیر شود. سخت‌گیریِ زیاد یعنی کاربر واقعیِ ردشده؛ سست بودن یعنی عبور درخواست مخرب. تنظیم درست بین این دو، دقیقاً همان معیار «هشدار کاذب» است که در ادامه با آن مقایسه می‌کنیم.
کلاس دوم؛ اسکنر بدافزار و پایش یکپارچگی فایل
اسکنر کلاس دوم، فایل‌های سایت را با مرجع سالم می‌سنجد: امضای بدافزارهای شناخته‌شده، مقایسهٔ فایل‌های هسته با نسخهٔ رسمی و هشدار روی تغییرهای بی‌منبع. خروجی این کلاس گزارش است؛ لیستی از فایل‌های مشکوک، تغییرهای عجیب در پوشه‌های حساس و وضعیت قرارگرفتن دامنه در فهرست‌های سیاه. برای سایت‌هایی که چند نفر در آن‌ها دست می‌زنند یا افزونه‌های کم‌به‌روز نصب دارند، این پایش تفاوت «نفوذ خاموش چندماهه» و «کشف در هفتهٔ اول» را می‌سازد.
مرز مهم این کلاس: اسکنر تشخیصی است، نه پیشگیرانه. فایلی که اسکن می‌شود، قبلاً وارد سایت شده است؛ پاک‌سازی خودِ فایل و ریشه‌کنی ورودی، کار دست متخصص است و گزارش تنها نقطهٔ شروع آن است. به تجربهٔ ما اسکن تمام‌سایت روی هاست اشتراکی باید برنامه‌دار باشد، نه روزانه؛ اسکن کامل هر هفته یا هر دو هفته در ساعات کم‌ترافیک، پوشش کافی می‌دهد بدون آن‌که آستانهٔ منابع را بشکند.
خواندن خروجی اسکنر هم مهارت میخواهد، نه فقط اجرای آن. هشدار روی فایل هسته را با نسخهٔ رسمی مقایسه کنید، تغییر در پوشهٔ آپلودها را جدی بگیرید و گزارش «فهرست سیاه دامنه» را با سرویس‌های مختلف چک کنید. گزارشی که هر هفته بی‌پاسخ بماند، فقط کاغذ است؛ برای هر نوع هشدار، پاسخ مشخص و مسئول مشخص تعریف کنید تا پایش به چرخهٔ واقعی امنیت تبدیل شود.
کلاس سوم؛ بستههای سختسازی و قفل‌های مدیریتی
بستههای سختسازی کارشان بستن درهای پیش‌فرض است: محدودسازی تلاش‌های ناموفق ورود، تأیید دومرحله‌ای برای مدیران، تغییر آدرس صفحهٔ ورود، غیرفعال‌کردن ویرایشگر فایل در پیشخوان و افزودن هدرهای امنیتی. این کلاس کم‌سروصداترین است، چون خروجی روزانه‌ای به شما نشان نمی‌دهد؛ اثرش در اتفاقی است که رخ نمی‌دهد. شش لایهٔ دفاعی این مسیر را در شش لایهٔ دفاعی ایمن‌سازی صفحه ورود وردپرس قدم‌به‌قدم باز کرده‌ایم و بستهٔ سختسازی همان لایه‌ها را یک‌جا اعمال میکند.
مزیت پنهان این کلاس، هزینهٔ تقریباً صفر روی کارایی است؛ چون کارش تنظیم پیکربندی است نه پردازش ترافیک. به تجربهٔ ما در سایت‌های کوچک و متوسط، بخش بزرگی از ریسک واقعی همین‌هاست: رمز ضعیف مدیر، ورود بدون تأیید دومرحله‌ای و ویرایشگر فایلِ باز. این سه را با هر ابزاری می‌توانید ببندید؛ پس برای شروع، وزن بودجه و منابع را به کلاس‌های دیگر ندهید و سختسازی را پایهٔ ثابت نگه دارید.
یک خطای رایج هم در استفاده از این کلاس دیده می‌شود: قفل‌ها را سخت می‌بندید و بعد برای راحتی روزمره، همان قفل‌ها را باز می‌گذارید. تغییر آدرس ورود بدون بهروزرسانی سرویس‌های متصل، یا تأیید دومرحله‌ای که برای «یکی دو روز» خاموش می‌شود، دقیقاً همان دری است که حمله از آن می‌آید. قاعدهٔ ما ساده است: هر قفلی که باز می‌شود، باید تاریخ بازشدن و دلیلش ثبت شود.
چهار معیار مقایسه؛ هشدار کاذب، بار منابع، پوشش و بازیابی
معیار اول، هشدار کاذب است: ابزاری که هر روز ده‌ها هشدار بیاثر می‌دهد، بعد از دو هفته از دید تیم می‌افتد و ارزش گزارشش صفر می‌شود. سنجش را روی دو هفتهٔ فقط ثبت بگذارید؛ اگر نسبت هشدار بیاثر به هشدار عملیاتی نامعقول بود، آن ابزار با تنظیم درست هم جور نمی‌شود. معیار دوم، بار منابع است: دیوار آتش برای هر درخواست پردازش میخواهد و اسکنر برای هر اجرا پردازش؛ این بار را باید با اندازهٔ هاست خودتان بسنجید، نه با ادعای صفحهٔ فروش.
معیار سوم، پوشش است: کدام کلاس‌ها را در بر میگیرد و کجاها را خالی می‌گذارد؛ دو ابزار با پوشش هم‌پوشان، دفاع را بیشتر نمی‌کنند، فقط گزارش را شلوغ می‌کنند. معیار چهارم، مسیر بازیابی است: اگر نفوذ کامل شود، ابزار چه کمکی به بازگشت سریع میکند؟ نسخهٔ پشتیبانِ مرتب و تستشده، جواب بخش بزرگی از این معیار است و خارج از افزونه باید حل شود. هزینهٔ لایسنس سالانهٔ کلاس‌های مختلف در بازار، بازهٔ برآورد بازارِ گسترده‌ای دارد و به تجربهٔ ما باید با هزینهٔ منابع سرور سنجیده شود، چون ابزار سنگین روی پلن ارزان، هزینهٔ ارتقا هاست را به صورت غیرمستقیم به قبض اضافه میکند.
واقعیت هاست ایرانی؛ منابع محدود و آستانهٔ تحمل
بخش بزرگی از سایت‌های وردپرسی ایران روی پلنهای اشتراکی با حافظه و پردازش محدود اجرا می‌شوند و این واقعیت، مقایسه را از صفحات فروش جدا میکند. ترکیب دیوار آتش سنگین، اسکنر همیشگی و چند ماژول گزارش‌گیری، در چنین پلنی به‌سرعت به مرز مصرف منابع می‌رسد و علامتش را در سرعت سایت می‌بینید. به تجربهٔ ما ترتیب درست برای پلنهای پایین این است: اول سختسازی، بعد دیوار آتش سبک با قانونهای ضروری، و اسکنر دورهای موضعی؛ چون این ترتیب بیشترین کاهش ریسک را با کمترین بار منابع می‌دهد.
این حرف، ضد ابزار کامل نیست؛ برای فروشگاه‌های پرترافیک یا سایت‌های خبری با ده‌ها انتشار روزانه، دیوار آتش قوی روی زیرساخت مناسب، تصمیم درستی است. تفاوت در تطبیق است: کلاسِ سنگین روی زیرساخت سنگین، کلاسِ سبک روی زیرساخت سبک. پیش از نصب، سقف منابع پلن هاست را بنویسید و بعد ترکیب را انتخاب کنید؛ همین یک قدم، بیشترین دعواهای «سایت کند شد» را پیشگیری میکند.
جدول تصمیم؛ کدام کلاس برای شما مناسب است؟
| سناریوی شما | ترکیب پیشنهادی | نکتهٔ اجرا |
|---|---|---|
| وبلاگ یا سایت شرکتی کوچک روی هاست اشتراکی | سختسازی پایه + دیوار آتش سبک + اسکن هفتگی موضعی | قانونهای دیوار را حداقلی نگه دارید؛ اسکن را ساعات کم‌ترافیک بگذارید |
| فروشگاه اینترنتی با درگاه پرداخت | سختسازی کامل + دیوار آتش تنظیم‌شده + اسکن دورهای | منطقهٔ پرداخت را از هشدار کاذب آزمایش کنید؛ پشتیبان روزانه اجباری است |
| سایت عضویت‌محور با چند مدیر | سختسازی + تأیید دومرحله‌ای + پایش یکپارچگی | گزارش تغییر فایل‌ها را به یک مسئول مشخص گره بزنید |
| سایت پرترافیک روی سرور اختصاصی | دیوار آتش کامل + اسکنر منظم + سختسازی | قانونها را مرحله‌ای سخت‌گیر کنید و اثر سرعت را هم‌زمان رصد کنید |
ترکیب‌ها نقطهٔ شروع‌اند، نه نسخهٔ ثابت. بعد از دو هفتهٔ فقط ثبت، سخت‌گیری را با گزارش واقعی تنظیم کنید؛ آیا هشدارها عملیاتی‌اند یا فقط گزارش را شلوغ می‌کنند؟
جدول را با یک قاعده بخوانید: اول زیرساخت، بعد کلاس. اگر سناریوی شما بین دو ردیف است، از ردیف سبکتر شروع کنید و با گزارش واقعی سنگین‌ترش کنید؛ بازگشت از ترکیب سنگین به سبک، همیشه سخت‌تر از اضافه‌کردن است. چهار پرسش تصویر بالا را هم پیش از هر نصب جواب بدهید تا تصمیم، به عادت «افزونهٔ بعدی» تبدیل نشود.
جمع‌بندی؛ نصب کمتر، پایش منظم
جمعِ مقایسه در سه جمله است: کلاس‌ها رقیب هم نیستند، لایه‌های مکمل‌اند؛ هیچ ابزاری جای بهروزرسانی منظم، رمز درست و پشتیبان تستشده را نمیگیرد؛ و بهترین ترکیب، ترکیبی است که با منابع هاست شما دوام بیاورد. هر سه ماه یک‌بار همین چهار معیار را روی ترکیب فعلی اجرا کنید: هشدار کاذب، بار منابع، پوشش و بازیابی. اگر یکی از آن‌ها قرمز شد، جای آن لایه را با کلاس دیگری پر کنید یا قانونها را دوباره تنظیم کنید؛ تصمیم امنیتی، تصمیم یک‌بارِ برای همیشه نیست.
برای دیدن اینکه رصد منظم و انتشار محتوای سالم چطور در یک پنل جمع می‌شود، قابلیت‌های پلتفرم رصد و انتشار را ببینید. اگر هم قدم بعدی برایتان مشخص نیست، ممیزی رایگان دامنه را اجرا کنید تا تصمیم امنیتی بعدی، داده‌محور گرفته شود نه حدسی. کدام کلاس برای شما مناسب است، در نهایت با گزارش ممیزی جواب میگیرد، نه با تبلیغ صفحهٔ فروش.
رصد ما، رشد شما.
سؤالات پرتکرار
آیا یک افزونهٔ امنیتی همهکاره کافی است؟
به تجربهٔ ما برای شروع، یک بستهٔ سختسازی پایه بههمراه دیوار آتش سبک کفایت میکند؛ اسکنر را میتوان هفتگی و موضعی اجرا کرد تا بار سرور بالا نرود. ابزار دوم را فقط وقتی اضافه کنید که گزارش کلاس اول، خلأ مشخصی نشان دهد.
هشدارهای کاذب را چطور کم کنیم؟
دو هفته ابزار را فقط روی حالت ثبت بگذارید و بعد قانونها را با گزارش واقعی سخت یا سست کنید. به تجربهٔ ما همین توقف کوتاه، نسبت هشدار بیاثر را بهشکل محسوس پایین میآورد و اعتماد تیم را به گزارش برمیگرداند.
روی هاست اشتراکی کدام کلاس سبکتر است؟
بستههای سختسازی و اسکنرِ موضعی سبکتریناند؛ چون کارشان تنظیم و بررسی دورهای است نه پردازش هر درخواست. دیوار آتش با قانونهای زیاد، حافظه و پردازش بیشتری میخواهد و در پلنهای پایین، آستانهٔ منابع را میفشارد.
افزونهٔ امنیتی جای پشتیبانگیری و بهروزرسانی را میگیرد؟
خیر؛ بهروزرسانی منظم هسته و افزونهها و نسخهٔ پشتیبان تستشده، پایهٔ دفاع هستند و افزونه لایهٔ روی این پایه است. کلاس سوم (سختسازی) همین پایه را قفل میکند، اما هیچ ابزاری جای نسخهٔ پشتیبانِ مرتب را نمیگیرد.
