Install Fail2ban sa Ubuntu 24.04 para I-block ang SSH Bots

Ano talaga ang ginagawa ng Fail2ban

Ang Fail2ban ay isang daemon na nagbabasa ng log. Minomonitor nito ang mga mensahe ng SSH authentication. Kapag nakakita ito ng ilang magkakasunod na failure mula sa isang address sa loob ng maikling panahon, nagpapatakbo ito ng firewall command na pansamantalang nagba-block sa address na iyon. Iyon ang buong ideya. Humigit-kumulang 30 linya lang ng configuration ang kailangan sa isang file. Sa Ubuntu 24.04, isang apt command lang ang kailangan para sa installation, at mapoprotektahan ka na nito bago ka pa mag-edit ng kahit ano.

Maging malinaw kung ano ito at kung ano ang hindi nito ginagawa. Hindi nag-a-authenticate ng sinuman ang Fail2ban. Hindi rin ito nag-e-encrypt ng anuman. Hindi nito napipigilan ang isang determinadong login attempt; ang napipigilan lamang nito ay ang paulit-ulit na attempt mula sa iisang source. Isa itong noise filter at rate limiter, hindi lock. Layunin nitong pigilan ang tuloy-tuloy na background scanning sa port 22 na aksayahin ang iyong CPU, bandwidth, at log space. Pinapabagal din nito ang attacker na kailangang gumamit ng tig-iisang address sa bawat attempt.

Mga Hindi Pinapalitan ng Fail2ban

Ang Fail2ban ay ikatlong layer, hindi unang layer. Kung tumatanggap pa rin ang server ng SSH passwords, maaaring patuloy na manghula ang isang botnet na kalat sa libo-libong address, dahil nananatili sa ibaba ng ban threshold ang bawat address at hindi ito nagti-trigger. Ang tunay na depensa laban dito ay key-only authentication, na ginagawang imposible ang password guessing gaano man karaming pagtatangka ang gawin. Kapag ginamit kasabay ng key-only auth, dalawang kapaki-pakinabang na bagay ang ginagawa ng Fail2ban: inaalis nito sa logs ang ingay mula sa brute-force attempts, at maaga nitong bina-ban ang mga scanner para tumigil ang mga ito sa paulit-ulit na pagtama sa port. Ituring ito bilang defense in depth. Nakapuwesto ito sa likod ng key authentication at firewall, hindi kailanman sa unahan ng mga ito.

Mga prerequisite at ang aktuwal na sitwasyon sa Ubuntu 24.04

Kailangan mo ng VPS na nagpapatakbo ng Ubuntu 24.04, may root o sudo access, at gumagana na ang SSH, mas mainam kung key authentication ang gamit. Matipid sa resources ang Fail2ban: ilang sampung megabytes lang ng RAM ang kailangan, at hindi na kailangang mag-tune ng mga limit.

Narito ang bahagi na madalas mali sa mga lumang guide. Sa loob ng maraming taon, ang karaniwang payo ay “i-install ang Fail2ban, pagkatapos ay idagdag ang backend = systemd, dahil tumigil ang Ubuntu sa pagsusulat sa /var/log/auth.log.” Inilalarawan ng payong ito ang isang totoong pagbabago: walang rsyslog ang mga modern server at cloud image, kaya sa systemd journal lamang nagsusulat ng SSH logs at wala na ang text file na iyon. Ngunit sa Ubuntu 24.04, isinasaalang-alang na ito ng Fail2ban package. Naglalagay ang package ng /etc/fail2ban/jail.d/defaults-debian.conf, at ang file na iyon—hindi ang upstream defaults—ang aktuwal na ginagamit ng iyong server:

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

[sshd]
enabled = true

Basahin itong mabuti dahil sinasagot nito ang dalawang tanong bago ka magbago ng kahit ano. Ibig sabihin ng backend = systemd, journal ang binabasa ng SSH jail, kaya hindi mahalaga na wala ang auth.log. Ibig sabihin ng banaction = nftables, nftables ang ginagamit para ipatupad ang mga ban. Ito ang firewall na aktuwal na ginagamit ng Ubuntu 24.04, sa halip na legacy iptables. Ibig sabihin naman ng [sshd] enabled = true, naka-enable ang jail mula sa unang boot. Sa madaling sabi: ang stock na apt install fail2ban sa Ubuntu 24.04 ay awtomatikong nagba-ban ng SSH brute-force. Karamihan ng gagawin mo ay pagkumpirma nito, pag-tune ng policy, at pagtiyak na hindi mo mai-lock out ang sarili mo.

