حملات بروت فورس تلاش‌های تکراری برای حدس زدن اطلاعات ورود هستند. مهاجم ممکن است تعداد زیادی رمز را برای یک حساب امتحان کند؛ اما موفقیت این تلاش به طول و یکتایی رمز، محدودیت ورود، احراز هویت چندمرحله‌ای و وضعیت سرویس بستگی دارد. برای شکستن همه رمزها نمی‌توان یک زمان ثابت اعلام کرد.
در این راهنما، تفاوت Brute Force با حملات مشابه و روش‌های دفاع و واکنش در سایت و وردپرس را مرور می‌کنیم. بازبینی فنی: ۲۷ مهر ۱۴۰۵.
بروت فورس با استفاده از رمزهای لو‌رفته فرق دارد
در حدس‌زدن آنلاین، سرویس ورود می‌تواند تلاش‌ها را ثبت و محدود کند. این وضعیت با حالتی که مهاجم فایل هش رمزها را به دست آورده و خارج از سایت روی آن کار می‌کند متفاوت است. بنابراین مقایسه سرعت کارت گرافیک با تعداد درخواست مجاز فرم ورود، نتیجه معتبری نمی‌دهد.
- حدس رمز برای یک حساب: تعداد زیادی گزینه برای همان کاربر آزمایش می‌شود.
- Password Spraying: چند رمز رایج روی حساب‌های متعدد امتحان می‌شود.
- Credential Stuffing: ترکیب نام کاربری و رمز افشاشده از سرویس دیگر، دوباره استفاده می‌شود.
نکته عملی برای صاحب سایت این است که فقط «قوی بودن» رمز کافی نیست. اگر همان رمز در چند سرویس استفاده شود، افشای یک سرویس می‌تواند دیگر حساب‌ها را نیز در معرض خطر قرار دهد. محدودیت صرفاً مبتنی بر IP هم برای درخواست‌های توزیع‌شده کافی نیست.
پیشگیری از حملات بروت فورس با چند لایه دفاع
رمز طولانی و منحصربه‌فرد انتخاب کنید
برای هر سرویس رمز مستقلی بسازید و از مدیر رمز معتبر برای تولید و نگهداری آن استفاده کنید. نام سایت، شماره تماس و الگوهای قابل حدس انتخاب مناسبی نیستند. در طراحی سامانه ورود، بررسی رمزهای رایج و افشاشده از تکیه بر ترکیب اجباری چند نماد مفیدتر است.
راهنمای NIST برای رمز تک‌عاملی حداقل ۱۵ نویسه را مقرر می‌کند و برای رمزِ بخشی از احراز هویت چندعاملی حداقل ۸ نویسه را می‌پذیرد. این اعداد به معنی امن بودن هر رمز با آن طول نیستند. همچنین تغییر دوره‌ایِ اجباری بدون نشانه افشا توصیه نمی‌شود؛ هنگام شواهد نفوذ یا افشای رمز، تغییر آن ضروری است.
احراز هویت چندمرحله‌ای را فعال کنید
برای مدیران سایت، پنل میزبانی و ایمیل بازیابی، عامل دوم را در اولویت بگذارید. در صورت پشتیبانی سرویس، گزینه‌های مقاوم در برابر فیشینگ مانند کلید امنیتی یا Passkey را ارزیابی کنید. همه روش‌های دومرحله‌ای در برابر فیشینگ مقاومت یکسانی ندارند.
کدهای بازیابی را در محل خصوصی نگه دارید و مسیر بازیابی حساب را پیش از نیاز واقعی بررسی کنید. تصویر QR راه‌اندازی، کلید مخفی و کدهای بازیابی را در آموزش عمومی یا تیکت غیرضروری نفرستید. اضافه کردن عامل دوم بدون برنامه بازیابی ممکن است مدیر اصلی را هم از حساب خارج کند.
سرعت تلاش‌های ورود را محدود کنید
محدودیت باید با رفتار حساب و منبع درخواست هماهنگ باشد. تأخیر تدریجی و محدودیت‌های متناسب، انتخاب بهتری از قفل دائمی و کورکورانه هستند. سیاست را طوری طراحی کنید که مهاجم نتواند صرفاً با چند تلاش ناموفق، حساب کاربران واقعی را از دسترس خارج کند.
پشت CDN یا پراکسی، تشخیص IP واقعی باید با پیکربندی مورد اعتماد میزبان انجام شود. اتکا به هدر دلخواه کاربر یا مسدود کردن یک IP اشتراکی می‌تواند هم دفاع را بی‌اثر کند و هم کاربران سالم را گرفتار کند. ابتدا یک سیاست محدود را آزمایش و سپس اثر آن را پایش کنید.
نکات دفاعی ویژه وردپرس
همه مدیران به حساب مشترک نیاز ندارند. برای هر فرد حساب مستقل با حداقل دسترسی لازم در نظر بگیرید و دسترسی افراد خارج‌شده از تیم را پس از بررسی مالکیت محتوا لغو کنید. قالب‌ها و افزونه‌های پشتیبانی‌شده را به‌روز نگه دارید؛ نام کاربری غیرمعمول به‌تنهایی جای این کنترل‌ها را نمی‌گیرد.
فقط صفحه ورود مرورگر را نبینید. اگر ابزار انتشار، برنامه موبایل یا یکپارچه‌سازی از روش دیگری وارد می‌شود، همان مسیر نیز باید در ارزیابی امنیت حضور داشته باشد. پیش از غیرفعال کردن XML-RPC یا دسترسی یک ابزار، وابستگی‌های واقعی را ثبت و روی محیط آزمایشی بررسی کنید. شکستن اتصال لازم کسب‌وکار، معیار موفقیت امنیت نیست.
تغییر نشانی ورود می‌تواند بخشی از نویز ربات‌ها را کم کند، اما یک عامل احراز هویت نیست. همچنین کپچا یک مانع کمکی است، نه تضمین جلوگیری از حمله. کاربرد آن را با دسترس‌پذیری فرم و تجربه کاربران واقعی متعادل کنید.
نشانه‌های حمله و واکنش به ورود مشکوک
افزایش ورودهای ناموفق، قفل‌شدن غیرعادی حساب‌ها یا ورود موفق ناشناس را پیگیری کنید. تعداد بالای خطا به‌تنهایی اثبات نفوذ نیست؛ رخدادها را با تاریخ، حساب و تغییرات بعدی تطبیق دهید. رمز، کد یک‌بارمصرف و کلید خصوصی را داخل گزارش امنیتی ثبت نکنید.
- شواهد رخداد و زمان آن را نگه دارید و دسترسی به گزارش‌ها را محدود کنید.
- با حساب و دستگاه مورد اعتماد، نشست‌ها و دسترسی‌های ناشناس را بررسی و لغو کنید.
- رمزهای درگیر و کلیدهای افشاشده را از مسیر امن جایگزین کنید و تنظیمات عامل دوم را بازبینی کنید.
- کاربران مدیریتی، فایل‌ها و تغییرات محتوا را بررسی کنید؛ تغییر رمز به‌تنهایی کد مخرب احتمالی را حذف نمی‌کند.
- پس از اصلاح علت، ورود عادی و بازیابی حساب را آزمایش و هشدارهای امنیتی را پایش کنید.
آیا فایروال به‌تنهایی کافی است؟
خیر. کنترل لبه، حفاظت حساب و امنیت برنامه مکمل یکدیگرند. قاعده‌ای که برای فرم ورود وب ساخته شده، لزوماً از همه سرویس‌های سرور محافظت نمی‌کند. هیچ افزونه یا سرویس واحدی را بدون بررسی محدوده پوشش، تضمین توقف همه حملات بروت فورس ندانید.
برای اجرای لایه دوم ورود، راهنمای احراز هویت دومرحله‌ای وردپرس را ببینید و هنگام نصب، روش پشتیبانی‌شده و سازگار با نسخه فعلی سایت را انتخاب کنید.
منابع: احراز هویت در OWASP، پیشگیری از Credential Stuffing، امنیت احراز هویت چندعاملی و NIST SP 800-63B-4.
