Ubuntu 24.04 पर Fail2ban: SSH हमले रोकें

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

Fail2ban लॉग पढ़ने वाला एक डेमन (daemon) है। यह आपके SSH ऑथेंटिकेशन संदेशों पर नज़र रखता है और जब एक ही एड्रेस से थोड़े-से समय के भीतर मुट्ठी भर असफल कोशिशें हो जाती हैं, तो एक फ़ायरवॉल कमांड चलाकर उस एड्रेस को कुछ देर के लिए ब्लॉक कर देता है। बस यही इसका पूरा विचार है। पूरा कॉन्फ़िगरेशन एक ही फ़ाइल में क़रीब तीस लाइनों का है, और Ubuntu 24.04 पर इंस्टॉल एक अकेली apt कमांड है, जो आपके कुछ भी एडिट करने से पहले ही आपको सुरक्षित कर देती है।

साफ़ समझ लें कि यह क्या है और क्या नहीं। Fail2ban किसी को ऑथेंटिकेट नहीं करता, कुछ भी एन्क्रिप्ट नहीं करता, और किसी दृढ़-निश्चयी हमलावर की एक अकेली लॉगिन कोशिश को नहीं रोकता — सिर्फ़ एक ही स्रोत से बार-बार होती कोशिशों को रोकता है। यह शोर का फ़िल्टर और एक रेट-लिमिटर है, ताला नहीं। इसका काम है पोर्ट 22 की लगातार चलती बैकग्राउंड स्कैनिंग को आपका CPU, आपकी बैंडविड्थ और आपका लॉग स्पेस बर्बाद करने से रोकना, और ऐसे किसी भी हमलावर को धीमा करना जिसे एक बार में एक ही एड्रेस से आना पड़े।

Fail2ban किसकी जगह नहीं लेता

Fail2ban तीसरी परत है, पहली नहीं। अगर आपका सर्वर अब भी SSH पासवर्ड स्वीकार करता है, तो हज़ारों एड्रेस पर फैला कोई बॉटनेट अंदाज़े लगाता रह सकता है, क्योंकि हर एड्रेस आपके बैन थ्रेशोल्ड के नीचे बना रहता है और उसे कभी ट्रिगर नहीं करता। इसके ख़िलाफ़ असली बचाव है key-only ऑथेंटिकेशन (लॉगिन सिर्फ़ SSH key से, पासवर्ड बिल्कुल नहीं), जो पासवर्ड के अंदाज़े लगाना असंभव बना देता है — कोई चाहे जितनी कोशिशें कर ले। key-only ऑथेंटिकेशन के ऊपर Fail2ban दो काम की चीज़ें करता है: यह आपके लॉग से ब्रूट-फ़ोर्स का शोर छाँट देता है, और स्कैनरों को जल्दी बाहर निकाल देता है ताकि वे पोर्ट पर हथौड़े बरसाना बंद करें। इसे defence in depth (परत-दर-परत बचाव) मानिए। यह key ऑथेंटिकेशन के पीछे और फ़ायरवॉल के पीछे बैठता है — उनके आगे कभी नहीं।

ज़रूरी चीज़ें, और Ubuntu 24.04 की असलियत

आपको Ubuntu 24.04 चला रहा एक VPS चाहिए जिस पर root या sudo हो, और SSH पहले से काम कर रहा हो — बेहतर हो तो key ऑथेंटिकेशन पर। Fail2ban बेहद किफ़ायती है: कुछ दसियों मेगाबाइट RAM, और किसी limit की ट्यूनिंग की ज़रूरत नहीं।

