Ubuntu 24.04 वर Fail2ban ने SSH bots थांबवा

Fail2ban नेमके काय करते

Fail2ban हा logs वाचणारा daemon आहे. तो तुमचे SSH authentication messages monitor करतो. कमी कालावधीत एका address कडून अनेक authentication failures झाल्यानंतर तो firewall command चालवतो आणि त्या address ला काही काळासाठी block करतो. हीच त्याची संपूर्ण कार्यपद्धती आहे. एका file मधील configuration साधारण तीस lines ची असते. Ubuntu 24.04 वर installation साठी एकच apt command पुरेसा आहे. काहीही edit करण्यापूर्वीच त्यामुळे server संरक्षित होतो.

ते काय आहे आणि काय नाही, हे स्पष्ट असणे आवश्यक आहे. Fail2ban कोणाचेही authentication करत नाही. ते कोणतीही encryption करत नाही. तसेच एकच determined login attempt थांबवत नाही. ते फक्त त्याच source कडून होणारे repeated attempts थांबवते. Fail2ban हा noise filter आणि rate limiter आहे; तो lock नाही. Port 22 चे सतत होणारे background scanning तुमचा CPU, bandwidth आणि log space वाया घालवू नये, हे त्याचे मुख्य उद्दिष्ट आहे. तसेच attacker ला प्रत्येक वेळी एकाच address वरून प्रयत्न करावा लागत असल्यास त्याचा वेग कमी करणे, हेही त्याचे काम आहे.

Fail2ban कशाची जागा घेत नाही

Fail2ban हा पहिला स्तर नसून तिसरा स्तर आहे. तुमचा सर्व्हर अजूनही SSH password स्वीकारत असेल, तर हजारो पत्त्यांवर पसरलेले botnet password guessing सुरू ठेवू शकते. याचे कारण प्रत्येक पत्ता तुमच्या ban threshold पेक्षा कमी प्रयत्न करतो आणि ban लागू होत नाही. यावरील खरे संरक्षण म्हणजे key-only authentication. यामुळे कोणीही कितीही प्रयत्न केले तरी password guessing शक्य होत नाही.

key-only authentication वर Fail2ban वापरल्यास दोन उपयुक्त गोष्टी होतात: logs मधील brute-force noise कमी होते आणि scanners लवकर block होतात, त्यामुळे ते port वर वारंवार प्रयत्न करणे थांबवतात. याला defence in depth म्हणून वापरा. ते key authentication आणि firewall यांच्या मागे असते; त्यांच्याऐवजी किंवा त्यांच्यापूर्वी नाही.

पूर्वअट आणि Ubuntu 24.04 मधील प्रत्यक्ष स्थिती

तुमच्याकडे root किंवा sudo अधिकारांसह Ubuntu 24.04 चालणारा VPS आणि आधीपासून कार्यरत SSH असणे आवश्यक आहे. शक्य असल्यास key authentication वापरा. Fail2ban कमी संसाधने वापरते: काही दहा मेगाबाइट RAM पुरेशी असते आणि limits चे tuning करण्याची आवश्यकता नसते.

आता प्रत्येक जुन्या मार्गदर्शकात चुकीचा असलेला भाग पाहू. अनेक वर्षे प्रचलित सल्ला असा होता: "Fail2ban install करा आणि नंतर backend = systemd जोडा, कारण Ubuntu ने /var/log/auth.log लिहिणे बंद केले आहे." या सल्ल्यामागे खरा बदल आहे. आधुनिक server आणि cloud images मध्ये rsyslog नसते. त्यामुळे SSH logs फक्त systemd journal मध्ये लिहिले जातात आणि ती text file उपलब्ध नसते. मात्र Ubuntu 24.04 मध्ये Fail2ban package याची आधीच दखल घेते. Package /etc/fail2ban/jail.d/defaults-debian.conf ठेवते. Upstream defaults ऐवजी तुमचा server प्रत्यक्षात हीच configuration चालवतो:

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

[sshd]
enabled = true

