Ubuntu 24.04 पर Fail2ban कैसे इंस्टॉल और कॉन्फ़िगर करें

Fail2ban वास्तव में क्या करता है

Fail2ban एक log-reading daemon है। यह आपके SSH authentication संदेशों की निगरानी करता है और एक निश्चित समय सीमा के भीतर एक ही IP address से कई बार login विफल होने पर, यह एक firewall command चलाता है जो उस address को कुछ समय के लिए block कर देता है। इसका मूल उद्देश्य यही है। इसमें एक file के भीतर लगभग तीस lines का configuration होता है, और Ubuntu 24.04 पर इसका installation एक एकल apt command है, जो किसी भी file को edit करने से पहले ही आपको सुरक्षा प्रदान कर देता है।

यह स्पष्ट रखें कि यह क्या है और क्या नहीं है। Fail2ban किसी को authenticate नहीं करता, किसी चीज़ को encrypt नहीं करता, और यह किसी एक दृढ़ login प्रयास को नहीं रोकता, बल्कि यह केवल एक ही source से बार-बार होने वाले प्रयासों को रोकता है। यह एक noise filter और rate limiter है, न कि कोई lock। इसका काम port 22 की निरंतर background scanning को रोकना है ताकि आपके CPU, bandwidth और log space की बर्बादी न हो, और यह उन हमलावरों की गति को धीमा कर देता है जिन्हें एक समय में एक ही address से प्रयास करना पड़ता है।

Fail2ban क्या प्रतिस्थापित नहीं करता है

Fail2ban तीसरी परत है, पहली नहीं। यदि आपका सर्वर अभी भी SSH पासवर्ड स्वीकार करता है, तो हजारों पतों पर फैला एक botnet अनुमान लगाना जारी रख सकता है, क्योंकि प्रत्येक पता आपकी ban threshold के नीचे रहता है और कभी भी उसे ट्रिगर नहीं करता है। इसके खिलाफ वास्तविक सुरक्षा केवल key-only authentication है, जो पासवर्ड का अनुमान लगाना असंभव बना देती है, चाहे कोई कितनी भी बार प्रयास करे। key-only authentication के ऊपर Fail2ban दो उपयोगी कार्य करता है: यह आपके logs से brute-force के शोर को हटाता है, और यह scanners को जल्दी बाहर निकाल देता है ताकि वे port पर हमला करना बंद कर दें। इसे defence in depth के रूप में मानें। यह key authentication के पीछे और firewall के पीछे स्थित होता है, कभी भी उनके आगे नहीं।

आवश्यकताएँ और Ubuntu 24.04 की वास्तविकता

आपको root या sudo एक्सेस के साथ Ubuntu 24.04 पर चलने वाला एक VPS चाहिए, जिसमें SSH पहले से काम कर रहा हो, अधिमानतः key authentication के साथ। Fail2ban बहुत कम संसाधन लेता है: केवल कुछ दसियों MB RAM, और इसमें limits को ट्यून करने की आवश्यकता नहीं होती।

अब वह हिस्सा जो पुराने guides में गलत बताया जाता है। वर्षों तक मानक सलाह यह थी कि "Fail2ban इंस्टॉल करें, फिर backend = systemd जोड़ें, क्योंकि Ubuntu ने /var/log/auth.log लिखना बंद कर दिया है।" यह सलाह एक वास्तविक बदलाव का वर्णन करती है, आधुनिक सर्वर और क्लाउड इमेजेस बिना rsyslog के आती हैं, इसलिए SSH केवल systemd journal में लॉग करता है और वह टेक्स्ट फाइल मौजूद नहीं होती, लेकिन Ubuntu 24.04 पर Fail2ban पैकेज पहले से ही इसे संभाल लेता है। यह पैकेज /etc/fail2ban/jail.d/defaults-debian.conf को ड्रॉप करता है, और यही फाइल, न कि अपस्ट्रीम डिफॉल्ट्स, वह है जो आपका सर्वर वास्तव में चलाता है:

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

