آموزش گام‌به‌گام جلوگیری از حملهٔ بروت‌فورس

حملهٔ بروت‌فورس حملهٔ پیچیده‌ای نیست؛ حملهٔ ارزانی است. ربات‌ها شبانه‌روز صفحهٔ ورود هزاران سایت را امتحان می‌کنند و هزینهٔ هر تلاش برای مهاجم تقریباً صفر است؛ برای همین همه سایت‌ها را امتحان می‌کنند، نه فقط سایت‌های معروف را. خبر خوب این است که همین ارزانی، نقطهٔ ضعف مهاجم است: هر لایه‌ای که تلاش‌ها را گران کند، موج حمله را به سایت بعدی می‌فرستد. این راهنما چهار لایه را به ترتیب می‌چیند و برای بدترین روز، نقشهٔ واکنش را هم کنار می‌گذارد.

حملهٔ بروت‌فورس چیست و چرا وردپرس هدف ثابت است؟

بروت‌فورس یعنی امتحان‌کردن نام کاربری و رمز عبور، بارها و بارها، تا باز شدن قفل. در وردپرس این حمله تقریباً همیشه یک آدرس را هدف می‌گیرد: صفحهٔ ورود و رابط xmlrpc که بعضی افزونه‌ها روشن نگه می‌دارند. مهاجم دو شکل کار می‌کند: حدس کورکورانهٔ رمز برای یک کاربر، و حدسِ لیستی — همان چند رمز ضعیف معروف که روی ده‌ها نام کاربری امتحان می‌شوند. شکل دوم ساده‌تر تشخیص داده می‌شود و شکل اول سخت‌تر؛ هر دو با همان لایه‌های این راهنما مهار می‌شوند.

چرا وردپرس؟ چون سهم بزرگ یعنی آدرس شناخته‌شده: مهاجم می‌داند صفحهٔ ورود کجاست و لازم نیست دنبالش بگردد. این امتیازِ مهاجم، هم‌زمان امتیاز شماست: دفاع استاندارد، برای همان آدرس استاندارد نوشته شده است. یک تفکیک صادقانه هم لازم است: بروت‌فورس حملهٔ اعتبارنامه است، نه حملهٔ نرم‌افزاری؛ نفوذ از مسیر افزونهٔ قدیمی و آسیب‌پذیر مسیر دیگری است که آیین آموزش گام‌به‌گام آپدیت وردپرس جداگانه باز کرده — دو مسیر مکمل‌اند و هیچ‌کدام جای دیگری را نمی‌گیرد.

جلوگیری از حمله brute force با دفاع لایه‌ای؛ نقشهٔ کلی

منطق دفاع لایه‌ای ساده است: هر لایه، یک شکست را خنثی می‌کند. لایهٔ اول مطمئن می‌شود رمز قابل حدس نیست؛ لایهٔ دوم مطمئن می‌شود تلاش‌های بی‌پایان به عدد محدود می‌رسند و ثبت می‌شوند؛ لایهٔ سوم موج حمله را پیش از رسیدن به سایت، در سطح میزبان و فایروال خفه می‌کند؛ و لایهٔ چهارم حتی با درست‌حدس‌شدن رمز، در ورود دومرحله‌ای متوقف می‌شود. هیچ لایه‌ای «کافی» نیست؛ ترکیب است که ادامهٔ حمله را بی‌صرفه می‌کند و مهاجم حرفه‌ای هزینه را می‌فهمد.

ترتیب اجرا هم مهم است: از داخل به بیرون. اول اعتبارنامه‌ها را درست کنید — یک روز کار دارد و بیشترین بازده را می‌دهد — بعد محدودسازی و پایش را فعال کنید، بعد قوانین میزبان و فایروال را بچینید و در پایان ورود دومرحله‌ای را برای همهٔ مدیران اجباری کنید. تیم‌هایی که ترتیب را برعکس اجرا می‌کنند، معمولاً در لایهٔ سوم هزینه می‌کنند و رمز ضعیفِ مدیر اصلی را زیر فایروال گران پنهان نگه می‌دارند؛ نتیجه، حس امنیت است نه امنیت.