हे काळजीपूर्वक वाचा, कारण कोणतीही configuration बदलण्यापूर्वी यामुळे दोन प्रश्न स्पष्ट होतात. backend = systemd याचा अर्थ SSH jail journal वाचते. त्यामुळे auth.log नसल्याने फरक पडत नाही. banaction = nftables याचा अर्थ bans nftables द्वारे लागू केले जातात. Ubuntu 24.04 प्रत्यक्षात हाच firewall वापरते; legacy iptables नाही. तसेच [sshd] enabled = true याचा अर्थ पहिल्या boot पासून jail सुरू असते. निष्कर्ष असा: Ubuntu 24.04 वरील stock apt install fail2ban SSH brute-force प्रयत्नांना कोणत्याही अतिरिक्त configuration शिवाय प्रतिबंधित करते. तुमच्या कामाचा बहुतांश भाग हे तपासणे, policy चे tuning करणे आणि स्वतःचा access बंद होणार नाही याची खात्री करणे हा आहे.

जुना auth.log सापळा अजूनही तीन परिस्थितींमध्ये आढळतो. त्या ओळखणे महत्त्वाचे आहे: तुम्ही Fail2ban pip ऐवजी apt वापरून install केले, त्यामुळे defaults-debian.conf उपलब्ध नाही; तुम्ही systemd journal वाचण्याची सुविधा नसलेल्या unprivileged container मध्ये आहात; किंवा जुन्या tutorial चे अनुसरण करून backend = auto तुमच्या स्वतःच्या jail.local मध्ये paste केले आणि कार्यरत default वर override केले. प्रत्येक परिस्थितीचे स्वरूप failure-modes विभागात नेमके दाखवले आहे.

पायरी 1: Fail2ban स्थापित करा आणि ते आधीपासून ban करत आहे याची खात्री करा

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04 सोबत Fail2ban 1.0.2 उपलब्ध येते. पॅकेजमध्ये python3-systemd ही hard dependency असल्यामुळे journal backend साठी आवश्यक सर्व घटक उपलब्ध असतात. सेवा स्वतः enable आणि start होते:

sudo systemctl status fail2ban

तुम्हाला active (running) हवे आहे. आता आधीपासून कार्यरत असलेला jail तपासा:

sudo fail2ban-client status sshd

काही मिनिटे जरी सार्वजनिक VPS इंटरनेटवर उपलब्ध असेल, तरी अनेकदा failures ची संख्या आणि banned addresses आधीच दिसतात. इंटरनेटवरून port 22 वर सतत scans होत असतात. यावरून stock config योग्यरीत्या काम करत असल्याचे सिद्ध होते. यानंतर तुम्ही त्यात सुधारणा करणार आहात; ते शून्यापासून तयार करणार नाही.

पायरी 2: jail.local संपादित करा, jail.conf कधीही संपादित करू नका