[sshd]
enabled = true

इसे ध्यान से पढ़ें, क्योंकि यह कुछ भी छूने से पहले दो सवालों का समाधान कर देता है। backend = systemd का अर्थ है कि SSH जेल journal को पढ़ती है, इसलिए गायब auth.log से कोई फर्क नहीं पड़ता। banaction = nftables का अर्थ है कि प्रतिबंध (bans) nftables के माध्यम से लागू किए जाते हैं, जो कि वह फायरवॉल है जिसे Ubuntu 24.04 वास्तव में उपयोग करता है, न कि पुराना iptables। और [sshd] enabled = true का अर्थ है कि जेल पहले बूट से ही चालू है। निष्कर्ष: Ubuntu 24.04 पर एक स्टॉक apt install fail2ban बॉक्स से बाहर निकलते ही SSH ब्रूट-फोर्स को प्रतिबंधित कर देता है। आपका अधिकांश काम यह पुष्टि करना, पॉलिसी को ट्यून करना और यह सुनिश्चित करना है कि आप खुद को लॉक न कर लें।

पुराना auth.log ट्रैप अभी भी तीन स्थितियों में परेशान करता है, और उन्हें पहचानना महत्वपूर्ण है: आपने apt के बजाय pip के साथ Fail2ban इंस्टॉल किया है, इसलिए कोई defaults-debian.conf नहीं है; आप एक ऐसे unprivileged कंटेनर के अंदर हैं जिसमें पढ़ने के लिए कोई systemd journal नहीं है; या आपने किसी पुराने ट्यूटोरियल का पालन किया और अपने स्वयं के jail.local में backend = auto पेस्ट कर दिया, जिससे काम करने वाला डिफॉल्ट ओवरराइड हो गया। failure-modes सेक्शन दिखाता है कि इनमें से प्रत्येक कैसा दिखता है।

चरण 1: इंस्टॉल करें और पुष्टि करें कि यह पहले से ही बैन कर रहा है

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04 में Fail2ban 1.0.2 आता है, और यह पैकेज एक hard dependency के रूप में python3-systemd को इंस्टॉल करता है, इसलिए journal backend के लिए आवश्यक सभी चीजें मौजूद होती हैं। यह service अपने आप enable और start हो जाती है:

sudo systemctl status fail2ban

आपको active (running) की आवश्यकता होगी। इसके बाद उस jail को देखें जो पहले से ही अपना काम कर रही है:

sudo fail2ban-client status sshd

एक public VPS पर जो कुछ मिनटों के लिए भी internet पर उपलब्ध रहा हो, आप अक्सर देखेंगे कि failures की गिनती हो रही है और IP addresses बैन किए जा चुके हैं, क्योंकि internet पर port 22 को लगातार scan किया जाता है। यह इस बात का प्रमाण है कि stock configuration सही ढंग से काम कर रहा है। अब आप इसे बेहतर बना रहे हैं, न कि शून्य से शुरुआत कर रहे हैं।

चरण 2: jail.local को संपादित करें, jail.conf को कभी नहीं

Fail2ban अपने upstream defaults को /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 लाइन पर दिए गए पते को अपने स्वयं के public 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 नीति (policy) निर्धारित करते हैं। डिफ़ॉल्ट रूप से दिया गया bantime केवल दस मिनट का होता है; एक घंटा एक बेहतर न्यूनतम समय है। दस मिनट के भीतर एक ही पते से पाँच बार विफल प्रयास होने पर ban लगा दिया जाता है। वास्तविक उपयोगकर्ता एक या दो बार पासवर्ड गलत टाइप कर सकते हैं; दस मिनट में पाँच विफलताएँ किसी script का संकेत हैं।
• ignoreip आपकी सुरक्षा के लिए है। यहाँ वह public पता डालें जहाँ से आप connect करते हैं, ताकि Fail2ban आपको कभी भी आपके अपने सर्वर से बाहर न कर दे। यदि आपके home connection का IP बदलता रहता है, तो अंत में दिए गए VPN दृष्टिकोण को अपनाना बेहतर है, न कि इस लाइन को छोड़ना।
• bantime.increment = true प्रत्येक बार ban की अवधि को पहले से लंबा बनाता है: एक घंटा, फिर दो, फिर चार, और अधिकतम bantime.maxtime तक। जो पते बार-बार प्रयास करते हैं, उन्हें उत्तरोत्तर अधिक समय के लिए lock कर दिया जाता है।

