آموزش نصب و تنظیم Fail2ban در Ubuntu 24.04

عملکرد واقعی Fail2ban

Fail2ban یک دیمون (daemon) برای خواندن لاگ‌ها است. این ابزار پیام‌های احراز هویت SSH شما را پایش می‌کند و پس از چند تلاش ناموفق از یک آدرس مشخص در یک بازهٔ زمانی کوتاه، یک دستور فایروال اجرا می‌کند که آن آدرس را برای مدتی مسدود می‌سازد. کل ایدهٔ این ابزار همین است. پیکربندی آن تنها حدود 30 خط در یک فایل است و در Ubuntu 24.04، نصب آن با یک دستور apt انجام می‌شود که پیش از ویرایش هر فایلی، شما را تحت محافظت قرار می‌دهد.

دقیقاً بدانید که این ابزار چیست و چه کاری انجام نمی‌دهد. Fail2ban هیچ‌کس را احراز هویت نمی‌کند، چیزی را رمزنگاری نمی‌کند و حتی یک تلاش برای ورودِ مصمم را متوقف نمی‌سازد؛ بلکه تنها تلاش‌های مکرر از یک منبع واحد را مسدود می‌کند. این ابزار یک فیلتر نویز و محدودکنندهٔ نرخ (rate limiter) است، نه یک قفل. وظیفهٔ آن این است که از هدر رفتن CPU، پهنای باند و فضای لاگ شما توسط اسکن‌های مداوم پس‌زمینه روی پورت 22 جلوگیری کند و سرعت هر مهاجمی را که مجبور است از یک آدرس در هر لحظه حمله کند، کاهش دهد.

آنچه Fail2ban جایگزین آن نمی‌شود

Fail2ban لایه سوم دفاعی است، نه لایه اول. اگر سرور شما همچنان رمز عبور SSH را می‌پذیرد، یک بات‌نت که در هزاران آدرس پخش شده است می‌تواند به حدس زدن ادامه دهد؛ زیرا هر آدرس زیر آستانه مسدودسازی شما باقی می‌ماند و هرگز باعث فعال شدن آن نمی‌شود. دفاع واقعی در برابر این حملات، احراز هویت فقط با کلید (key-only authentication) است که حدس زدن رمز عبور را بدون توجه به تعداد تلاش‌ها، غیرممکن می‌کند. استفاده از Fail2ban در کنار احراز هویت با کلید، دو کار مفید انجام می‌دهد: نویز حملات brute-force را از لاگ‌های شما حذف می‌کند و اسکنرها را در مراحل اولیه بیرون می‌اندازد تا از کوبیدن مداوم به پورت دست بردارند. به آن به عنوان دفاع در عمق نگاه کنید. این ابزار پشت احراز هویت با کلید و پشت فایروال قرار می‌گیرد و هرگز نباید جلوی آن‌ها باشد.

پیش‌نیازها و واقعیت Ubuntu 24.04

شما به یک VPS با سیستم‌عامل Ubuntu 24.04 نیاز دارید که دسترسی root یا sudo داشته باشد و SSH آن از قبل، ترجیحاً با احراز هویت کلید (key authentication)، فعال باشد. Fail2ban بسیار کم‌مصرف است: تنها چند ده مگابایت رم اشغال می‌کند و نیازی به تنظیم محدودیت‌ها (tuning) ندارد.