May tatlong sitwasyon kung kailan nagdudulot pa rin ng problema ang lumang auth.log trap, kaya mahalagang makilala ang mga ito: na-install mo ang Fail2ban gamit ang pip sa halip na apt, kaya walang defaults-debian.conf; nasa loob ka ng unprivileged container na walang systemd journal na mababasa; o sinunod mo ang lumang tutorial at inilagay ang backend = auto sa sarili mong jail.local, kaya na-override ang gumaganang default. Ipinapakita ng seksyong failure modes kung ano mismo ang hitsura ng bawat sitwasyon.

Hakbang 1: I-install at tiyaking nagba-ban na ito

sudo apt update
sudo apt install -y fail2ban

Kasamang nire-release sa Ubuntu 24.04 ang Fail2ban 1.0.2, at hinihila ng package ang python3-systemd bilang hard dependency. Kaya kumpleto na ang kailangan ng journal backend. Awtomatikong ini-enable at sini-start ng service ang sarili nito:

sudo systemctl status fail2ban

Dapat makita mo ang active (running). Pagkatapos, tingnan ang jail na gumagana na:

sudo fail2ban-client status sshd

Sa isang public VPS na reachable na kahit ilang minuto pa lamang, madalas ay makikita mo nang may mga failure na nabilang at mga address na na-ban. Patuloy na ini-scan ng internet ang port 22. Patunay ito na gumagana ang stock config. Mula rito, nire-refine mo na lang ito, hindi mo ito binubuo mula sa simula.

Hakbang 2: I-edit ang jail.local, hindi ang jail.conf