Fail2ban त्याचे upstream default /etc/fail2ban/jail.conf मध्ये ठेवते. ती फाइल संपादित करू नका. पॅकेजचे प्रत्येक apt upgrade ती फाइल बदलू शकते आणि तुमचे बदल कोणतीही सूचना न देता नाहीसे होऊ शकतात. Fail2ban फाइल्स ठरावीक क्रमाने वाचते: प्रथम jail.conf, त्यानंतर jail.d/ मधील सर्व फाइल्स आणि मग jail.local. शेवटी वाचलेली value लागू होते. .local फाइल तुमच्यासाठी आहे आणि package upgrades तिच्यात कधीही बदल करत नाहीत. हाच नियम filters साठीही लागू होतो. त्यामध्ये *.local फाइल shipped filter.d/*.conf वर override करते.

म्हणून तुम्हाला आवश्यक असलेल्या मोजक्या settings बदलणारी छोटी jail.local लिहा. संदर्भासाठी jail.conf आणि packaged jail.d/defaults-debian.conf दोन्ही अपरिवर्तित ठेवा.

पायरी 3: /etc/fail2ban/jail.local लिहा

sudo nano /etc/fail2ban/jail.local

यामध्ये ही सामग्री लिहा. ignoreip ओळीवरील address तुमच्या स्वतःच्या 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 ठरवतात. वितरित केलेला default bantime फक्त दहा मिनिटांचा आहे; एक तास हा अधिक योग्य किमान कालावधी आहे. दहा मिनिटांच्या आत एका address कडून पाच failures झाल्यास ban लागू होतो. वास्तविक वापरकर्ते password एकदा किंवा दोनदा चुकीचा टाइप करू शकतात; दहा मिनिटांत पाच failures म्हणजे script चालू असल्याचे संकेत आहेत.
• ignoreip हा तुमचा safety belt आहे. ज्या public address वरून तुम्ही connect होता तो येथे लिहा, म्हणजे Fail2ban तुम्हाला तुमच्याच server पासून कधीही lock out करू शकणार नाही. बदलणारा IP असलेले home connection असल्यास शेवटी दिलेला VPN approach वापरणे योग्य ठरते; ही line वगळण्याचे ते कारण नाही.
• bantime.increment = true मुळे प्रत्येक repeat ban मागील ban पेक्षा अधिक काळ लागू राहतो: प्रथम एक तास, नंतर दोन, त्यानंतर चार, आणि कमाल bantime.maxtime पर्यंत. वारंवार परतणाऱ्या addresses वर क्रमशः अधिक दीर्घकाळ lockout लागू होतो.

तुम्ही SSH ज्या machine वरून करता त्या machine वरून whitelist करण्यासाठी address शोधा; server वरून नाही:

curl -s ifconfig.me

तुमच्या ports आणि ban policy नुसार तयार केलेला jail.local येथे generate करा आणि तो file मध्ये paste करा:

पायरी 4: रीस्टार्ट करा आणि ते journal वाचत आहे याची पडताळणी करा

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

-t प्रथम config test चालवते. त्यामुळे jail.local मध्ये typo असल्यास सेवा बंद राहण्याऐवजी येथे स्पष्टपणे अपयश दिसते. कार्यरत 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 तुमचे logins खरोखर वाचत आहे हे सिद्ध करणारी संख्या Total failed आहे. ती शून्यापेक्षा जास्त असल्यास, किंवा दुसऱ्या मशीनवरून जाणूनबुजून login अयशस्वी केल्यावर ती वाढत असल्यास, journal वाचले जात आहे आणि तुमचे काम पूर्ण झाले. ती कितीही वेळा login अयशस्वी केल्यानंतरही 0 वरच राहिल्यास, आणि तुम्ही ignoreip मधील address वरून चाचणी करत नसल्याची खात्री असल्यास, खालील failure modes विभागाकडे जा.

Journal matches ओळ अजूनही sshd.service हे नाव दाखवते, हे लक्षात घ्या. Ubuntu वर SSH unit प्रत्यक्षात ssh.service आहे. मात्र वितरित filter _COMM=sshd शी देखील जुळतो. OpenSSH 24.04 मध्ये त्याचे failures sshd नावाच्या process कडून log केले जातात. त्यामुळे हा match कार्य करतो. तुम्ही नवीन OpenSSH वापरत असल्यासच हा तपशील महत्त्वाचा आहे. OpenSSH 9.8 किंवा त्यानंतरच्या आवृत्तीत प्रत्येक connection साठीचा worker sshd-session असतो. Failure modes विभागात ही परिस्थिती समाविष्ट आहे.

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

सार्वजनिक VPS वर प्रत्यक्ष ban काही मिनिटांत आपोआप लागू होतात. एखादा ban पाहण्यासाठी log चा शेवटचा भाग सतत पहा:

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 करा. स्वतःचा address कधीही वापरू नका:

sudo fail2ban-client set sshd banip 10.0.0.66

यामध्ये 1 असे output दिसते आणि fail2ban-client status sshd मधील Banned IP list अंतर्गत तो address दिसतो. आता firewall मध्ये block प्रत्यक्षात अस्तित्वात आहे का ते पडताळा. Ubuntu 24.04 मध्ये हे iptables नसून nftables आहे:

sudo nft list table inet f2b-table

तुम्हाला 10.0.0.66 असलेला addr-set-sshd नावाचा set आणि त्या set मधील कोणत्याही source ला reject करणारी f2b-chain chain दिसेल. fail2ban-client मध्ये एखादा address banned असल्याचे दिसत असेल, पण nft list मध्ये काहीही दिसत नसेल, तर तुमची ban action आणि firewall यांच्यात सुसंगतता नाही. यासाठी failure modes मधील nftables/iptables संबंधी सूचना पहा.

चरण 6: स्वतःवरील बंदी काढा आणि प्रवेश बंद झाल्यास पुनर्प्राप्ती करा

ज्या पत्त्यावर बंदी घालू नये होता, म्हणजेच आपल्या स्वतःच्या पत्त्यावर, बंदी घातली असल्यास ती काढा:

sudo fail2ban-client set sshd unbanip 10.0.0.66

यशस्वी झाल्यावर हे 1 परत करते. प्रत्येक jail मधील सर्व बंदी काढण्यासाठी:

sudo fail2ban-client unban --all

आपले आधीपासून उघडे असलेले SSH सत्र आपल्याला वाचवेल असे गृहीत धरू नका: nftables मधील बंदी घातलेल्या पत्त्याकडून port 22 वरील प्रत्येक packet नाकारते. यात आधीच स्थापित झालेल्या connections चा देखील समावेश होतो. त्यामुळे बंदी लागू होताच विद्यमान session थांबते. आपण स्वतःवर बंदी घातली आणि आपल्याकडे ignoreip entry नसल्यास, बंदीची मुदत संपेपर्यंत आपला प्रवेश बंद राहतो. आपल्या provider च्या web console द्वारे पुनर्प्राप्ती करा. VNC किंवा serial console SSH मार्गे जोडलेले नसतात. तेथे bantime संपेपर्यंत प्रतीक्षा करा किंवा unban command चालवा.

पायरी 7: प्रतिबंध कायम ठेवा आणि त्यांची तीव्रता वाढवा

Fail2ban सक्रिय प्रतिबंध /var/lib/fail2ban/fail2ban.sqlite3 येथील छोट्या SQLite database मध्ये ठेवते. त्यामुळे service restart किंवा reboot नंतरही ते कायम राहतात; ते गमावले जात नाहीत. तुम्ही आधी जोडलेल्या bantime.increment ओळी प्रत्येक पुनरावृत्ती करणाऱ्या आक्रमकासाठी प्रतिबंधाची तीव्रता वाढवतात. ही मुदत साधारणपणे one hour पासून one week पर्यंत जवळपास दुप्पट वाढते.

याशिवाय संपूर्ण system साठी "three strikes" धोरण लागू करण्याकरिता Fail2ban मध्ये recidive jail उपलब्ध आहे. ते स्वतःच्या /var/log/fail2ban.log वर लक्ष ठेवते आणि सर्व jails मध्ये वारंवार प्रतिबंधित झालेल्या कोणत्याही address साठी दीर्घकालीन प्रतिबंध लागू करते. तुमचे [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 ओळी प्रत्यक्षात त्याच ठिकाणी दिसतात. तुम्ही जागतिक स्तरावर सेट केलेला systemd default मात्र ते journal कडे निर्देशित करेल, जिथे त्या ओळी उपलब्ध नसतात.

पायरी 8: केवळ key authentication वापरा; शक्य असल्यास 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. Password authentication बंद केल्यावर brute-force प्रयत्न यशस्वी होऊ शकत नाहीत. त्यामुळे Fail2ban चा उपयोग log मधील अनावश्यक नोंदी कमी करण्यासाठी आणि scanners ना सुरुवातीलाच अडवण्यासाठी होतो. याहून सुरक्षित पर्याय म्हणजे SSH सार्वजनिक internet वर पूर्णपणे उपलब्ध न ठेवणे: SSH self-hosted WireGuard VPN मागे ठेवा आणि port 22 असा firewall नियम लावा की तो फक्त tunnel वरून आलेल्या विनंत्यांना उत्तर देईल. ज्या port पर्यंत पोहोचताच येत नाही, त्यावर कोणी brute-force करू शकत नाही. त्यामुळे Fail2ban हे मुख्य संरक्षण न राहता अतिरिक्त संरक्षण ठरते.

Fail2ban केवळ SSH साठी नाही. Failed login नोंदवणाऱ्या कोणत्याही सेवेसाठी jail तयार करता येतो. यात mail server, nginx site किंवा self-hosted Vaultwarden password manager यांचा समावेश होतो. Credential stuffing साठी त्याचे web login खुले ठेवणे टाळायचे असल्यास ही रचना उपयुक्त ठरते. एखादे web app Let's Encrypt certificate असलेल्या nginx site मागे चालत असल्यावर, SSH jail journal वर जसा filter लावतो त्याच प्रकारे Fail2ban filter त्याच्या access log वर लावा.

अपयशाच्या स्थिती आणि दिसणारे अचूक संदेश

"Have not found any log file for sshd jail", आणि Fail2ban सुरू होत नाही. ही जुनी auth.log समस्या आहे. Ubuntu 24.04 वर ही समस्या फक्त तेव्हाच दिसते, जेव्हा पॅकेजचा default बदलला असेल, pip install मध्ये defaults-debian.conf नसेल, journal नसलेला container असेल किंवा jail.local मध्ये तुम्ही चुकीने backend = auto पेस्ट केले असेल. /var/log/auth.log नसलेल्या file backend मध्ये sshd jail ला त्याची log सापडत नाही आणि संपूर्ण daemon बंद होतो. fail2ban.log हे दाखवते:

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

हा error fatal असल्यामुळे service कधीही सुरू होत नाही. त्यानंतर fail2ban-client status पुढील परिणाम दाखवते:

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

"socket path" ही ओळ Fail2ban मध्ये बिघाड आहे असे सांगत नाही. एका jail ला तिची log सापडली नाही म्हणून Fail2ban सुरूच झाले नाही, असे ती सांगते. [DEFAULT] मध्ये backend = systemd सेट केल्यास दोन्ही संदेश एकाच वेळी दूर होतात. Ubuntu package हे तुमच्यासाठी आधीच करते.

Jail सक्रिय आहे, पण Total failed मध्ये कधीही वाढ होत नाही. Daemon सुरू आहे आणि journal वाचली जात आहे. तरीही journalctl -u ssh मध्ये प्रत्यक्ष अपयशी प्रयत्न जमा होत आहेत, तर counter 0 वरच राहतो. प्रथम स्पष्ट कारण दूर करा: तुम्ही ignoreip मध्ये असलेल्या address वरून चाचणी करत आहात. त्यामुळे तुमचे स्वतःचे अपयशी प्रयत्न रचनेनुसार वगळले जातात. तसे नसल्यास, तुम्ही OpenSSH च्या अशा build वर असू शकता ज्यामध्ये प्रत्येक connection साठीचा worker sshd-session (9.8 आणि त्यानंतरच्या आवृत्त्यांमध्ये) आहे. त्याच्या journal _COMM मध्ये sshd-session असते, sshd नाही. त्यामुळे वितरित 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. तुम्ही तुमचा स्वतःचा address ignoreip मधून वगळला आणि काही चुकीचे login प्रयत्न केले. आता:

ssh: connect to host 10.0.0.10 port 22: Connection refused

ही नकारात्मक प्रतिक्रिया silent timeout ऐवजी दिसते, कारण nftables action चा default reject verdict तुमच्यावर लागू झाला आहे. Step 6 प्रमाणे दुरुस्ती करा: वेगळ्या, unbanned address वरील session मधून unban करा किंवा provider console वापरा. Banned address वरून आधीच उघडलेले session देखील स्थिर होते. हे पुन्हा होऊ नये म्हणून तुमचा address ignoreip मध्ये जोडा.

Fail2ban सांगते की address banned आहे, पण तो connect होऊ शकतो. status sshd मधील counter वाढतो, तरीही address port 22 पर्यंत पोहोचतो. याचा अर्थ ban action आणि firewall यांच्यात विसंगती आहे. Ubuntu 24.04 वर याचे जवळजवळ नेहमीचे कारण असे असते की तुम्ही कार्यरत banaction = nftables बदलून जुन्या guide मधून कॉपी केलेले banaction = iptables-multiport वापरले आहे आणि त्या server वर iptables layer नाही. fail2ban.log हे दाखवते:

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

तो override काढून टाका आणि package मधील nftables action वापरू द्या. किंवा firewall पूर्णपणे ufw द्वारे व्यवस्थापित करत असाल आणि bans तेथे दिसावेत असे वाटत असेल, तर [DEFAULT] मध्ये banaction = ufw सेट करा. Restart करा आणि sudo nft list ruleset | grep f2b वापरून rule दिसत असल्याची खात्री करा.

jail.local संपादित केल्यानंतर Fail2ban सुरू होत नाही. Typo, चुकीचे heading किंवा अवैध time value असल्यास service सुरू होण्यास नकार देते. Service सुरू करण्यापूर्वी Fail2ban कडून configuration तपासून घ्या:

sudo fail2ban-client -t

समस्या असलेली file आणि jail ते दाखवते. उदाहरणार्थ, Errors in jail 'sshd'. Skipping.... त्यामुळे अंदाजाने नव्हे, तर मूळ configuration दुरुस्त करता येते.

FAQ

Ubuntu 24.04 वरील मूळ Fail2ban install SSH हल्ले प्रत्यक्षात block करते का?

होय. या package मध्ये /etc/fail2ban/jail.d/defaults-debian.conf उपलब्ध आहे. त्यामुळे sshd jail enable होते. backend = systemd सेट केलेले असल्यामुळे अनुपस्थित /var/log/auth.log ऐवजी systemd journal वाचला जातो. banaction = nftables सेट केलेले असल्यामुळे bans Ubuntu च्या प्रत्यक्ष firewall द्वारे लागू होतात. साधे apt install fail2ban पहिल्या boot पासून SSH चे संरक्षण करते. sudo fail2ban-client status sshd वापरून याची खात्री करा आणि Total failed ची किंमत शून्यापेक्षा जास्त आहे का ते तपासा.

माझ्या server वर Fail2ban काहीही ban का करत नाही?

सामान्य तीन कारणे क्रमाने तपासा. तुम्ही ignoreip मधील address वरून चाचणी करत असू शकता. हा address रचनेनुसार exempt असतो. जुन्या मार्गदर्शकातील backend = auto हे jail.local मध्ये paste करून तुम्ही कार्यरत default override केलेले असू शकते. auth.log नसलेल्या image वर यामुळे journal वाचन बंद होते. किंवा systemd journal वाचण्यासाठी काहीही उपलब्ध नसलेल्या container मध्ये तुम्ही असू शकता. fail2ban-client status sshd मधील Total failed तपासा. journalctl -u ssh मध्ये प्रत्यक्ष failures दिसत असताना त्याची संख्या कधीही वाढत नसेल, तर jail चुकीचे ठिकाण वाचत आहे.

माझा स्वतःचा IP address unban कसा करू?

sudo fail2ban-client set sshd unbanip YOUR.IP.HERE चालवा. यशस्वी झाल्यावर ते 1 परत करते. सर्व bans काढण्यासाठी sudo fail2ban-client unban --all चालवा. SSH मधून lock out झाल्यास, तुमच्या provider चे web किंवा VNC console वापरून हाच command चालवा. ban मुळे तुमच्या address कडून port 22 कडे जाणारे प्रत्येक packet नाकारले जाते. त्यामुळे आधीपासून उघडलेले session देखील काम करणे थांबवते. त्यानंतर तुमचा address ignoreip मध्ये जोडा, जेणेकरून ही समस्या पुन्हा उद्भवणार नाही.

jail.conf आणि jail.local यांच्यात काय फरक आहे?

jail.conf मध्ये Fail2ban चे upstream defaults असतात. प्रत्येक package upgrade वेळी ही file overwrite होते. त्यामुळे त्यातील कोणताही बदल शेवटी नष्ट होतो. Debian/Ubuntu package आपली settings jail.d/defaults-debian.conf द्वारे त्यावर लागू करते. तुमचे बदल jail.local मध्ये असावेत. ही file सर्वांत शेवटी वाचली जाते आणि दोन्हीपेक्षा हिची settings प्राधान्याने लागू होतात. Upgrade वेळी या file मध्ये बदल केला जात नाही. jail.conf फक्त read-only संदर्भासाठी ठेवा.

Fail2ban key-based SSH authentication ची जागा घेते का?

नाही. Fail2ban एका address कडून होणाऱ्या repeated failures वर rate limit लावते. प्रत्येक address threshold च्या खाली राहणाऱ्या slow, distributed guess विरुद्ध ते काहीही करत नाही. Key-only authentication (PasswordAuthentication no) password guessing पूर्णपणे अशक्य करते. त्यानंतर Fail2ban log मधील अनावश्यक नोंदी कमी करते आणि scanners ना लवकर दूर करते. दोन्ही वापरा. शक्य असल्यास SSH पूर्णपणे public internet पासून दूर ठेवा.