Fail2ban و مسئله تکرار خطاهای ورود
Fail2ban ابزار متن‌بازی برای مشاهده گزارش سرویس‌ها و واکنش به الگوهای تکرارشونده نامطلوب است. نمونه شناخته‌شده، تلاش‌های ناموفق ورود به SSH است. ابزار رخدادهای متناسب با فیلتر را پیدا می‌کند و پس از رسیدن به آستانه تعیین‌شده، عملیاتی مانند مسدود کردن موقت نشانی مبدأ انجام می‌دهد. این فرایند با خود سامانه احراز هویت تفاوت دارد: Fail2ban تصمیم نمی‌گیرد گذرواژه درست است یا نه؛ نتیجه ثبت‌شده توسط سرویس را می‌خواند و بر اساس آن واکنش نشان می‌دهد.
کاربرد آن برای مدیر لینوکس زمانی ارزشمند است که گزارش معتبر، رفتار قابل تشخیص و محل مناسبی برای اعمال محدودیت وجود داشته باشد. صرف نصب بسته باعث محافظت خودکار از همه برنامه‌ها نمی‌شود. باید مشخص شود کدام سرویس بررسی می‌شود، خطای مربوط در کجا ثبت می‌شود، نشانی واقعی کارخواه چگونه استخراج می‌شود و عملیات مسدودسازی کدام مسیر شبکه را پوشش می‌دهد. اگر یکی از این حلقه‌ها اشتباه باشد، ابزار ممکن است بی‌اثر بماند یا کاربر مجاز را محدود کند.
README رسمی نیز روشن می‌گوید کاهش نرخ تلاش‌های ناموفق، خطر احراز هویت ضعیف را از بین نمی‌برد. استفاده از کلید عمومی، احراز هویت چندعاملی و محدود کردن دسترسی مدیریتی همچنان اهمیت دارد. مهاجمی که از اعتبارنامه معتبر استفاده کند الزاماً خطای قابل شمارش ایجاد نمی‌کند. بنابراین Fail2ban باید به عنوان یک کنترل مکمل ارزیابی شود و معیار موفقیت آن کاهش یک رفتار مشخص باشد؛ نه ادعای جلوگیری از تمام نفوذها.
Jail از چه اجزایی تشکیل می‌شود؟
واژه jail در این ابزار به مجموعه‌ای از تنظیمات گفته می‌شود که منبع گزارش، فیلتر تشخیص و عملیات واکنش را به هم پیوند می‌دهد. فیلتر مشخص می‌کند چه رخدادی شکست محسوب شود و اطلاعات مورد نیاز از متن گزارش چگونه استخراج شود. عملیات تعیین می‌کند پس از رسیدن به شرط، چه کاری انجام شود. این عملیات می‌تواند تغییر قواعد دیواره آتش باشد و در برخی پیکربندی‌ها کارهای دیگری نیز تعریف شود. خواندن دقیق تنظیمات بسته نصب‌شده برای فهم نتیجه ضروری است.
سه گزینه مهم maxretry، findtime و bantime باید در کنار هم فهمیده شوند. گزینه نخست تعداد شکست لازم را تعیین می‌کند، گزینه دوم بازه زمانی بررسی شکست‌ها را مشخص می‌کند و گزینه سوم مدت محدودیت را تعیین می‌کند. برای مثال شمارش پنج شکست در ده دقیقه با پنج شکست در یک روز یک سیاست نیست. انتخاب عددها باید بر رفتار سرویس، تعداد کاربران و هزینه محدود شدن اشتباه مبتنی باشد. نمونه موجود در مستندات، توصیه یکسان برای تمام سازمان‌ها محسوب نمی‌شود.
زمان محدودیت نیز به تنهایی نشان‌دهنده قدرت دفاع نیست. یک مبدأ مشترک ممکن است نماینده صدها کاربر باشد و مسدودسازی طولانی آن هزینه زیادی ایجاد کند. از سوی دیگر محدودیت بسیار کوتاه می‌تواند رفتار تکراری را به اندازه کافی کاهش ندهد. بهتر است ابتدا در دامنه کوچک، آمار شکست و خطای تشخیص جمع‌آوری شود. سپس آستانه‌ها با شواهد تغییر کنند و دلیل هر تغییر در کنار تنظیمات ثبت شود.
دریافت و شناسایی نسخه نصب‌شده
پروژه در مخزن رسمی خود نصب از بسته‌های توزیع لینوکس را معرفی می‌کند و کد منبع را نیز در اختیار می‌گذارد. برای محیط عملیاتی، مسیر دریافت باید با رویه نگه‌داری سازمان هماهنگ باشد. نسخه بسته توزیع ممکن است با شاخه توسعه مخزن متفاوت باشد؛ بنابراین نمونه‌ای که از شاخه اصلی خوانده می‌شود باید با راهنمای نسخه نصب‌شده تطبیق داده شود. شماره نمایش‌داده‌شده در README شاخه توسعه را نباید به عنوان آخرین انتشار پایدار اعلام کرد.
پس از نصب، پیش از تغییر سیاست شبکه می‌توان دسترسی به ابزار و راهنمای آن را بررسی کرد. فرمان وضعیت به سرویس در حال اجرا وابسته است و ممکن است برای دسترسی به سوکت مدیریتی به مجوز نیاز داشته باشد. این تفاوت را با نصب نبودن برنامه اشتباه نگیرید.
fail2ban-client -h
fail2ban-client version
sudo fail2ban-client status
خروجی نسخه، محل تنظیمات و روش اجرای سرویس را در پرونده استقرار ثبت کنید. بعضی توزیع‌ها تنظیمات پیش‌فرض و عملیات دیواره آتش را تغییر می‌دهند. هدف این بررسی آن است که تیم بداند دقیقاً چه چیزی اجرا می‌شود، نه اینکه فقط نام بسته در فهرست نرم‌افزارها دیده شود. همچنین مسئول دریافت اصلاحات و بازبینی پس از ارتقای سیستم‌عامل باید مشخص باشد.
تنظیم محلی را از فایل بسته جدا کنیم
فایل نمونه رسمی توصیه می‌کند تنظیمات اختصاصی در jail.local یا فایل مناسب زیر jail.d نگه‌داری شوند. ویرایش مستقیم jail.conf می‌تواند در به‌روزرسانی بعدی باعث از دست رفتن تغییرات یا دشوار شدن مقایسه با پیش‌فرض‌ها شود. بهتر است فقط گزینه‌های مورد نیاز را در فایل محلی بازنویسی کنید. کپی کامل یک فایل بزرگ، نگه‌داری را دشوار می‌کند زیرا گزینه‌های قدیمی را نیز همراه خود حفظ می‌کند.
پیش از فعال کردن jail مربوط به SSH، مسیر دسترسی اضطراری را آماده کنید. یک نشست مدیریتی باز جای کنسول مستقل و برنامه بازگشت را به طور کامل نمی‌گیرد. آزمون را با مبدأ آزمایشی جداگانه انجام دهید تا نشانی مدیریت ناخواسته مسدود نشود. این احتیاط بخشی از اجرای تغییر شبکه است؛ خصوصاً روی سروری که تنها راه دسترسی آن همان سرویس تحت بررسی است.
نمونه زیر صرفاً شکل چند گزینه را نشان می‌دهد. نام jail، backend، منبع گزارش و عملیات مناسب باید از بسته نصب‌شده و محیط واقعی بررسی شوند. پیش از فعال‌سازی، تنظیمات را با ابزار و راهنمای همان نسخه اعتبارسنجی کنید.
[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 10m
این نمونه تضمین نمی‌کند همه نصب‌های SSH با همین چهار خط درست کار کنند. اگر سرویس روی درگاهی غیرمعمول اجرا می‌شود، عملیات مسدودسازی نیز باید همان مسیر را پوشش دهد. نام سرویس، مکان گزارش و مدیر دیواره آتش در توزیع‌های مختلف یکسان نیستند. فعال شدن jail را از مؤثر بودن واکنش روی ارتباط واقعی جداگانه آزمایش کنید.
فایل گزارش و journal مسیرهای متفاوت‌اند
Fail2ban می‌تواند با backendهای مختلف داده گزارش را دریافت کند. در حالت خواندن فایل، مسیر و مجوز خواندن آن اهمیت دارد. در حالت systemd، ابزار از journal استفاده می‌کند و به اجزای لازم برای این اتصال نیاز دارد. فایل رسمی jail.conf تصریح می‌کند که گزینه logpath برای backend نوع systemd معتبر نیست و تطبیق journal باید در تنظیمات مربوط بررسی شود. ترکیب تصادفی نمونه‌های این دو مسیر می‌تواند ابزار را از رخداد واقعی دور کند.
برای تشخیص منبع مناسب، ابتدا یک خطای ورود کنترل‌شده با حساب آزمایشی ایجاد کنید و ببینید سرویس دقیقاً چه چیزی ثبت می‌کند. زمان، نام فرایند و نشانی مبدأ را بررسی کنید. سپس مطمئن شوید همان رخداد به Fail2ban می‌رسد. مشاهده گزارش قدیمی یا فایل خالی برای تأیید مسیر کافی نیست. چرخش فایل‌های گزارش، تغییر قالب پس از ارتقا و قطع جریان جمع‌آوری نیز باید در پایش دیده شوند.
در محیط‌های کانتینری، محل گزارش و محل دیواره آتش ممکن است دو فضای متفاوت باشند. خواندن گزارش داخل کانتینر الزاماً اجازه تغییر قواعد میزبان را فراهم نمی‌کند. از سوی دیگر دادن دسترسی گسترده شبکه به کانتینر فقط برای رفع سریع خطا، تصمیم معماری مهمی است. محل اجرای ابزار را با مسیر عبور واقعی بسته‌ها و مدل مجوز سرویس هماهنگ کنید.
نشانی واقعی کارخواه پشت پراکسی
در سرویس پشت پراکسی یا متوازن‌کننده بار، نشانی دیده‌شده توسط برنامه ممکن است متعلق به پراکسی باشد. اگر همان نشانی مسدود شود، همه کاربران عبوری از آن مسیر آسیب می‌بینند. پیش از تعریف فیلتر باید روشن باشد کدام فیلد گزارش هویت شبکه‌ای کارخواه را نشان می‌دهد و چه مؤلفه‌ای آن را نوشته است. یک سرآیند قابل جعل توسط کاربر نباید بدون زنجیره اعتماد مشخص، مبنای مسدودسازی دیگران قرار گیرد.
حتی استخراج درست نشانی واقعی هم همیشه کافی نیست. اگر بسته‌ای که به میزبان می‌رسد همچنان مبدأ پراکسی دارد، قاعده محلی مبتنی بر نشانی اصلی ممکن است هیچ بسته‌ای را نگیرد. محل اعمال محدودیت باید با معماری سازگار باشد؛ شاید تصمیم باید در همان لایه پراکسی اعمال شود. این انتخاب را با راهنمای اجزای شبکه انجام دهید و از موفقیت ثبت یک ban در گزارش، مؤثر بودن آن را نتیجه نگیرید.
فهرست استثنا و خطر اعتماد گسترده
گزینه ignoreip برای مستثنا کردن نشانی‌ها یا محدوده‌های تعریف‌شده به کار می‌رود. این امکان می‌تواند برای مسیر مدیریت ثابت مفید باشد، اما افزودن یک شبکه بزرگ تنها برای کاهش تماس‌های پشتیبانی، سطح کنترل را کم می‌کند. هر استثنا باید مالک، دلیل و زمان بازبینی داشته باشد. اگر نشانی مدیریت تغییر می‌کند، فرایند اصلاح استثنا نیز باید مشخص باشد تا تیم میان قطع دسترسی و گسترش بی‌قاعده اعتماد گرفتار نشود.
نشانی مشترک خروجی سازمان یا اپراتور اینترنت هویت یک فرد نیست. چند خطای یک کاربر ممکن است محدودیت را برای کاربران دیگر همان نشانی فعال کند. این واقعیت به ویژه برای سرویس عمومی مهم است. بررسی خطای تشخیص باید علاوه بر شمار رخداد، اثر بر کاربران واقعی را بسنجد. جایی که هزینه مسدودسازی اشتباه زیاد است، کنترل در سطح حساب یا خود برنامه ممکن است مکمل مناسب‌تری باشد.
آزمون تشخیص و آزمون واکنش
آزمون فیلتر باید شامل نمونه مثبت و منفی باشد. نمونه مثبت یک خطای واقعی است که انتظار داریم شمارش شود؛ نمونه منفی رخدادی مجاز یا نامرتبط است که نباید به محدودیت منجر شود. ابزار fail2ban-regex برای بررسی تطبیق گزارش و فیلتر در مجموعه پروژه وجود دارد. پیش از استفاده، نحو آن را از راهنمای نسخه نصب‌شده بخوانید و نمونه‌های فاقد راز را به کار ببرید. هدف صرفاً رسیدن به تعداد تطبیق بیشتر نیست، بلکه درست بودن موارد تطبیق است.
سپس واکنش واقعی را با مبدأ آزمایشی بررسی کنید. وضعیت jail را بخوانید، وجود محدودیت را در لایه مربوط مشاهده کنید و تلاش اتصال جدید را از همان مبدأ بسنجید. پس از پایان مدت، برداشته شدن محدودیت نیز باید آزمایش شود. شکست هر مرحله معنای متفاوتی دارد: ممکن است تشخیص درست باشد ولی عملیات خطا دهد، یا قاعده ساخته شود اما در مسیر ترافیک قرار نگیرد.
sudo fail2ban-client status sshd
برای بازبینی رخداد، زمان شروع، jail درگیر، مبدأ، دلیل تشخیص و نتیجه عملیات را نگه دارید. گزارش‌ها ممکن است نام کاربری و اطلاعات شبکه داشته باشند؛ دسترسی و دوره نگه‌داری آن‌ها باید متناسب باشد. ارسال خودکار همه خطوط گزارش به سرویس بیرونی را بدون بررسی محتوای آن فعال نکنید. پایش باید به خطای اجرای عملیات و توقف دریافت گزارش نیز توجه کند.
نگه‌داری و معیار پذیرش
پس از ارتقای SSH، وب‌سرور یا قالب گزارش، نمونه‌های آزمون را دوباره اجرا کنید. فیلتر درست دیروز ممکن است دیگر رخداد امروز را تشخیص ندهد. همچنین تغییر مدیر دیواره آتش یا جابه‌جایی سرویس به کانتینر می‌تواند مسیر واکنش را عوض کند. نگه‌داری شامل بررسی دوره‌ای استثناها، آستانه‌ها و خطاهای عملیات است؛ نه فقط اطمینان از زنده بودن فرایند.
معیار آماده بودن این است که رخداد مورد نظر از منبع درست خوانده شود، مبدأ درست استخراج شود، آستانه با سیاست سازگار باشد و محدودیت در جای مناسب اعمال و برداشته شود. همزمان دسترسی مجاز و مسیر بازیابی باید باقی بمانند. با چنین آزمونی Fail2ban می‌تواند تکرار رفتار نامطلوب را کاهش دهد و حجم کار دستی مدیر را کمتر کند. ارزش آن از اتصال دقیق گزارش به اقدام می‌آید و به کیفیت همان دو بخش وابسته است.