اکنون به بخشی می‌رسیم که اکثر راهنماهای قدیمی در آن اشتباه می‌کنند. سال‌ها توصیه استاندارد این بود که «Fail2ban را نصب کنید و سپس backend = systemd را اضافه کنید، زیرا Ubuntu دیگر /var/log/auth.log را نمی‌نویسد.» این توصیه فقط در برخی ایمیج‌ها صادق است. یک سرور Ubuntu 24.04 استاندارد یا ایمیج ابری (cloud image) همچنان rsyslog را نصب می‌کند که قوانین پیش‌فرض آن، auth,authpriv.* را در /var/log/auth.log می‌نویسد؛ بنابراین در اکثر VPSها، تلاش‌های ناموفق SSH هم در آن فایل و هم در systemd journal ثبت می‌شوند. ایمیج‌های مینیمال (ایمیج ابری مینیمال Ubuntu 24.04 بدون rsyslog عرضه می‌شود) و اکثر کانتینرها، لاگ‌های SSH را فقط در journal ثبت می‌کنند و در آنجا فایل متنی واقعاً وجود ندارد. در هر صورت، در Ubuntu 24.04 بسته Fail2ban این موضوع را لحاظ کرده است. این بسته فایل /etc/fail2ban/jail.d/defaults-debian.conf را اضافه می‌کند و سرور شما در واقع از این فایل استفاده می‌کند، نه تنظیمات پیش‌فرض upstream:

[DEFAULT]
banaction = nftables
banaction_allports = nftables[type=allports]
backend = systemd

[sshd]
enabled = true

این فایل را با دقت بخوانید، زیرا پیش از آنکه تغییری ایجاد کنید، دو پرسش را پاسخ می‌دهد. backend = systemd به این معنی است که jail مربوط به SSH، لاگ‌ها را از journal می‌خواند، بنابراین فرقی نمی‌کند که ایمیج شما auth.log را می‌نویسد یا خیر. banaction = nftables به این معنی است که مسدودسازی‌ها (bans) از طریق nftables اعمال می‌شوند که فایروال واقعی مورد استفاده در Ubuntu 24.04 است، نه iptables قدیمی. و [sshd] enabled = true به این معنی است که jail از همان اولین بوت فعال است. نتیجه این است که یک apt install fail2ban استاندارد در Ubuntu 24.04، حملات brute-force به SSH را به‌صورت پیش‌فرض مسدود می‌کند. بیشتر کار شما تأیید این موضوع، تنظیم سیاست‌ها و اطمینان از این است که خودتان را از سرور قفل نکنید.

تله قدیمی auth.log هنوز در سه موقعیت مشکل‌ساز می‌شود و شناخت آن‌ها ارزشمند است: شما Fail2ban را با pip به جای apt نصب کرده‌اید، بنابراین defaults-debian.conf وجود ندارد؛ شما داخل یک کانتینر بدون دسترسی (unprivileged) هستید که systemd journal برای خواندن ندارد؛ یا از یک راهنمای قدیمی پیروی کرده‌اید و backend = auto را در jail.local خود کپی کرده‌اید که باعث نادیده گرفته شدن تنظیمات پیش‌فرضِ صحیح می‌شود. حالت اول و سوم فقط در ایمیج‌هایی که فاقد rsyslog هستند (مانند ایمیج‌های مینیمال) باعث از کار افتادن مسدودسازی SSH می‌شوند، زیرا در جایی که rsyslog اجرا می‌شود، backend فایل، /var/log/auth.log را پیدا کرده و کار می‌کند. بخش حالت‌های شکست (failure-modes) دقیقاً نشان می‌دهد که هر کدام از این موارد چگونه به نظر می‌رسند.

گام 1: نصب و تأیید عملکرد فعلی مسدودسازی

sudo apt update
sudo apt install -y fail2ban

نسخه Ubuntu 24.04 همراه با Fail2ban 1.0.2 عرضه می‌شود و این بسته، python3-systemd را به‌عنوان یک وابستگی اصلی نصب می‌کند؛ بنابراین backend ژورنال تمام پیش‌نیازهای لازم را در اختیار دارد. این سرویس به‌صورت خودکار فعال شده و شروع به کار می‌کند:

sudo systemctl status fail2ban

شما به active (running) نیاز دارید. سپس جِیلی (jail) را بررسی کنید که در حال انجام وظیفه است:

sudo fail2ban-client status sshd

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

گام 2: ویرایش jail.local، نه jail.conf