Pinapanatili ng Fail2ban ang upstream defaults nito sa /etc/fail2ban/jail.conf. Huwag i-edit ang file na iyon. Maaaring palitan ito ng bawat apt upgrade ng package, at mawawala ang mga pagbabago mo nang walang babala. Binabasa ng Fail2ban ang mga file sa nakatakdang pagkakasunod-sunod: jail.conf muna, pagkatapos ang lahat ng nasa jail.d/, at saka ang jail.local; ang huling value ang ginagamit. Ang file na .local ay sa iyo, at hindi ito ginalaw ng mga package upgrade. Pareho ang patakaran para sa filters: ino-override ng *.local file ang kasamang filter.d/*.conf.

Kaya gumawa ka ng maliit na jail.local na nag-o-override lamang sa ilang setting na kailangan mo, at huwag galawin ang jail.conf at ang naka-package na jail.d/defaults-debian.conf upang manatili silang reference.

Hakbang 3: Isulat ang /etc/fail2ban/jail.local

sudo nano /etc/fail2ban/jail.local

Ilagay ito, at palitan ang address sa linyang ignoreip ng sarili mong 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

May dahilan ang bawat linya:

• bantime, findtime, at maxretry ang policy. Sampung minuto lamang ang shipped default na bantime; mas makatuwiran ang isang oras bilang minimum. Kapag limang beses nag-fail mula sa isang address sa loob ng sampung minuto, maba-ban ito. Karaniwang nagkakamali ang totoong user sa password nang isa o dalawang beses; ang limang failure sa loob ng sampung minuto ay malamang na script.
• ignoreip ang safety belt mo. Ilagay rito ang public address na pinanggagalingan ng koneksyon mo para hindi ka kailanman ma-lock out ng Fail2ban sa sarili mong server. Kung pabago-bago ang IP ng home connection mo, dahilan ito para piliin ang VPN approach sa dulo, hindi para laktawan ang linyang ito.
• Ginagawang mas mahaba ng bantime.increment = true ang bawat kasunod na ban kaysa sa nauna: isang oras, pagkatapos ay dalawang oras, at pagkatapos ay apat na oras, hanggang bantime.maxtime. Ang mga address na paulit-ulit na bumabalik ay unti-unting mas matagal na nasi-lock out.

Hanapin ang address na ilalagay sa whitelist mula sa machine kung saan ka nag-SSH, hindi mula sa server:

curl -s ifconfig.me

Maaari kang bumuo rito ng jail.local na nakaayon sa mga port at ban policy mo, pagkatapos ay i-paste ito sa file:

Hakbang 4: I-restart at i-verify na binabasa nito ang journal

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

Unang nagpapatakbo ng config test ang -t, kaya kung may typo sa jail.local, malinaw itong magfa-fail dito sa halip na manatiling down ang service. Ganito ang status ng isang gumaganang 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

Ang numerong nagpapatunay na talagang binabasa ng Fail2ban ang iyong mga login ay Total failed. Kung mas mataas ito sa zero, o tumataas kapag sinadya mong mag-fail ng login mula sa ibang machine, binabasa ang journal at tapos ka na. Kung nananatili ito sa 0 kahit ilang beses kang mag-fail, at sigurado kang hindi ka nagte-test mula sa address sa ignoreip, pumunta sa mga failure mode sa ibaba.

Pansinin na tinutukoy pa rin ng linyang Journal matches ang sshd.service. Sa Ubuntu, ang aktuwal na SSH unit ay ssh.service, pero tumutugma rin ang kasamang filter sa _COMM=sshd. Itinatala rin ng OpenSSH sa 24.04 ang mga failure nito mula sa process na may pangalang sshd, kaya gumagana ang match. Mahalaga lamang ang detalyeng ito kung gumagamit ka ng mas bagong OpenSSH (9.8 o mas bago, kung saan ang per-connection worker ay sshd-session); saklaw ng mga failure mode ang kasong iyon.

Hakbang 5: Subaybayan ang aktuwal na ban o piliting gumawa nito para sa testing

Awtomatikong lumilitaw ang mga totoong ban sa loob ng ilang minuto sa anumang public VPS. Para subaybayan ang isa, gamitin ang tail sa log:

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

Ganito ang hitsura ng isang 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

Para subukan ang buong proseso nang end to end nang hindi naghihintay, manu-manong i-ban ang isang address para sa documentation. Huwag kailanman ang sarili mong address:

sudo fail2ban-client set sshd banip 10.0.0.66

Ipi-print nito ang 1, at lalabas ang address sa ilalim ng Banned IP list sa fail2ban-client status sshd. Ngayon, kumpirmahing talagang umiiral ang block sa firewall. Sa Ubuntu 24.04, nftables ang ginagamit, hindi iptables:

sudo nft list table inet f2b-table

Makakakita ka ng set na may pangalang addr-set-sshd na naglalaman ng 10.0.0.66, at chain na f2b-chain na nagre-reject sa anumang source na nasa set na iyon. Kung sinasabi ng fail2ban-client na banned ang isang address pero walang lumalabas sa nft list, hindi tugma ang ban action mo sa firewall. Tingnan ang tala tungkol sa nftables/iptables sa failure modes.

Hakbang 6: I-unban ang sarili at mag-recover kapag na-lock out

Kung na-ban mo ang isang address na hindi dapat ma-ban, kasama ang sarili mong address, alisin ito:

sudo fail2ban-client set sshd unbanip 10.0.0.66

Ibabalik nito ang 1 kapag matagumpay. Para i-clear ang lahat ng ban sa lahat ng jail:

sudo fail2ban-client unban --all

Huwag umasa sa kasalukuyang bukas na SSH session para mailigtas ka: tinatanggihan ng nftables ban ang bawat packet mula sa banned address papunta sa port 22, kasama ang mga packet para sa established connections. Dahil dito, nag-freeze ang kasalukuyang session sa sandaling maipatupad ang ban. Kung na-ban mo ang sarili mo at wala kang ignoreip entry, naka-lock out ka hanggang mag-expire ang ban. Mag-recover sa web console ng provider mo, gaya ng VNC o serial, na hindi dumadaan sa SSH, at hintaying matapos ang bantime o patakbuhin doon ang unban command.

Hakbang 7: Gawing persistent at pataasin ang tagal ng mga ban

Itinatago ng Fail2ban ang mga aktibong ban sa isang maliit na SQLite database sa /var/lib/fail2ban/fail2ban.sqlite3, kaya nananatili ang mga ito pagkatapos i-restart ang service o mag-reboot; hindi mo mawawala ang mga ito. Ginagawang lumalaking problema para sa mismong repeat offender ang bawat bantime.increment line na idinagdag mo na, at tinatayang dumodoble ang tagal mula 1 oras hanggang humigit-kumulang 1 linggo.

Para sa system-wide na policy na "three strikes", may kasamang recidive jail ang Fail2ban. Binabantayan nito ang sarili nitong /var/log/fail2ban.log at nagbibigay ng mahahabang ban sa anumang address na paulit-ulit nang na-ban sa lahat ng jail. Dahil ginagamit na ngayon ng iyong [DEFAULT] ang systemd backend, ibalik ang jail na ito sa log file na idinisenyo nitong basahin:

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

Pinananatili ng backend = auto na may explicit na logpath ang pagbasa ng recidive sa plain na fail2ban.log. Dito aktuwal na lumalabas ang mga Ban line na binibilang nito. Kung hindi ito itatakda, ituturo ito ng systemd default na itinakda mo globally sa journal, kung saan hindi lumalabas ang mga line na iyon.

Hakbang 8: Ipares ito sa key-only SSH, at mas mabuti pa, sa isang VPN

May silbi ang Fail2ban kapag ginagamit kasabay ng key authentication. Sa isang drop-in file sa ilalim ng /etc/ssh/sshd_config.d/, halimbawa /etc/ssh/sshd_config.d/00-hardening.conf, itakda ang:

PasswordAuthentication no
KbdInteractiveAuthentication no

Pagkatapos, sudo systemctl restart ssh. Kapag naka-off ang mga password, hindi maaaring magtagumpay ang brute-force attack; ginagamit ang Fail2ban upang bawasan ang ingay sa log at paalisin agad ang mga scanner. Mas matibay kung ganap na hindi ilalantad sa public internet ang SSH: ilagay ang SSH sa likod ng self-hosted WireGuard VPN at i-firewall ang port 22 upang sumagot lamang ito sa tunnel. Walang makakapag-brute-force sa port na hindi nila maaabot, kaya nagsisilbi ang Fail2ban bilang backup protection sa halip na unang depensa.

Hindi lamang para sa SSH ang Fail2ban. Anumang service na nagla-log ng mga bigong login ay maaaring lagyan ng jail, kabilang ang mail server, nginx site, o self-hosted na Vaultwarden password manager na mas mabuting hindi hayaang bukas sa credential stuffing. Kapag nasa likod na ng nginx site na may Let's Encrypt certificate ang isang web app, ituro ang Fail2ban filter sa access log nito sa parehong paraan na nakaturo ang SSH jail sa journal.

Mga failure mode, kasama ang eksaktong strings na makikita mo

"Have not found any log file for sshd jail", at hindi mag-start ang Fail2ban. Ito ang lumang problema sa auth.log, at sa Ubuntu 24.04 mangyayari lamang ito kung may nag-override sa default na kasama sa package, isang pip install na walang defaults-debian.conf, isang container na walang journal, o isang maling backend = auto na na-paste mo sa jail.local. Sa file backend na walang /var/log/auth.log, hindi mahanap ng sshd jail ang log nito kaya nag-a-abort ang buong daemon. Ipinapakita ng fail2ban.log ang sumusunod:

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

Dahil fatal ang error na ito, hindi kailanman umaandar ang service, at iniuulat naman ng fail2ban-client status ang kasunod na sintomas:

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

Ang linyang "socket path" ay hindi nangangahulugang sira ang Fail2ban. Ibig sabihin nito, hindi ito nag-start dahil hindi mahanap ng isang jail ang log nito. Ang pag-set ng backend = systemd sa [DEFAULT], na ginagawa na ng Ubuntu package para sa iyo, ay nag-aayos sa dalawang mensahe nang sabay.

Active ang jail pero hindi kailanman gumagalaw ang Total failed. Tumatakbo ang daemon at binabasa ang journal, pero naiipon ang mga totoong failure sa journalctl -u ssh habang nananatili sa 0 ang counter. Unang alisin ang karaniwang dahilan: nagte-test ka mula sa address na nasa ignoreip, kaya sadyang hindi kasama ang sarili mong failures. Kung hindi iyon ang dahilan, gumagamit ka ng OpenSSH build kung saan ang per-connection worker ay sshd-session (9.8 at mas bago), at ang journal _COMM nito ay sshd-session, hindi sshd, kaya hindi ito natutugma ng kasamang match. Palawakin ang match sa [sshd] block:

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

Mag-restart, sadyang mag-fail ng login mula sa address na wala sa ignoreip, at kumpirmahing sa wakas ay tumataas ang Total failed.

Na-ban mo ang sarili mo: Connection refused. Hindi mo isinama ang sarili mong address sa ignoreip, nag-test ka ng ilang maling login, at ngayon ay ganito:

ssh: connect to host 10.0.0.10 port 22: Connection refused

Ang pagtanggi, sa halip na silent timeout, ay default na reject verdict ng nftables action na gumagana laban sa iyo. Ayusin ito gaya ng nasa Step 6: mag-unban mula sa session sa ibang address na hindi banned, o mula sa provider console. Nagye-freeze rin ang session na bukas na mula sa banned address. Pagkatapos, idagdag ang sarili mong address sa ignoreip para hindi na ito maulit.

Sinasabi ng Fail2ban na banned ang isang address, pero nakakakonekta pa rin ito. Tumataas ang counter sa status sshd, pero nakakarating pa rin ang address sa port 22. Mismatch ito sa pagitan ng ban action at firewall, at sa Ubuntu 24.04 halos palaging nangangahulugan itong pinalitan mo ang gumaganang banaction = nftables ng banaction = iptables-multiport na kinopya mula sa mas lumang guide, sa server na walang iptables layer. Ipinapakita ng fail2ban.log ang sumusunod:

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

Burahin ang override na iyon at gamitin ang packaged nftables action, o, kung buong-buo mong pinamamahalaan ang firewall sa pamamagitan ng ufw at gusto mong lumitaw doon ang mga ban, i-set ang banaction = ufw sa [DEFAULT]. Mag-restart at kumpirmahing lumilitaw ang rule gamit ang sudo nft list ruleset | grep f2b.

Hindi mag-start ang Fail2ban matapos i-edit ang jail.local. Dahil sa typo, maling heading, o maling time value, maaaring tumangging mag-start ang service. Hingin sa Fail2ban na suriin ang config bago ito tumakbo:

sudo fail2ban-client -t

Papangalanan nito ang file at jail na may problema, halimbawa Errors in jail 'sshd'. Skipping..., kaya maaayos mo ang source sa halip na manghula.

FAQ

Talaga bang bina-ban ng stock Fail2ban install sa Ubuntu 24.04 ang mga SSH attack?

Oo. Kasama sa package ang /etc/fail2ban/jail.d/defaults-debian.conf, na nag-e-enable sa sshd jail, nagse-set ng backend = systemd para basahin nito ang systemd journal sa halip na ang nawawalang /var/log/auth.log, at nagse-set ng banaction = nftables para ipatupad ang mga ban sa pamamagitan ng aktuwal na firewall ng Ubuntu. Pinoprotektahan ng simpleng apt install fail2ban ang SSH mula sa unang boot. Kumpirmahin ito gamit ang sudo fail2ban-client status sshd at hanapin ang non-zero na Total failed.

Bakit walang bina-ban ang Fail2ban sa server ko?

Isa-isahin ang tatlong karaniwang sanhi. Maaaring nagte-test ka mula sa address na nasa ignoreip, na sadyang hindi kasama sa ban. Maaaring na-override mo ang gumaganang default sa pamamagitan ng pag-paste ng backend = auto sa jail.local mula sa lumang guide, kaya hindi mabasa ang journal sa image na walang auth.log. O maaaring nasa loob ka ng container na walang systemd journal na mababasa. Suriin ang Total failed sa fail2ban-client status sshd: kung hindi ito tumataas habang nagpapakita ang journalctl -u ssh ng mga totoong failure, maling source ang binabasa ng jail.

Paano ko aalisin ang ban sa sarili kong IP address?

Patakbuhin ang sudo fail2ban-client set sshd unbanip YOUR.IP.HERE, na nagbabalik ng 1 kapag matagumpay, o ang sudo fail2ban-client unban --all para i-clear ang lahat ng ban. Kung naka-lock out ka sa SSH, gamitin ang web o VNC console ng iyong provider para patakbuhin ang parehong command. Tinatanggihan ng ban ang bawat packet mula sa iyong address papunta sa port 22, kaya hihinto rin ang isang session na dati nang bukas. Pagkatapos, idagdag ang iyong address sa ignoreip para hindi na ito ma-ban muli.

Ano ang pagkakaiba ng jail.conf at jail.local?

Naglalaman ang jail.conf ng upstream defaults ng Fail2ban at ino-overwrite sa bawat package upgrade, kaya tuluyang mawawala ang anumang edit doon. Inilalagay ng Debian/Ubuntu package ang sarili nitong settings sa ibabaw nito sa pamamagitan ng jail.d/defaults-debian.conf. Dapat ilagay ang iyong mga pagbabago sa jail.local, na huling binabasa at nangingibabaw sa dalawang iyon, at hindi binabago ng mga upgrade. Ituring ang jail.conf bilang read-only reference.

Pinapalitan ba ng Fail2ban ang key-based SSH authentication?

Hindi. Nililimitahan ng Fail2ban ang rate ng paulit-ulit na failure mula sa isang address. Wala itong nagagawa laban sa mabagal at distributed na paghula kung nananatili ang bawat address sa ibaba ng threshold. Ginagawang imposibleng mag-guess ng password ang key-only authentication (PasswordAuthentication no), at pagkatapos ay binabawasan ng Fail2ban ang log noise at maagang inaalis ang mga scanner. Gamitin ang dalawa, at kung maaari ay huwag ilantad sa public internet ang SSH.