لایهٔ اول؛ بهداشت اعتبارنامه‌ها و مدیریت کاربران

لایهٔ اول سه قاعده دارد و هر سه در یک روز اجرا می‌شوند. اول، نام کاربری «admin» حذف یا بی‌اثر شود: این نام در لیست امتحانِ همهٔ ربات‌هاست؛ کاربر مدیر با نام دیگری بسازید و حساب قدیمی را مدیرِ محتوایی کنید یا حذف کنید. دوم، رمزها طولانی و یکتا باشند: رمز مدیر از مدیریت رمز عبور بیاید، نه از حافظه؛ رمزِ تکرارشده در سرویس دیگری، رمز امن نیست. سوم، دسترسی حداقلی: هر نقش فقط دسترسی‌ای که لازم دارد بگیرد و نویسنده‌ها، مدیر کل نباشند — مدیریت نقش‌ها همان‌جایی است که اکثر نفوذها از داخل ساده می‌شوند.

بهداشت اعتبارنامه یک‌بار انجام نمی‌شود؛ فهرست کاربران را هر ماه مرور کنید: چه کسانی مدیرند؟ چه کسانی بیایند و رفتند؟ حساب‌های بی‌صاحب را همان روز ببندید. این مرور ده دقیقه است و بیشترین جلوی داخل‌سوختن را می‌گیرد؛ به تجربهٔ ما در بازسازی سایت‌های آلوده، رایج‌ترین قدمِ جاافتاده همین مرور ماهانهٔ کاربران بوده است، نه کمبود ابزار گران.

لایهٔ دوم؛ محدودسازی و پایش تلاش‌های ورود

لایهٔ دوم حمله را از «بی‌پایان» به «محدود و ثبت‌شده» می‌برد. حداقل‌ها: محدود کردن تلاش ورود — مثلاً چند تلاش ناموفق و بعد وقفهٔ زمانی برای همان آدرس؛ افزودن کپچای ملایم برای جلوی ربات‌های ساده؛ و ثبت لاگ تلاش‌های ورود شامل آدرس IP، نام کاربری امتحان‌شده و زمان. پایش همین لاگ‌هاست که لایه را زنده نگه می‌دارد: مرور هفتگی تلاش‌های ناموفق نشان می‌دهد موج از کجا می‌آید و چه نام‌های کاربری‌ای هدف‌اند — همان داده‌ای که تصمیم‌های لایهٔ سوم را می‌سازد.

دو نکتهٔ اجرایی: حد محدودسازی را جایی بگذارید که خودتان و کاربران واقعی را قفل نکند — قفل اضافه‌سخت، همان جاست که تیم از آن دور می‌زند و درِ پشتی نیمه‌باز می‌سازد؛ و برای تیم‌های ثابت با IP مشخص، اجازهٔ ورود فقط از آن آدرس‌ها جدی‌ترین صرفهٔ موجود است. اگر لاگ ورود ناگهان خالی یا بی‌نظم شد، مشکوک باشید؛ لاگ پاک‌شده، خودش یک سیگنال است و باید همان روز بررسی شود، نه هفتهٔ بعد.

لایهٔ سوم؛ فایروال و دفاع در سطح میزبان

لایهٔ سوم حمله را قبل از رسیدن به وردپرس می‌گیرد. در سطح میزبان، پنل‌های جدی امکان مسدودسازی خودکار IPهای تکرارکننده، حفاظت اختصاصی روی صفحهٔ ورود و محدود کردن xmlrpc را می‌دهند؛ اگر افزونه‌ای از xmlrpc استفاده نمی‌کند، مسدودکردنش کل یک مسیر حمله را می‌بندد. فایروال وب (WAF) یک لایه بالاتر می‌نشیند و قاعده‌های عمومی مثل محدودسازی نرخ درخواست روی صفحهٔ ورود را قبل از سایت اجرا می‌کند؛ شبکهٔ توزیع محتوا هم می‌تواند قواعد لبه‌ای برای همان آدرس بگذارد.