उस मशीन से whitelist करने के लिए पता ढूँढें जहाँ से आप SSH करते हैं, न कि सर्वर से:

curl -s ifconfig.me

आप यहाँ अपने ports और ban नीति के अनुसार एक jail.local तैयार कर सकते हैं, और फिर उसे फ़ाइल में paste कर सकते हैं:

चरण 4: Restart करें और verify करें कि यह journal को पढ़ रहा है

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

-t पहले एक config test चलाता है, इसलिए jail.local में कोई भी typo होने पर service मृत रहने के बजाय यहीं स्पष्ट रूप से fail हो जाएगी। एक स्वस्थ jail का status कुछ इस तरह दिखता है:

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 वास्तव में आपके logins को पढ़ रहा है, वह Total failed है। यदि यह शून्य से अधिक है, या किसी अन्य machine से जानबूझकर login fail करने पर बढ़ती है, तो इसका मतलब है कि journal पढ़ा जा रहा है और आपका काम पूरा हो गया है। यदि आप कितनी भी बार fail होने पर भी यह 0 पर ही बनी रहती है, और आप सुनिश्चित हैं कि आप ignoreip में दिए गए address से test नहीं कर रहे हैं, तो नीचे दिए गए failure modes पर जाएँ।

ध्यान दें कि Journal matches line में अभी भी sshd.service का नाम है। Ubuntu पर SSH unit वास्तव में ssh.service है, लेकिन प्रदान किया गया filter _COMM=sshd पर भी match करता है, और 24.04 पर OpenSSH अपनी failures को sshd नामक process से log करता है, इसलिए यह match काम करता है। यह विवरण केवल तभी मायने रखता है यदि आप नए OpenSSH (9.8 या बाद के version, जहाँ per-connection worker sshd-session है) का उपयोग कर रहे हैं; failure modes उस स्थिति को भी कवर करते हैं।

चरण 5: वास्तविक ban को देखें, या परीक्षण के लिए एक ban लागू करें

किसी भी public VPS पर वास्तविक bans कुछ ही मिनटों में अपने आप आ जाते हैं। किसी ban को देखने के लिए, log को tail करें:

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

एक ban इस तरह दिखता है:

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

बिना प्रतीक्षा किए पूरी प्रक्रिया की पुष्टि करने के लिए, किसी documentation address को मैन्युअल रूप से ban करें। ध्यान रहे, अपना स्वयं का IP address कभी न डालें:

sudo fail2ban-client set sshd banip 10.0.0.66

यह 1 प्रिंट करता है, और वह address fail2ban-client status sshd में Banned IP list के अंतर्गत दिखाई देता है। अब पुष्टि करें कि firewall में block वास्तव में मौजूद है। Ubuntu 24.04 पर यह iptables नहीं, बल्कि nftables है:

sudo nft list table inet f2b-table

आपको 10.0.0.66 को धारण करने वाला addr-set-sshd नामक एक set दिखाई देगा, और एक chain f2b-chain जो उस set में मौजूद किसी भी source को reject करती है। यदि fail2ban-client यह बताता है कि कोई address banned है लेकिन nft list में कुछ भी दिखाई नहीं देता है, तो इसका मतलब है कि आपकी ban action आपके firewall से मेल नहीं खाती है। विफलता के कारणों (failure modes) में nftables/iptables संबंधी नोट देखें।