نرم‌افزار Fail2ban تنظیمات پیش‌فرض خود را در /etc/fail2ban/jail.conf نگهداری می‌کند. این فایل را ویرایش نکنید. همان‌طور که در سربرگ خود فایل هشدار داده شده است، ارتقای بسته می‌تواند آن را جایگزین کند و تغییرات شما از بین برود. Fail2ban فایل‌ها را به ترتیب مشخصی می‌خواند: ابتدا jail.conf، سپس jail.d/*.conf به ترتیب حروف الفبا، سپس jail.local، و در نهایت jail.d/*.local به ترتیب حروف الفبا؛ در این فرآیند، آخرین مقدار خوانده‌شده اعمال می‌شود. بنابراین jail.local تنظیمات defaults-debian.conf ارائه‌شده توسط بسته را بازنویسی می‌کند، اما هر فایلی با پسوند *.local که در jail.d/ قرار دهید، پس از آن خوانده شده و به نوبه خود تنظیمات قبلی را بازنویسی می‌کند؛ تغییرات خود را در یک مکان متمرکز نگه دارید تا بدانید کدام مقدار در حال اجراست. فایل .local متعلق به شماست و ارتقای بسته هرگز آن را تغییر نمی‌دهد. همین قانون در مورد فیلترها نیز صدق می‌کند، جایی که یک فایل *.local تنظیمات فایل filter.d/*.conf ارائه‌شده را بازنویسی می‌کند.

بنابراین، شما یک فایل jail.local کوچک می‌نویسید که فقط تعداد انگشت‌شماری از تنظیمات مورد نظر شما را بازنویسی می‌کند و هر دو فایل jail.conf و jail.d/defaults-debian.conf ارائه‌شده توسط بسته را به عنوان مرجع، دست‌نخورده باقی می‌گذارید.

گام 3: نوشتن فایل /etc/fail2ban/jail.local

sudo nano /etc/fail2ban/jail.local

محتوای زیر را در فایل قرار دهید و آدرس موجود در خط ignoreip را با آدرس IP عمومی خود جایگزین کنید:

[DEFAULT]
# Ubuntu 24.04 already sets these two in jail.d/defaults-debian.conf.
# Pinning them here documents the dependency and survives if that
# file is ever removed or changed by an upgrade.
backend   = systemd
banaction = nftables

# Ban for one hour ...
bantime  = 1h
# ... if an address fails ...
maxretry = 5
# ... 5 times within 10 minutes.
findtime = 10m

# Never ban these. PUT YOUR OWN IP HERE.
ignoreip = 127.0.0.1/8 ::1 10.0.0.24

# Longer bans for repeat offenders: 1h, 2h, 4h ... up to a week.
bantime.increment = true
bantime.maxtime   = 1w

[sshd]
enabled = true

هر خط در این پیکربندی هدف خاصی دارد:

• پارامترهای bantime، findtime و maxretry سیاست مسدودسازی را تعیین می‌کنند. مقدار پیش‌فرض bantime تنها ده دقیقه است؛ یک ساعت حداقل زمان منطقی‌تری محسوب می‌شود. پنج تلاش ناموفق از یک آدرس در مدت ده دقیقه منجر به مسدود شدن می‌شود. کاربران واقعی ممکن است یک یا دو بار رمز عبور را اشتباه وارد کنند، اما پنج خطا در ده دقیقه نشان‌دهنده فعالیت یک اسکریپت است.
• پارامتر ignoreip کمربند ایمنی شماست. آدرس عمومی که از آن متصل می‌شوید را اینجا وارد کنید تا Fail2ban هرگز شما را از سرور خودتان بیرون نیندازد. اگر اتصال خانگی شما IP متغیر دارد، بهتر است از روش VPN در انتهای آموزش استفاده کنید، نه اینکه این خط را نادیده بگیرید.
• پارامتر bantime.increment = true باعث می‌شود هر بار مسدودسازی مجدد، طولانی‌تر از قبل باشد (یک ساعت، سپس دو ساعت، چهار ساعت و تا سقف bantime.maxtime). آدرس‌هایی که به تلاش‌های خود ادامه می‌دهند، به‌طور تصاعدی مدت بیشتری مسدود می‌مانند.

برای پیدا کردن آدرسی که باید در لیست سفید قرار گیرد، از دستگاهی که با آن SSH می‌زنید استفاده کنید، نه از داخل سرور:

curl -s ifconfig.me

شما می‌توانید یک jail.local متناسب با پورت‌ها و سیاست مسدودسازی خود در اینجا تولید کرده و سپس آن را در فایل جای‌گذاری کنید:

گام 4: راه‌اندازی مجدد و تأیید خواندن ژورنال

sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

برنامه -t ابتدا یک تست پیکربندی انجام می‌دهد، بنابراین اگر در jail.local غلط تایپی وجود داشته باشد، سرویس به‌جای متوقف شدن، با خطا مواجه می‌شود. وضعیت یک jail سالم به این صورت است:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     14
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 1
   |- Total banned:     3
   `- Banned IP list:   203.0.113.66

عددی که ثابت می‌کند Fail2ban واقعاً در حال خواندن لاگ‌های ورود شماست، Total failed است. اگر این عدد بزرگ‌تر از صفر باشد، یا هنگام تلاش ناموفق عمدی برای ورود از دستگاهی دیگر افزایش یابد، یعنی ژورنال در حال خواندن است و کار شما تمام شده است. اگر با وجود چندین بار تلاش ناموفق، عدد همچنان 0 باقی ماند و مطمئن هستید که از آدرسی که در ignoreip ذکر شده تست نمی‌کنید، به بخش حالت‌های شکست در ادامه مراجعه کنید.

توجه داشته باشید که خط Journal matches همچنان به sshd.service اشاره دارد. در اوبونتو، واحد SSH در واقع ssh.service است، اما فیلتر پیش‌فرض با _COMM=sshd نیز مطابقت دارد و OpenSSH در نسخه 24.04 خطاهای خود را از فرآیندی به نام sshd ثبت می‌کند، بنابراین این تطبیق کار می‌کند. این جزئیات تنها در صورتی اهمیت دارد که از نسخه جدیدتر OpenSSH (نسخه 9.8 یا بالاتر، که در آن worker هر اتصال sshd-session نام دارد) استفاده می‌کنید؛ بخش حالت‌های شکست، این مورد را نیز پوشش می‌دهد.

گام 5: مشاهده اعمال یک مسدودسازی واقعی، یا تست آن با اعمال دستی

مسدودسازی‌های واقعی روی هر VPS عمومی، ظرف چند دقیقه به‌طور خودکار رخ می‌دهند. برای مشاهده یکی از آن‌ها، لاگ را دنبال کنید:

sudo tail -f /var/log/fail2ban.log

یک مسدودسازی به این شکل دیده می‌شود:

2026-07-15 10:31:40,502 fail2ban.filter  [812]: INFO    [sshd] Found 203.0.113.66 - 2026-07-15 10:31:40
2026-07-15 10:31:44,118 fail2ban.actions [812]: NOTICE  [sshd] Ban 203.0.113.66

برای اطمینان از عملکرد کامل مکانیزم بدون انتظار، یک آدرس مستندات را به‌صورت دستی مسدود کنید؛ هرگز آدرس خودتان را مسدود نکنید. 203.0.113.66 در محدوده TEST-NET-3 قرار دارد، بلوکی که برای مستندات رزرو شده است، بنابراین نمی‌تواند یک میزبان واقعی یا آدرس خصوصی در شبکه ارائه‌دهنده شما باشد:

sudo fail2ban-client set sshd banip 203.0.113.66

این دستور 1 را چاپ می‌کند و آدرس تحت Banned IP list در fail2ban-client status sshd ظاهر می‌شود. اکنون تأیید کنید که مسدودسازی واقعاً در فایروال وجود دارد. در Ubuntu 24.04 این ابزار nftables است، نه iptables:

sudo nft list table inet f2b-table

شما یک set با نام addr-set-sshd را خواهید دید که حاوی 203.0.113.66 است، و یک chain با نام f2b-chain که هر منبعی در آن set را رد (reject) می‌کند. اگر fail2ban-client می‌گوید یک آدرس مسدود شده است اما چیزی در nft list ظاهر نمی‌شود، action مسدودسازی شما با فایروال‌تان مطابقت ندارد؛ به یادداشت مربوط به nftables/iptables در بخش حالت‌های شکست (failure modes) مراجعه کنید.

گام 6: رفع مسدودیت خود و بازیابی دسترسی در صورت قفل شدن

اگر آدرس IP خود را به اشتباه مسدود کرده‌اید، آن را حذف کنید:

sudo fail2ban-client set sshd unbanip 203.0.113.66

این دستور در صورت موفقیت 1 را برمی‌گرداند. برای پاک کردن تمام مسدودیت‌ها از تمامی jailها:

sudo fail2ban-client unban --all

روی نشست SSH که از قبل باز است حساب نکنید: مسدودیت nftables تمام بسته‌های ارسالی از آدرس مسدودشده به پورت 22 را رد می‌کند، حتی برای اتصالات برقرار شده؛ بنابراین نشست فعلی به محض اعمال مسدودیت منجمد می‌شود. اگر خود را مسدود کردید و ورودی ignoreip ندارید، تا زمان انقضای مسدودیت قفل خواهید بود. برای بازیابی، از کنسول وب ارائه‌دهنده خود (VNC یا سریال) استفاده کنید که از مسیر SSH عبور نمی‌کند، و سپس یا منتظر بمانید تا bantime به پایان برسد یا دستور رفع مسدودیت را در همان‌جا اجرا کنید.

گام 7: تداوم مسدودسازی و تشدید آن

برنامه Fail2ban مسدودسازی‌های فعال را در یک پایگاه داده کوچک SQLite در مسیر /var/lib/fail2ban/fail2ban.sqlite3 نگهداری می‌کند، بنابراین این موارد پس از راه‌اندازی مجدد سرویس یا ریبوت سیستم باقی می‌مانند و از دست نمی‌روند. خطوط bantime.increment که قبلاً اضافه کردید، هر فرد متخلف تکراری را با مشکلی فزاینده مواجه می‌کند که زمان مسدودسازی آن تقریباً از یک ساعت به سمت یک هفته دوبرابر می‌شود.

برای اعمال یک سیاست کلی «سه اخطار» در سطح سیستم علاوه بر موارد فوق، Fail2ban یک jail به نام recidive ارائه می‌دهد که فایل لاگ /var/log/fail2ban.log خود را پایش کرده و به هر آدرس IP که به‌طور مکرر در تمام jailها مسدود شده باشد، محرومیت‌های طولانی‌مدت اعمال می‌کند. از آنجا که [DEFAULT] شما اکنون از backend سیستم‌عامل systemd استفاده می‌کند، این jail را مجدداً به فایل لاگی که برای خواندن آن طراحی شده است، متصل کنید:

[recidive]
enabled  = true
backend  = auto
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 5

استفاده از backend = auto به همراه logpath صریح، باعث می‌شود recidive همچنان فایل متنی ساده fail2ban.log را بخواند؛ این همان جایی است که خطوط Ban که برنامه آن‌ها را شمارش می‌کند ظاهر می‌شوند. تنظیم پیش‌فرض systemd که به‌صورت سراسری اعمال کردید، برنامه را به سمت journal هدایت می‌کند، در حالی که این خطوط در آنجا وجود ندارند.

گام 8: ترکیب با احراز هویت فقط با کلید SSH و ترجیحاً VPN

Fail2ban تنها در کنار احراز هویت مبتنی بر کلید کارایی واقعی خود را نشان می‌دهد. در یک فایل drop-in در مسیر /etc/ssh/sshd_config.d/، برای مثال /etc/ssh/sshd_config.d/00-hardening.conf، تنظیمات زیر را اعمال کنید:

PasswordAuthentication no
KbdInteractiveAuthentication no

سپس sudo systemctl restart ssh را اجرا کنید. با غیرفعال کردن رمز عبور، حملات brute force به‌هیچ‌وجه موفق نخواهند بود؛ در این حالت Fail2ban برای کاهش حجم لاگ‌ها و مسدودسازی زودهنگام اسکنرها عمل می‌کند. راهکار قوی‌تر این است که SSH را به‌طور کامل از اینترنت عمومی دور نگه دارید: SSH را پشت یک WireGuard VPN شخصی قرار دهید و پورت 22 را در فایروال مسدود کنید تا فقط از طریق تونل پاسخگو باشد. هیچ‌کس نمی‌تواند پورتی را که به آن دسترسی ندارد brute-force کند و Fail2ban در اینجا به عنوان یک لایه حفاظتی پشتیبان عمل می‌کند، نه خط مقدم دفاع.

Fail2ban فقط مختص SSH نیست. هر سرویسی که تلاش‌های ناموفق ورود را ثبت می‌کند، می‌تواند یک jail داشته باشد؛ مانند سرور ایمیل، سایت nginx یا مدیریت رمز عبور Vaultwarden شخصی که ترجیح می‌دهید صفحه ورود وب آن در برابر حملات credential stuffing باز نباشد. هنگامی که یک وب‌اپلیکیشن پشت یک سایت nginx با گواهی Let's Encrypt قرار گرفت، یک فیلتر Fail2ban را به همان شکلی که jail مربوط به SSH به journal اشاره می‌کند، به لاگ دسترسی (access log) آن سرویس متصل کنید.

حالت‌های شکست و پیام‌های خطای دقیق

پیام "Have not found any log file for sshd jail" و عدم اجرای Fail2ban. این یک مشکل قدیمی auth.log است و در Ubuntu 24.04 تنها زمانی با آن مواجه می‌شوید که /var/log/auth.log وجود نداشته باشد (مانند یک image مینیمال یا کانتینر که فاقد rsyslog است) و journal نیز خوانده نشود: یک نصب pip بدون defaults-debian.conf، یک کانتینر بدون journal، یا یک backend = auto اضافی که در jail.local کپی کرده‌اید. در backend فایل بدون /var/log/auth.log، جیل sshd نمی‌تواند فایل لاگ خود را پیدا کند و کل daemon متوقف می‌شود. دستور fail2ban.log این وضعیت را نشان می‌دهد:

ERROR   Failed during configuration: Have not found any log file for sshd jail

از آنجا که این خطا مهلک است، سرویس هرگز بالا نمی‌آید و fail2ban-client status سپس علامت ثانویه آن را گزارش می‌دهد:

ERROR  Failed to access socket path: /var/run/fail2ban/fail2ban.sock. Is fail2ban running?

آن خط "socket path" به این معنی نیست که Fail2ban خراب شده است؛ بلکه نشان می‌دهد سرویس هرگز شروع به کار نکرده چون یک جیل نتوانسته لاگ خود را پیدا کند. تنظیم backend = systemd در [DEFAULT]، که پکیج Ubuntu به‌صورت پیش‌فرض برای شما انجام می‌دهد، هر دو پیام را هم‌زمان رفع می‌کند.

جیل فعال است اما Total failed تغییر نمی‌کند. دیمون در حال اجراست و journal خوانده می‌شود، اما شکست‌های واقعی در journalctl -u ssh انباشته می‌شوند در حالی که شمارنده روی 0 باقی مانده است. ابتدا موارد بدیهی را بررسی کنید: ممکن است در حال تست از آدرسی باشید که در ignoreip لیست شده است، بنابراین شکست‌های شما طبق طراحی نادیده گرفته می‌شوند. اگر مشکل این نیست، شما از نسخه‌ای از OpenSSH استفاده می‌کنید که worker هر اتصال در آن sshd-session است (نسخه 9.8 و بالاتر)؛ در این نسخه، _COMM مربوط به journal برابر با sshd-session است، نه sshd، بنابراین الگوی پیش‌فرض آن را شناسایی نمی‌کند. الگو را در بلوک [sshd] گسترش دهید:

[sshd]
enabled      = true
backend      = systemd
journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd + _COMM=sshd-session

سرویس را ری‌استارت کنید، از آدرسی که در ignoreip نیست عمداً یک لاگین ناموفق انجام دهید و تأیید کنید که Total failed بالاخره افزایش می‌یابد.

خودتان را بن کردید: Connection refused. آدرس خود را در ignoreip قرار نداده‌اید، چند لاگین ناموفق را تست کرده‌اید و اکنون:

ssh: connect to host 10.0.0.10 port 22: Connection refused

این امتناع (refusal) به جای یک timeout بی‌صدا، نتیجه عملکرد پیش‌فرض reject در اکشن nftables است که وظیفه خود را روی شما انجام می‌دهد. طبق مرحله 6 مشکل را حل کنید: از یک نشست دیگر با آدرسی که بن نشده است یا از طریق کنسول ارائه‌دهنده، بن را لغو کنید (نشستی که از قبل با آدرس بن‌شده باز بوده نیز فریز می‌شود). سپس آدرس خود را به ignoreip اضافه کنید تا دیگر این اتفاق تکرار نشود.

Fail2ban می‌گوید آدرسی بن شده، اما همچنان می‌تواند وصل شود. شمارنده در status sshd افزایش می‌یابد، اما آدرس همچنان به پورت 22 دسترسی دارد. این یک عدم تطابق بین ban-action و فایروال است و در Ubuntu 24.04 تقریباً همیشه به این معنی است که شما banaction = nftables پیش‌فرض را با banaction = iptables-multiport که از یک راهنمای قدیمی کپی کرده‌اید جایگزین کرده‌اید، آن هم روی سیستمی که لایه iptables ندارد. دستور fail2ban.log این را نشان می‌دهد:

fail2ban.actions [812]: ERROR  Failed to execute ban jail 'sshd' action 'iptables-multiport'

آن جایگزینی را حذف کنید و اجازه دهید اکشن پیش‌فرض nftables عمل کند، یا اگر فایروال را کاملاً از طریق ufw مدیریت می‌کنید و می‌خواهید بن‌ها در آنجا نمایش داده شوند، banaction = ufw را در [DEFAULT] تنظیم کنید. سرویس را ری‌استارت کرده و با sudo nft list ruleset | grep f2b تأیید کنید که قانون مربوطه ظاهر شده است.

Fail2ban پس از ویرایش jail.local اجرا نمی‌شود. یک غلط تایپی، یک سرتیتر اضافی یا یک مقدار زمانی اشتباه باعث می‌شود سرویس از اجرا خودداری کند. از Fail2ban بخواهید پیش از اجرا، پیکربندی را بررسی کند:

sudo fail2ban-client -t

این دستور فایل و جِیلی که مشکل دارد را نام می‌برد، برای مثال Errors in jail 'sshd'. Skipping...، بنابراین به جای حدس زدن، مستقیماً منبع مشکل را اصلاح می‌کنید.

FAQ

آیا نصب پیش‌فرض Fail2ban روی Ubuntu 24.04 واقعاً حملات SSH را مسدود می‌کند؟

بله. این بسته شامل /etc/fail2ban/jail.d/defaults-debian.conf است که jail مربوط به sshd را فعال می‌کند، backend = systemd را تنظیم می‌کند تا فارغ از اینکه ایمیج شما /var/log/auth.log را می‌نویسد یا خیر، journal سیستم‌عامل (systemd) را بخواند، و banaction = nftables را تنظیم می‌کند تا مسدودسازی‌ها از طریق فایروال اصلی Ubuntu اعمال شوند. یک apt install fail2ban ساده، SSH را از همان اولین بوت محافظت می‌کند. این موضوع را با sudo fail2ban-client status sshd تأیید کنید و به دنبال یک مقدار غیر صفر در Total failed باشید.

چرا Fail2ban روی سرور من هیچ چیزی را مسدود نمی‌کند؟

سه علت رایج را به ترتیب بررسی کنید. ممکن است در حال تست از آدرسی در ignoreip باشید که طبق طراحی، از مسدودسازی معاف است. ممکن است با کپی کردن backend = auto از یک راهنمای قدیمی در jail.local، تنظیمات پیش‌فرضِ درست را بازنویسی کرده باشید؛ این کار در ایمیجی که rsyslog ندارد و در نتیجه auth.log هم ندارد، باعث اختلال در مسدودسازی SSH می‌شود. یا ممکن است داخل یک کانتینر باشید که اصلاً journal سیستم‌عامل (systemd) برای خواندن ندارد. مقدار Total failed را در fail2ban-client status sshd بررسی کنید: اگر با وجود نمایش خطاهای واقعی در journalctl -u ssh، این مقدار هرگز افزایش نمی‌یابد، یعنی jail در حال خواندن از مسیر اشتباهی است.

چگونه آدرس IP خود را از حالت مسدود خارج کنم؟

دستور sudo fail2ban-client set sshd unbanip YOUR.IP.HERE را اجرا کنید که در صورت موفقیت 1 را برمی‌گرداند، یا از sudo fail2ban-client unban --all برای پاک کردن تمام مسدودسازی‌ها استفاده کنید. اگر دسترسی شما به SSH قطع شده است، از کنسول وب یا VNC ارائه‌دهنده خود برای اجرای همان دستور استفاده کنید؛ مسدودسازی، تمام بسته‌های ارسالی از آدرس شما به پورت 22 را رد می‌کند، بنابراین حتی نشست‌هایی که از قبل باز بوده‌اند نیز از کار می‌افتند. سپس آدرس خود را به ignoreip اضافه کنید تا این اتفاق تکرار نشود.

تفاوت بین jail.conf و jail.local چیست؟

jail.conf حاوی تنظیمات پیش‌فرض بالادستی Fail2ban است و ممکن است با ارتقای بسته جایگزین شود، بنابراین هر تغییری در آن در معرض خطر است. بسته Debian/Ubuntu تنظیمات خود را از طریق jail.d/defaults-debian.conf روی آن اعمال می‌کند. تغییرات شما باید در jail.local قرار بگیرد که پس از هر دو فایل خوانده شده و اولویت دارد، و ارتقاها هرگز به آن دست نمی‌زنند. تنها یک فایل *.local در داخل jail.d/ است که حتی دیرتر از آن خوانده می‌شود، پس فایل‌های اضافی در آنجا باقی نگذارید. jail.conf را به عنوان یک مرجع فقط‌خواندنی باقی بگذارید.

آیا Fail2ban جایگزین احراز هویت مبتنی بر کلید (key-based) در SSH می‌شود؟

خیر. Fail2ban نرخ تلاش‌های ناموفق از یک آدرس را محدود می‌کند؛ این ابزار در برابر حدس‌های کند و توزیع‌شده که در آن هر آدرس زیر آستانه مجاز باقی می‌ماند، کاری انجام نمی‌دهد. احراز هویت فقط با کلید (PasswordAuthentication no) حدس زدن رمز عبور را به‌طور کامل غیرممکن می‌کند و Fail2ban در این حالت، نویز لاگ‌ها را کاهش داده و اسکنرها را در مراحل اولیه اخراج می‌کند. از هر دو استفاده کنید و در حالت ایده‌آل، SSH را به‌طور کامل از دسترس اینترنت عمومی خارج کنید.