دو قاعده برای این لایه: اول، هر قاعدهٔ سخت‌گیری که اضافه می‌کنید را با مسیر واقعی خودتان تست کنید — قاعده‌ای که ورود اضطراری خودتان را می‌بندد، در روز حادثه گران تمام می‌شود؛ دوم، این لایه را با میزبان هماهنگ کنید، نه به تنهایی: اکثر هاست‌ها حفاظت آماده دارند که فقط باید فعال شود، و دوباره‌سازی آن به‌صورت دستی، فقط پشتی تکراری می‌سازد. اگر می‌خواهید این لایه‌ها بدون دست‌وپنجه نرم‌کردن با تنظیمات، در سطح پلتفرم اجرا شوند، صفحهٔ امنیت و زیرساخت سوئیت همان ترکیب را نشان می‌دهد.

لایهٔ چهارم؛ ورود دومرحله‌ای و نقشهٔ واکنش پس از نفوذ

ورود دومرحله‌ای بزرگ‌ترین پرش این راهنماست: حتی با رمزِ درستِ حدس‌خورده، ورود کامل نمی‌شود. برای همهٔ مدیران اجباری‌اش کنید، برای نویسنده‌ها هم فعال باشد و کدهای بازیابی را جایی امن و بیرون از همان دستگاه نگه دارید — کد بازیابیِ گم‌شده، مدیر را در روز تعطیلی میزبان قفل می‌کند. اگر اپلیکیشن احراز هویت برای تیم سخت است، حداقل برای حساب‌های مدیر، پیامکی هم از هیچ بودن بهتر است؛ اما اپلیکیشن استاندارد ماست.

و نقشهٔ واکنش برای روزی که همه‌چیز مشکوک است: اول، دسترسی‌ها را از یک دستگاه سالم عوض کنید — رمزها، نه از داخل همان سایت مشکوک؛ دوم، سایت را در حالت نگهداری بگذارید تا مهاجم کارش را ادامه ندهد؛ سوم، آخرین بکاپ سالمِ پیش از نفوذ را بازیابی کنید — روتین بکاپ منظم وردپرس همین روز را می‌سازد — و چهارم، بعد از پاک‌سازی، روند کامل بازگشت را در بازیابی سایت هک‌شده دنبال کنید: اسکن، عوض‌کردن نمک‌های امنیتی و مرور کاربران. مهم‌ترین قاعدهٔ این نقشه پیش‌نویس‌بودن آن است: نقشه‌ای که در کشوی ذهن باشد، در روز حادثه وجود ندارد.

ریتم پایش ماهانه و جمع‌بندی

چهار لایه با ریتم زنده می‌مانند. ماهانه: مرور فهرست کاربران و نقش‌ها، مرور لاگ تلاش‌های ورود، چک سلامت ورود دومرحله‌ای و مرور قواعد فایروال. فصلی: تست نقشهٔ واکنش — یک بازی کوتاه که بدانید بکاپ کجاست، چه کسی بازیابی را اجرا می‌کند و مسیر عوض‌کردن رمزها چقدر طول می‌کشد. این ریتم بیست دقیقه در ماه است و همان چیزی است که دفاع را از یک نصب یک‌باره به وضعیت پایدار می‌برد؛ دفاعی که مرور ندارد، با هر تغییر تیم و هر افزونهٔ تازه، سوراخ تازه می‌گیرد.

جمع‌بندی: بهداشت اعتبارنامه‌ها، محدودسازی و پایش ورود، دفاع میزبان و فایروال، ورود دومرحله‌ای و نقشهٔ واکنش — چهار لایه و یک ریتم. با لایهٔ اول همین امروز شروع کنید؛ بقیه را در دو هفته بچینید. اگر خواستید این وضعیت برای دامنهٔ خودتان از بیرون سنجیده شود، ممیزی رایگان دامنه نقطهٔ شروع کم‌ریسکی است و ادامهٔ مسیر نگهداری — از بکاپ تا بازیابی — در هاب امنیت و پشتیبان‌گیری نوشته شده است. به تجربهٔ ما سایت‌هایی که این ریتم را دارند، روز حادثه را با برگه مدیریت می‌کنند و بقیه با هیجان؛ تفاوت دو حالت، همان بیست دقیقهٔ ماهانه است.

رصد ما، رشد شما.