चरण 6: खुद को अनबैन करें, और लॉक आउट होने पर रिकवर करें

यदि आपने किसी ऐसे IP address को बैन कर दिया है जिसे नहीं करना चाहिए था, तो उसे हटा दें:

sudo fail2ban-client set sshd unbanip 10.0.0.66

सफलता मिलने पर यह 1 लौटाता है। हर jail से सभी बैन हटाने के लिए:

sudo fail2ban-client unban --all

यह न सोचें कि पहले से खुला SSH session आपको बचा लेगा: nftables बैन port 22 पर आने वाले बैन किए गए address के हर packet को अस्वीकार (reject) कर देता है। इसमें स्थापित (established) connections भी शामिल हैं, इसलिए बैन लगते ही मौजूदा session फ्रीज हो जाता है। यदि आप खुद को बैन कर लेते हैं और आपके पास कोई ignoreip entry नहीं है, तो आप बैन की अवधि समाप्त होने तक लॉक आउट रहेंगे। अपने प्रदाता (provider) के वेब कंसोल (VNC या serial) के माध्यम से रिकवर करें, जो SSH से होकर नहीं जाता है। वहां या तो bantime के समाप्त होने की प्रतीक्षा करें या unban कमांड चलाएं।

चरण 7: Bans को स्थायी बनाना और बढ़ाना

Fail2ban सक्रिय bans को /var/lib/fail2ban/fail2ban.sqlite3 पर एक छोटी SQLite database में रखता है, इसलिए service restart या reboot के बाद भी वे बने रहते हैं; आप उन्हें खोते नहीं हैं। जो bantime.increment लाइनें आपने पहले ही जोड़ दी हैं, वे प्रत्येक बार-बार उल्लंघन करने वाले (repeat offender) के लिए समस्या को बढ़ा देती हैं, जो लगभग एक घंटे से बढ़कर एक सप्ताह तक हो जाती है।

इसके अतिरिक्त, पूरे सिस्टम के लिए "three strikes" नीति लागू करने हेतु, Fail2ban में एक recidive jail शामिल होती है जो अपनी खुद की /var/log/fail2ban.log पर नजर रखती है और किसी भी ऐसे address को लंबी अवधि के लिए ban कर देती है जिसे सभी jails में बार-बार ban किया गया हो। चूँकि आपका [DEFAULT] अब systemd backend का उपयोग करता है, इसलिए इस jail को उस log file से जोड़ें जिसे पढ़ने के लिए इसे बनाया गया है:

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

स्पष्ट logpath के साथ backend = auto यह सुनिश्चित करता है कि recidive सादे fail2ban.log को पढ़ता रहे, जहाँ वे Ban लाइनें वास्तव में दिखाई देती हैं जिन्हें यह गिनता है। यदि आप इसे global स्तर पर सेट किए गए systemd default पर छोड़ देंगे, तो यह journal की ओर इशारा करेगा, जहाँ ये लाइनें मौजूद नहीं होती हैं।

चरण 8: इसे केवल-key वाले SSH के साथ जोड़ें, और VPN का उपयोग करना और भी बेहतर है

Fail2ban केवल key authentication के साथ ही प्रभावी ढंग से काम करता है। /etc/ssh/sshd_config.d/ के अंतर्गत एक drop-in file, जैसे कि /etc/ssh/sshd_config.d/00-hardening.conf में, यह सेट करें:

PasswordAuthentication no
KbdInteractiveAuthentication no

इसके बाद sudo systemctl restart ssh चलाएं। पासवर्ड बंद होने पर, brute force हमला सफल नहीं हो सकता; ऐसी स्थिति में Fail2ban का कार्य केवल log noise को कम करना और scanners को जल्दी बाहर निकालना रह जाता है। इससे भी बेहतर यह है कि SSH को सार्वजनिक इंटरनेट से पूरी तरह दूर रखा जाए: SSH को self-hosted WireGuard VPN के पीछे रखें और port 22 को firewall करें ताकि यह केवल tunnel पर ही प्रतिक्रिया दे। कोई भी उस port को brute-force नहीं कर सकता जिस तक वह पहुँच ही नहीं सकता, और Fail2ban एक मुख्य सुरक्षा पंक्ति के बजाय एक अंतिम सुरक्षा उपाय (backstop) बन जाता है।

