آموزش نصب و تنظیم 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 بسیار کم‌مصرف است: تنها چند ده مگابایت رم اشغال می‌کند و نیازی به تنظیم محدودیت‌ها ندارد.

اکنون به بخشی می‌رسیم که اکثر راهنماهای قدیمی در آن اشتباه می‌کنند. سال‌ها توصیه استاندارد این بود که «Fail2ban را نصب کنید و سپس backend = systemd را اضافه کنید، زیرا Ubuntu دیگر /var/log/auth.log را نمی‌نویسد.» این توصیه به یک تغییر واقعی اشاره دارد؛ ایمیج‌های مدرن سرور و ابری بدون rsyslog عرضه می‌شوند، بنابراین لاگ‌های SSH فقط در systemd 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 خود کپی کرده‌اید که باعث نادیده گرفته شدن تنظیمات پیش‌فرضِ صحیح شده است. بخش حالت‌های شکست (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 نگهداری می‌کند. این فایل را ویرایش نکنید. هر apt upgrade از این بسته می‌تواند فایل مذکور را جایگزین کند و تغییرات شما بدون هیچ هشداری از بین خواهد رفت. Fail2ban فایل‌ها را به ترتیب مشخصی می‌خواند: ابتدا jail.conf، سپس تمام فایل‌های موجود در jail.d/، و در نهایت jail.local؛ در این فرآیند، آخرین مقدار خوانده‌شده اولویت دارد. فایل .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:   10.0.0.66

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

توجه داشته باشید که خط Journal matches همچنان به sshd.service اشاره دارد. در Ubuntu، واحد سرویس 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 10.0.0.66 - 2026-07-15 10:31:40
2026-07-15 10:31:44,118 fail2ban.actions [812]: NOTICE  [sshd] Ban 10.0.0.66

برای اطمینان از عملکرد کامل سیستم بدون انتظار، یک آدرس مستندات را به‌صورت دستی مسدود کنید (هرگز آدرس خودتان را مسدود نکنید):

sudo fail2ban-client set sshd banip 10.0.0.66

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

sudo nft list table inet f2b-table

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

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

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

sudo fail2ban-client set sshd unbanip 10.0.0.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 تنها زمانی با آن مواجه می‌شوید که چیزی تنظیمات پیش‌فرض بسته‌ها را بازنویسی کرده باشد، یا یک نصب 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 تغییر نمی‌کند. daemon در حال اجراست و journal خوانده می‌شود، اما شکست‌های واقعی در journalctl -u ssh انباشته می‌شوند در حالی که شمارنده روی 0 باقی مانده است. ابتدا موارد بدیهی را بررسی کنید: شما در حال تست از آدرسی هستید که در ignoreip لیست شده است، بنابراین شکست‌های شما طبق طراحی نادیده گرفته می‌شوند. اگر مشکل این نیست، شما از نسخه OpenSSH استفاده می‌کنید که در آن worker هر اتصال به صورت sshd-session است (نسخه 9.8 و بالاتر)، که در آن _COMM برابر با 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 که وجود ندارد، از systemd journal بخواند و banaction = nftables را تنظیم می‌کند تا مسدودسازی‌ها از طریق فایروال اصلی Ubuntu اعمال شوند. یک نصب ساده apt install fail2ban از همان بوت اول از SSH محافظت می‌کند. این موضوع را با sudo fail2ban-client status sshd تأیید کنید و به دنبال مقدار غیر صفر در Total failed باشید.

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

سه دلیل رایج را به ترتیب بررسی کنید. ممکن است در حال تست از آدرسی در ignoreip باشید که طبق طراحی از مسدودسازی معاف است. ممکن است با کپی کردن backend = auto از یک راهنمای قدیمی در jail.local، تنظیمات پیش‌فرض صحیح را بازنویسی کرده باشید که باعث از کار افتادن خواندن journal در ایمیجی می‌شود که auth.log ندارد. یا ممکن است داخل یک container باشید که اصلاً systemd journal برای خواندن ندارد. مقدار 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 قرار بگیرد که آخرین فایل خوانده‌شده است و بر هر دو فایل دیگر اولویت دارد و ارتقاها هرگز به آن دست نمی‌زنند. فایل jail.conf را به عنوان مرجع فقط‌خواندنی باقی بگذارید.

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

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