अब वह हिस्सा जिसे हर पुरानी गाइड ग़लत बताती है। बरसों तक मानक सलाह यही थी कि "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 का मतलब है कि SSH jail (Fail2ban हर सेवा की निगरानी वाले नियम-सेट को jail कहता है) journal पढ़ता है, इसलिए ग़ायब auth.log से कोई फ़र्क़ नहीं पड़ता। banaction = nftables का मतलब है कि बैन nftables के ज़रिए लागू होते हैं — यानी वह फ़ायरवॉल जो Ubuntu 24.04 असल में इस्तेमाल करता है — न कि पुराना iptables। और [sshd] enabled = true का मतलब है कि यह jail पहले बूट से ही चालू है। नतीजा: Ubuntu 24.04 पर एक सादा apt install fail2ban बिना कुछ किए ही SSH ब्रूट-फ़ोर्स को बैन करता है। आपका ज़्यादातर काम इसकी पुष्टि करना, पॉलिसी को ट्यून करना, और यह पक्का करना है कि आप खुद को लॉक-आउट न कर बैठें।

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

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

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04 में Fail2ban 1.0.2 आता है, और पैकेज python3-systemd को एक अनिवार्य dependency के तौर पर साथ खींच लाता है, इसलिए journal बैकएंड के पास वह सब कुछ है जो उसे चाहिए। सर्विस खुद ही enable होकर चालू हो जाती है:

sudo systemctl status fail2ban

आपको active (running) दिखना चाहिए। फिर उस jail को देखिए जो पहले से अपना काम कर रहा है:

sudo fail2ban-client status sshd

एक ऐसे पब्लिक VPS पर जो चंद मिनटों से भी पहुँच में रहा हो, आपको अक्सर पहले से गिनी हुई असफल कोशिशें और बैन हुए एड्रेस दिख जाएँगे — इंटरनेट पोर्ट 22 को लगातार स्कैन करता रहता है। यही सबूत है कि डिफ़ॉल्ट कॉन्फ़िगरेशन काम करता है। यहाँ से आगे आप उसे तराश रहे हैं, शून्य से नहीं बना रहे।

स्टेप 2: jail.local ही एडिट करें, jail.conf कभी नहीं

Fail2ban अपने upstream डिफ़ॉल्ट /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: रीस्टार्ट करें और पक्का करें कि यह journal पढ़ रहा है

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। अगर यह शून्य से ऊपर है, या जब आप किसी दूसरी मशीन से जान-बूझकर लॉगिन फ़ेल करते हैं तो चढ़ती है, तो journal पढ़ा जा रहा है और आपका काम पूरा हुआ। अगर आप चाहे जितनी बार फ़ेल हों और यह 0 पर ही टिकी रहे — और आपको पक्का पता हो कि आप ignoreip वाले एड्रेस से टेस्ट नहीं कर रहे — तो सीधे नीचे 'आम गड़बड़ियाँ' पर जाएँ।