Fail2ban केवल SSH के लिए नहीं है। कोई भी service जो विफल login को log करती है, उसके लिए jail बनाई जा सकती है, जैसे कि mail server, nginx site, या self-hosted Vaultwarden password manager, जिसके web login को आप credential stuffing के लिए खुला नहीं छोड़ना चाहेंगे। एक बार जब कोई web app Let's Encrypt certificate वाली nginx site के पीछे आ जाता है, तो उसके access log पर Fail2ban filter को उसी तरह point करें जैसे SSH jail को journal पर point किया जाता है।

विफलता के प्रकार, और वे सटीक strings जो आपको दिखाई देंगी

"Have not found any log file for sshd jail", और Fail2ban start नहीं होगा। यह एक पुरानी auth.log समस्या है, और Ubuntu 24.04 पर आप इसका सामना तभी करते हैं यदि किसी चीज़ ने packaged default को override कर दिया हो, जैसे कि बिना defaults-debian.conf वाला pip install, बिना journal वाला container, या jail.local में पेस्ट की गई कोई गलत backend = auto। बिना /var/log/auth.log वाले file backend पर, sshd jail अपनी log नहीं ढूँढ पाती और पूरा daemon abort हो जाता है। fail2ban.log यह दिखाता है:

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

चूंकि वह error fatal है, service कभी start नहीं होती, और fail2ban-client status फिर downstream लक्षण की रिपोर्ट करता है:

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

वह "socket path" वाली line का मतलब यह नहीं है कि Fail2ban खराब है, इसका मतलब है कि यह कभी start ही नहीं हुआ क्योंकि एक jail अपनी log नहीं ढूँढ सकी। [DEFAULT] में backend = systemd सेट करने से, जो Ubuntu package आपके लिए पहले से करता है, दोनों messages एक साथ ठीक हो जाते हैं।

Jail active है लेकिन Total failed कभी नहीं बढ़ता। Daemon चल रहा है और journal पढ़ा जा रहा है, फिर भी वास्तविक failures journalctl -u ssh में जमा हो रहे हैं जबकि counter 0 पर अटका है। सबसे पहले स्पष्ट कारण को हटा दें: आप ignoreip में सूचीबद्ध address से test कर रहे हैं, इसलिए आपकी अपनी failures design के अनुसार छूट प्राप्त हैं। यदि यह कारण नहीं है, तो आप OpenSSH के ऐसे build पर हैं जहाँ per-connection worker sshd-session (9.8 और बाद के version) है, जिसका journal _COMM, sshd के बजाय sshd-session है, इसलिए shipped match उसे पकड़ नहीं पाता। [sshd] block में match को बढ़ाएँ:

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

Restart करें, ignoreip में न होने वाले address से जानबूझकर login fail करें, और पुष्टि करें कि Total failed अंततः बढ़ रहा है।

आपने खुद को ban कर लिया: Connection refused। आपने ignoreip में अपना address शामिल नहीं किया, कुछ गलत logins test किए, और अब:

ssh: connect to host 10.0.0.10 port 22: Connection refused

Silent timeout के बजाय refusal, nftables action का default reject verdict है जो अपना काम कर रहा है। इसे Step 6 के अनुसार ठीक करें: किसी अन्य, unbanned address से session के माध्यम से या provider console से unban करें, क्योंकि banned address से पहले से खुला session भी freeze हो जाता है। फिर अपना address ignoreip में जोड़ें ताकि ऐसा दोबारा न हो।

Fail2ban कहता है कि एक address banned है, लेकिन वह अभी भी connect कर सकता है। status sshd में counter बढ़ता है, फिर भी address अभी भी port 22 तक पहुँच जाता है। यह ban-action और firewall के बीच का बेमेल है, और Ubuntu 24.04 पर इसका मतलब लगभग हमेशा यह होता है कि आपने iptables layer न होने वाले box पर, किसी पुरानी guide से copy किए गए banaction = iptables-multiport के साथ working banaction = nftables को override कर दिया है। fail2ban.log यह दिखाता है:

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

उस override को हटा दें और packaged nftables action को रहने दें, या, यदि आप firewall को पूरी तरह ufw के माध्यम से manage करते हैं और चाहते हैं कि bans वहाँ दिखाई दें, तो [DEFAULT] में banaction = ufw सेट करें। Restart करें और पुष्टि करें कि rule sudo nft list ruleset | grep f2b के साथ दिखाई देता है।

jail.local को edit करने के बाद Fail2ban start नहीं होगा। कोई typo, गलत heading या गलत time value के कारण service start होने से मना कर देती है। Fail2ban को run होने से पहले config जाँचने के लिए कहें:

sudo fail2ban-client -t

यह उस file और jail का नाम बताता है जिसमें समस्या है, उदाहरण के लिए Errors in jail 'sshd'. Skipping..., ताकि आप अनुमान लगाने के बजाय source को ठीक कर सकें।

FAQ

क्या Ubuntu 24.04 पर Fail2ban का स्टॉक इंस्टॉलेशन वास्तव में SSH हमलों को रोकता है?

हाँ। यह पैकेज /etc/fail2ban/jail.d/defaults-debian.conf के साथ आता है, जो sshd जेल को सक्षम करता है, backend = systemd को सेट करता है ताकि यह अनुपस्थित /var/log/auth.log के बजाय systemd जर्नल को पढ़ सके, और banaction = nftables को सेट करता है ताकि प्रतिबंध Ubuntu के वास्तविक फायरवॉल के माध्यम से लागू हों। एक सामान्य apt install fail2ban पहले बूट से ही SSH की सुरक्षा करता है। इसकी पुष्टि sudo fail2ban-client status sshd के साथ करें और एक गैर-शून्य Total failed की जाँच करें।

Fail2ban मेरे सर्वर पर किसी को बैन क्यों नहीं कर रहा है?

तीन सामान्य कारणों की क्रमानुसार जाँच करें। हो सकता है कि आप ignoreip में मौजूद किसी पते से परीक्षण कर रहे हों, जिसे डिज़ाइन के अनुसार छूट प्राप्त है। हो सकता है कि आपने किसी पुरानी गाइड से backend = auto को jail.local में पेस्ट करके डिफ़ॉल्ट सेटिंग्स को बदल दिया हो, जो बिना auth.log वाली इमेज पर जर्नल रीडिंग को बाधित करता है। या हो सकता है कि आप किसी ऐसे कंटेनर के अंदर हों जहाँ पढ़ने के लिए कोई systemd जर्नल ही न हो। fail2ban-client status sshd में Total failed की जाँच करें: यदि journalctl -u ssh वास्तविक विफलताओं को दिखाता है लेकिन यह संख्या कभी नहीं बढ़ती, तो जेल गलत स्थान को पढ़ रही है।

मैं अपना 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 एक पते से बार-बार होने वाली विफलताओं की दर को सीमित करता है; यह धीमे, वितरित अनुमानों के खिलाफ कुछ नहीं करता जहाँ प्रत्येक पता सीमा (threshold) के नीचे रहता है। केवल-की प्रमाणीकरण (PasswordAuthentication no) पासवर्ड का अनुमान लगाना पूरी तरह से असंभव बना देता है, और Fail2ban तब लॉग के शोर को कम करता है और स्कैनर्स को जल्दी बाहर निकाल देता है। दोनों का उपयोग करें, और आदर्श रूप से SSH को सार्वजनिक इंटरनेट से पूरी तरह दूर रखें।