ग़ौर करें कि Journal matches वाली लाइन अब भी sshd.service का नाम लेती है। Ubuntu पर SSH यूनिट असल में ssh.service है, लेकिन पैकेज के साथ आया फ़िल्टर _COMM=sshd पर भी मैच करता है, और 24.04 पर OpenSSH अपनी असफलताएँ sshd नाम के प्रोसेस से लॉग करता है, इसलिए मैच काम करता है। यह बारीकी तभी मायने रखती है जब आप किसी नए OpenSSH पर हों (9.8 या उसके बाद का, जहाँ हर कनेक्शन का वर्कर प्रोसेस 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

आपको addr-set-sshd नाम का एक सेट दिखेगा जिसमें 10.0.0.66 बैठा है, और f2b-chain नाम की एक chain जो उस सेट में मौजूद किसी भी स्रोत को reject करती है। अगर fail2ban-client कहता है कि कोई एड्रेस बैन है, लेकिन nft list में कुछ नहीं दिखता, तो आपका ban action आपके फ़ायरवॉल से मेल नहीं खाता — 'आम गड़बड़ियाँ' में nftables/iptables वाला नोट देखें।

स्टेप 6: खुद को अनबैन करें, और लॉक-आउट हो जाएँ तो उबरें

अगर आपने कोई ऐसा एड्रेस बैन कर दिया जो नहीं करना चाहिए था — यानी अपना — तो उसे हटाएँ:

sudo fail2ban-client set sshd unbanip 10.0.0.66

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

sudo fail2ban-client unban --all

किसी पहले से खुले SSH सेशन के भरोसे न रहें: nftables का बैन उस बैन हुए एड्रेस से पोर्ट 22 पर आने वाले हर पैकेट को reject करता है — पहले से बने कनेक्शन भी शामिल — इसलिए बैन लगते ही मौजूदा सेशन जम जाता है। अगर आपने खुद को बैन कर लिया और ignoreip में कोई एंट्री नहीं है, तो बैन ख़त्म होने तक आप बाहर हैं — अपने प्रोवाइडर के वेब कंसोल (VNC या सीरियल) से उबरें, जो SSH से होकर नहीं जाता, और वहाँ या तो bantime बीतने का इंतज़ार करें या अनबैन कमांड चला दें।

स्टेप 7: बैन को टिकाऊ बनाएँ और बढ़ते जाने दें

Fail2ban सक्रिय बैन /var/lib/fail2ban/fail2ban.sqlite3 पर रखे एक छोटे-से SQLite डेटाबेस में सहेजता है, इसलिए वे सर्विस रीस्टार्ट या रीबूट के बाद भी बचे रहते हैं; आप उन्हें खोते नहीं। जो bantime.increment लाइनें आप पहले ही जोड़ चुके हैं, उनकी बदौलत हर बार-बार लौटने वाले एड्रेस की मुसीबत अपने आप बढ़ती जाती है — हर बैन पिछले से क़रीब-क़रीब दोगुना, एक घंटे से बढ़ते-बढ़ते एक हफ़्ते तक।

इसके ऊपर पूरे सिस्टम के स्तर की एक "three strikes" (तीसरी ग़लती पर बाहर) पॉलिसी के लिए, Fail2ban अपने साथ एक recidive jail देता है, जो उसकी अपनी /var/log/fail2ban.log पर नज़र रखता है और ऐसे किसी भी एड्रेस को लंबा बैन थमा देता है जो सारे jails में मिलाकर बार-बार बैन हो चुका हो। चूँकि आपका [DEFAULT] अब 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: इसे key-only SSH से जोड़ें, और उससे भी बेहतर, VPN से

Fail2ban अपनी मौजूदगी तभी सार्थक बनाता है जब key ऑथेंटिकेशन उसके साथ हो। /etc/ssh/sshd_config.d/ के नीचे किसी drop-in फ़ाइल में — मान लीजिए /etc/ssh/sshd_config.d/00-hardening.conf — यह सेट करें:

PasswordAuthentication no
KbdInteractiveAuthentication no

फिर sudo systemctl restart ssh। पासवर्ड बंद होते ही ब्रूट-फ़ोर्स कामयाब हो ही नहीं सकता; तब Fail2ban का काम रह जाता है लॉग का शोर काटना और स्कैनरों को जल्दी बाहर करना। इससे भी मज़बूत तरीक़ा है SSH को पब्लिक इंटरनेट से पूरी तरह दूर रखना: SSH को खुद होस्ट किए हुए WireGuard VPN के पीछे रखें और पोर्ट 22 को फ़ायरवॉल से ऐसे बाँधें कि वह सिर्फ़ टनल पर जवाब दे। जिस पोर्ट तक कोई पहुँच ही नहीं सकता, उस पर ब्रूट-फ़ोर्स भी नहीं कर सकता, और Fail2ban अग्रिम मोर्चे से हटकर एक बैकअप-परत बन जाता है।

Fail2ban सिर्फ़ SSH के लिए नहीं है। जो भी सर्विस असफल लॉगिन लॉग करती है, उसके लिए jail बन सकता है — कोई मेल सर्वर, कोई nginx साइट, या खुद होस्ट किया हुआ एक Vaultwarden पासवर्ड मैनेजर जिसका वेब लॉगिन आप credential stuffing (चुराए हुए पासवर्डों को थोक में आज़माने) के लिए खुला नहीं छोड़ना चाहेंगे। एक बार कोई वेब ऐप Let's Encrypt सर्टिफ़िकेट वाली किसी nginx साइट के पीछे आ जाए, तो एक Fail2ban फ़िल्टर को उसके access log की ओर वैसे ही मोड़ दें जैसे SSH jail journal की ओर मुड़ा है।

आम गड़बड़ियाँ, और ठीक वही स्ट्रिंग्स जो आपको दिखेंगी

"Have not found any log file for sshd jail", और Fail2ban स्टार्ट ही नहीं होता। यह वही पुरानी auth.log समस्या है, और Ubuntu 24.04 पर आप इससे तभी टकराते हैं जब किसी चीज़ ने पैकेज वाले डिफ़ॉल्ट को ओवरराइड कर दिया हो — बिना defaults-debian.conf वाला कोई pip इंस्टॉल, बिना journal वाला कोई कंटेनर, या jail.local में चिपकाया गया कोई भटका हुआ backend = auto। फ़ाइल बैकएंड पर जब /var/log/auth.log ही न हो, तो sshd jail को अपना लॉग नहीं मिलता और पूरा डेमन ही रुक जाता है। 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 ख़राब हो गया है — इसका मतलब है कि वह शुरू ही नहीं हुआ, क्योंकि एक jail को उसका लॉग नहीं मिला। [DEFAULT] में backend = systemd सेट करना — जो Ubuntu पैकेज पहले से आपके लिए कर देता है — दोनों संदेश एक साथ ठीक कर देता है।

jail चालू है, पर Total failed कभी हिलता नहीं। डेमन चल रहा है और journal पढ़ा जा रहा है, फिर भी असली असफलताएँ journalctl -u ssh में जमा होती जाती हैं और काउंटर 0 पर बैठा रहता है। पहले सबसे ज़ाहिर वजह ख़ारिज करें: आप ignoreip में दर्ज किसी एड्रेस से टेस्ट कर रहे हैं, इसलिए आपकी अपनी असफलताएँ डिज़ाइन से ही छूट पाती हैं। अगर बात यह नहीं है, तो आप OpenSSH के ऐसे बिल्ड पर हैं जहाँ हर कनेक्शन का वर्कर sshd-session है (9.8 और उसके बाद), जिसका journal में _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

साइलेंट टाइमआउट की जगह मिला यह साफ़ इनकार दरअसल nftables action के डिफ़ॉल्ट reject फ़ैसले का ही नतीजा है — वह अपना काम कर रहा है, बस निशाना आप हैं। इसे स्टेप 6 की तरह ठीक करें: किसी दूसरे, बैन-मुक्त एड्रेस पर खुले सेशन से, या प्रोवाइडर कंसोल से अनबैन करें — बैन हुए एड्रेस से पहले से खुला सेशन भी जम जाता है। फिर अपना एड्रेस ignoreip में जोड़ दें ताकि यह दोबारा न हो।

Fail2ban कहता है एड्रेस बैन है, पर वह फिर भी कनेक्ट कर पा रहा है। status sshd का काउंटर बढ़ रहा है, फिर भी वह एड्रेस पोर्ट 22 तक पहुँच रहा है। यह ban action और फ़ायरवॉल के बीच का बेमेल है, और Ubuntu 24.04 पर इसका मतलब लगभग हमेशा यही होता है कि आपने किसी पुरानी गाइड से कॉपी किए banaction = iptables-multiport से चालू हालत वाले banaction = nftables को ओवरराइड कर दिया — एक ऐसी मशीन पर जिसमें iptables की परत है ही नहीं। fail2ban.log दिखाता है:

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

वह ओवरराइड हटाएँ और पैकेज वाले nftables action को अपनी जगह रहने दें, या — अगर आप फ़ायरवॉल पूरी तरह ufw से चलाते हैं और चाहते हैं कि बैन वहीं दिखें — [DEFAULT] में banaction = ufw सेट करें। रीस्टार्ट करें और sudo nft list ruleset | grep f2b से पुष्टि करें कि नियम दिखता है।

jail.local एडिट करने के बाद Fail2ban स्टार्ट नहीं होता। एक टाइपो — कोई भटका हुआ सेक्शन-हेडर या कोई ग़लत समय-वैल्यू — सर्विस को उठने ही नहीं देती। Fail2ban से कहें कि चलने से पहले कॉन्फ़िग जाँच ले:

sudo fail2ban-client -t

यह समस्या वाली फ़ाइल और jail का नाम बता देता है, जैसे Errors in jail 'sshd'. Skipping..., ताकि आप अंदाज़े लगाने के बजाय जड़ को ठीक करें।

FAQ

क्या Ubuntu 24.04 पर डिफ़ॉल्ट Fail2ban इंस्टॉल सच में SSH हमले बैन करता है?

हाँ। पैकेज /etc/fail2ban/jail.d/defaults-debian.conf साथ लाता है, जो sshd jail चालू करता है, 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 में चिपकाकर चालू हालत वाला डिफ़ॉल्ट ओवरराइड कर दिया हो, जिससे बिना auth.log वाली इमेज पर journal से पढ़ने का सिलसिला ही टूट जाता है। या हो सकता है आप ऐसे कंटेनर में हों जहाँ पढ़ने के लिए कोई systemd journal है ही नहीं। fail2ban-client status sshd में Total failed जाँचें: अगर journalctl -u ssh असली असफलताएँ दिखाता रहे और यह कभी न चढ़े, तो jail ग़लत जगह पढ़ रहा है।

मैं अपना ही IP एड्रेस कैसे अनबैन करूँ?

sudo fail2ban-client set sshd unbanip YOUR.IP.HERE चलाएँ, जो सफल होने पर 1 लौटाता है, या हर बैन साफ़ करने के लिए sudo fail2ban-client unban --all। अगर आप SSH से लॉक-आउट हैं, तो वही कमांड अपने प्रोवाइडर के वेब या VNC कंसोल से चलाएँ — बैन आपके एड्रेस से पोर्ट 22 पर आने वाला हर पैकेट reject करता है, इसलिए पहले से खुला सेशन भी काम करना बंद कर देता है। फिर अपना एड्रेस ignoreip में जोड़ दें ताकि यह दोबारा न हो।

jail.conf और jail.local में क्या फ़र्क़ है?

jail.conf में Fail2ban के upstream डिफ़ॉल्ट रहते हैं और हर पैकेज अपग्रेड पर वह ओवरराइट हो जाती है, इसलिए वहाँ किया कोई भी बदलाव देर-सबेर खो जाता है। Debian/Ubuntu पैकेज jail.d/defaults-debian.conf के ज़रिए उसके ऊपर अपनी सेटिंग्स चढ़ाता है। आपके बदलावों की जगह jail.local है, जो सबसे आख़िर में पढ़ी जाती है, दोनों पर भारी पड़ती है, और जिसे अपग्रेड कभी नहीं छूते। jail.conf को सिर्फ़ पढ़ने भर के संदर्भ के तौर पर छोड़ दें।

क्या Fail2ban key-आधारित SSH ऑथेंटिकेशन की जगह ले लेता है?

नहीं। Fail2ban एक ही एड्रेस से बार-बार होती असफलताओं की रफ़्तार पर लगाम लगाता है; उस धीमे, कई एड्रेसों में बँटे (distributed) अंदाज़े लगाने के खेल के आगे यह कुछ नहीं कर पाता, जहाँ हर एड्रेस थ्रेशोल्ड के नीचे बना रहता है। key-only ऑथेंटिकेशन (PasswordAuthentication no) पासवर्ड के अंदाज़े सिरे से असंभव कर देता है, और तब Fail2ban लॉग का शोर छाँटता है और स्कैनरों को जल्दी बाहर करता है। दोनों चलाएँ, और हो सके तो SSH को पब्लिक इंटरनेट से पूरी तरह दूर ही रखें।