Paano i-install ang Fail2ban sa Ubuntu 24.04

Ang ginagawa ng Fail2ban

Ang Fail2ban ay isang log-reading daemon. Binabantayan nito ang mga SSH authentication messages. Kapag may ilang failures mula sa isang address sa loob ng maikling window, magpapatakbo ito ng firewall command para i-block ang address na iyon pansamantala. Iyon ang pangunahing function nito. Binubuo ito ng humigit-kumulang tatlumpung linya ng config sa isang file. Sa Ubuntu 24.04, ang installation ay isang apt command lang na nagbibigay agad ng proteksyon bago ka pa mag-edit ng kahit ano.

Alamin ang limitasyon nito. Hindi nag-a-authenticate ang Fail2ban, hindi nag-e-encrypt ng kahit ano, at hindi nito mapipigilan ang isang determinado na login attempt — ang mga paulit-ulit na attempt lamang mula sa iisang source ang kaya nitong harangin. Isa itong noise filter at rate limiter, hindi ito lock. Ang layunin nito ay itigil ang pag-aksaya ng CPU, bandwidth, at log space sa constant background scanning ng port 22, at para pabagalin ang anumang attacker na kailangang gumamit ng iisang address sa bawat pagkakataon.

Ang hindi pinapalitan ng Fail2ban

Ang Fail2ban ay ang ikatlong layer, hindi ang una. Kung tumatanggap pa rin ang iyong server ng SSH passwords, maaaring magpatuloy ang paghula ng isang botnet mula sa libu-libong address. Mangyayari ito dahil ang bawat address ay nananatili sa ibaba ng iyong ban threshold at hindi ito na-ti-trigger. Ang tunay na depensa laban dito ay ang key-only authentication. Dahil dito, imposible ang password guessing kahit gaano pa karaming attempts ang gawin ng sinuman. Ang paggamit ng Fail2ban kasama ang key-only auth ay may dalawang pakinabang: binabawasan nito ang brute-force noise sa iyong logs, at tinatanggal nito ang mga scanner nang maaga para hindi na sila patuloy na mag-hammer sa port. Ituring ito bilang defence in depth. Nakapwesto ito sa likod ng key authentication at sa likod ng firewall, hindi sa harap ng mga ito.

Mga Prerequisites, at ang realidad ng Ubuntu 24.04

Kailangan mo ng VPS na tumatakbo ang Ubuntu 24.04 na may root o sudo access, at gumagana na ang SSH — mas mainam kung gamit ang key authentication. Matipid ang Fail2ban: kailangan lang ng ilang tens of megabytes ng RAM, at hindi na kailangan ng tuning sa mga limits.

Narito ang bahaging madalas magkamali sa mga lumang guide. Sa loob ng maraming taon, ang standard na payo ay "i-install ang Fail2ban, pagkatapos ay i-add ang backend = systemd, dahil itinigil na ng Ubuntu ang pagsusulat ng /var/log/auth.log." Ang payong ito ay tumutukoy sa isang totoong pagbabago — ang mga modernong server at cloud images ay wala nang rsyslog, kaya ang SSH logs ay sa systemd journal na lamang isinusulat at wala na ang text file na iyon — ngunit sa Ubuntu 24.04, ang Fail2ban package ay naka-configure na para dito. Ang package ay naglalagay ng /etc/fail2ban/jail.d/defaults-debian.conf, at ang file na iyon, hindi ang upstream defaults, ang aktwal 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 gumalaw. Ang backend = systemd ay nangangahulugang binabasa ng SSH jail ang journal, kaya hindi na mahalaga ang nawalang auth.log. Ang banaction = nftables ay nangangahulugang ang mga ban ay ipinapatupad sa pamamagitan ng nftables, na siyang firewall na aktwal na ginagamit ng Ubuntu 24.04 sa halip na ang legacy iptables. At ang [sshd] enabled = true ay nangangahulugang naka-on na ang jail mula sa unang boot. Ang resulta: ang stock na apt install fail2ban sa Ubuntu 24.04 ay awtomatikong nagba-ban ng SSH brute-force. Ang karamihan sa iyong gagawin ay ang pag-confirm nito, ang pag-tune ng policy, at ang pagtiyak na hindi mo ma-lock out ang iyong sarili.

Ang lumang auth.log trap ay nararanasan pa rin sa tatlong sitwasyon, at mahalagang malaman ang mga ito: nag-install ka ng Fail2ban gamit ang pip sa halip na apt, kaya walang defaults-debian.conf; nasa loob ka ng isang unprivileged container na walang systemd journal na mababasa; o sumunod ka sa isang lumang tutorial at i-paste ang backend = auto sa iyong sariling jail.local, na nag-o-override sa gumaganang default. Ipinapakita ng failure-modes section ang eksaktong hitsura ng bawat isa.

Step 1: I-install at i-confirm kung gumagana na ang pag-ban

sudo apt update
sudo apt install -y fail2ban

Ang Ubuntu 24.04 ay may kasamang Fail2ban 1.0.2. Kasama sa package na ito ang python3-systemd bilang hard dependency, kaya kumpleto na ang kailangan ng journal backend. Awtomatikong nag-e-enable at nag-i-start ang service:

sudo systemctl status fail2ban

Kailangan mo ang active (running). Pagkatapos, tingnan ang jail na kasalukuyang gumagana:

sudo fail2ban-client status sshd

Sa isang public VPS na online na kahit ilang minuto lang, madalas ay makikita mo na ang mga nabibilang na failure at mga na-ban na address — tuloy-tuloy ang pag-scan ng internet sa port 22. Patunay ito na gumagana ang stock config. Ang gagawin mo ay i-refine ito, hindi magbuo mula sa wala.

Step 2: I-edit ang jail.local, huwag ang jail.conf

Naka-store ang mga default settings ng Fail2ban sa /etc/fail2ban/jail.conf. Huwag i-edit ang file na iyon. Maaaring palitan ng bawat apt upgrade ng package ang file na iyon, at mawawala ang iyong mga pagbabago nang walang babala. Binabasa ng Fail2ban ang mga file sa isang fixed order — jail.conf muna, pagkatapos ang lahat ng nasa jail.d/, at pagkatapos ang jail.local — at ang huling value ang mananalo. Ang .local file ay para sa iyo, at hindi ito binabago ng mga package upgrade. Ang parehong rule ay applies sa mga filter, kung saan ang isang *.local file ay nag-o-override sa shipped na filter.d/*.conf.

Kaya gumawa ng maliit na jail.local na nag-o-override lamang sa mga settings na kailangan mo, at iwanan ang jail.conf at ang packaged na jail.d/defaults-debian.conf nang walang pagbabago bilang reference.

Step 3: I-write ang /etc/fail2ban/jail.local

sudo nano /etc/fail2ban/jail.local

I-paste ito, at palitan ang address sa ignoreip line gamit ang iyong sariling 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

Ang bawat linya ay may partikular na gamit:

• Ang bantime, findtime, at maxretry ay ang policy. Ang default na bantime ay sampung minuto lamang; mas mainam na gawin itong isang oras. Ang limang failures mula sa isang address sa loob ng sampung minuto ay magreresulta sa ban. Ang totoong tao ay nagkakamali sa password nang isa o dalawang beses lang; ang limang failures sa sampung minuto ay senyales ng isang script.
• Ang ignoreip ay ang iyong safety belt. Ilagay dito ang public address na ginagamit mo para mag-connect para hindi ka ma-lockout ng Fail2ban sa sarili mong server. Kung ang home connection mo ay may nagbabagong IP, mas mabuting gamitin ang VPN approach sa dulo, hindi dahil kailangang laktawan ang linyang ito.
• Ang bantime.increment = true ay ginagawang mas mahaba ang bawat ban kumpara sa nauna — isang oras, pagkatapos ay dalawa, pagkatapos ay apat — hanggang bantime.maxtime. Ang mga address na paulit-ulit na bumabalik ay unti-unting mas matagal na na-lo-lock out.

Hanapin ang address na dapat i-whitelist mula sa machine na ginagamit mo para mag-SSH, hindi mula sa server:

curl -s ifconfig.me

Maaari kang mag-generate ng jail.local na naka-tune sa iyong mga port at ban policy dito, pagkatapos ay i-paste ito sa file:

Step 4: I-restart at i-verify kung binabasa nito ang journal

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

Nagsasagawa muna ng config test ang -t, kaya ang typo sa jail.local ay magdudulot ng error dito sa halip na hayaang hindi gumana ang service. Ganito ang hitsura ng healthy 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

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

Pansinin na ang Journal matches line ay nakapangalan pa rin sa sshd.service. Sa Ubuntu, ang SSH unit ay ssh.service, pero ang kasamang filter ay tumutugma rin sa _COMM=sshd, at ang OpenSSH sa 24.04 ay nire-record ang mga failure mula sa isang process na may pangalang sshd, kaya gumagana ang match. Mahalaga lang ang detalye na iyon kung nasa mas bagong OpenSSH ka (9.8 o mas bago, kung saan ang per-connection worker ay sshd-session); covered ng mga failure modes ang kasong iyon.

Step 5: Watch a real ban land, or force one to test

Real bans arrive on their own within minutes on any public VPS. To watch one, tail the log:

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

A ban looks like this:

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

To prove the machinery end to end without waiting, ban a documentation address by hand — never your own:

sudo fail2ban-client set sshd banip 10.0.0.66

It prints 1, and the address appears under Banned IP list in fail2ban-client status sshd. Now confirm the block really exists in the firewall. On Ubuntu 24.04 that is nftables, not iptables:

sudo nft list table inet f2b-table

You will see a set named addr-set-sshd holding 10.0.0.66, and a chain f2b-chain that rejects any source in that set. If fail2ban-client says an address is banned but nothing appears in nft list, your ban action does not match your firewall — see the nftables/iptables note in the failure modes.

Step 6: I-unban ang sarili, at mag-recover kung na-lock out

Kung na-ban mo ang isang address na hindi dapat—gaya ng sarili mong address—tanggalin ito:

sudo fail2ban-client set sshd unbanip 10.0.0.66

Magbabalik ito ng 1 kapag successful. Para i-clear ang lahat ng ban sa lahat ng jail:

sudo fail2ban-client unban --all

Huwag umasa sa kasalukuyang SSH session para makaligtas: ang nftables ban ay tinatanggihan ang lahat ng packet mula sa banned address papunta sa port 22 — kasama na ang mga established connection — kaya ang existing session ay mag-freeze sa sandaling ma-apply ang ban. Kung na-ban mo ang sarili mo at walang ignoreip entry, ma-lock out ka hanggang sa mag-expire ang ban — mag-recover gamit ang web console ng iyong provider (VNC o serial), na hindi gumagamit ng SSH, at maghintay hanggang sa bantime o i-run ang unban command doon.

Step 7: Gawing permanent at escalating ang mga ban

Itinatago ng Fail2ban ang mga active ban sa isang maliit na SQLite database sa /var/lib/fail2ban/fail2ban.sqlite3, kaya mananatili ang mga ito kahit mag-restart ang service o mag-reboot ang system; hindi mawawala ang mga ito. Dahil sa mga linya ng bantime.increment na idinagdag mo na, ang bawat paulit-ulit na offender ay magiging escalating problem para sa kanila — halos nadodoble ang tagal mula isang oras patungong isang linggo.

Para sa isang system-wide na "three strikes" policy, may kasamang recidive jail ang Fail2ban na binabantayan ang sarili nitong /var/log/fail2ban.log. Nagbibigay ito ng mahabang ban sa anumang address na paulit-ulit na na-ban sa lahat ng jail. Dahil ang [DEFAULT] mo ay gumagamit na ng systemd backend, i-pin ang jail na ito pabalik sa log file na dapat nitong basahin:

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

Ang backend = auto na may explicit na logpath ay pananatili sa recidive na magbasa sa plain fail2ban.log. Dito talaga lumalabas ang mga Ban lines na binibilang nito — ang systemd default na i-set mo globally ay ituturo ito sa journal, kung saan wala ang mga ito.

Step 8: I-pair ito sa key-only SSH, o mas mabuti, sa isang VPN

Nagiging epektibo lang ang Fail2ban kung kasama ang key authentication. Sa isang drop-in file sa ilalim ng /etc/ssh/sshd_config.d/ — halimbawa ay /etc/ssh/sshd_config.d/00-hardening.conf — i-set ang:

PasswordAuthentication no
KbdInteractiveAuthentication no

Pagkatapos ay sudo systemctl restart ssh. Kapag naka-off na ang passwords, hindi na magtatagumpay ang brute force; ang papel na lang ng Fail2ban ay bawasan ang log noise at i-evict ang mga scanner nang maaga. Mas matibay kung pananatilihing off ang SSH sa public internet: ilagay ang SSH sa likod ng isang self-hosted WireGuard VPN at i-firewall ang port 22 para sumagot lamang ito sa loob ng tunnel. Hindi makakapag-brute-force ang sinuman sa port na hindi nila ma-access, at ang Fail2ban ay magsisilbing backstop sa halip na front line.

Hindi lang para sa SSH ang Fail2ban. Anumang service na naglo-log ng failed logins ay maaaring lagyan ng jail — isang mail server, isang nginx site, o isang self-hosted Vaultwarden password manager na ayaw mong iwanang bukas sa credential stuffing. Kapag ang isang web app ay nasa likod na ng isang nginx site na may Let's Encrypt certificate, i-point ang isang Fail2ban filter sa access log nito gaya ng pag-point ng SSH jail sa journal.

Failure modes, kasama ang mga eksaktong string na makikita mo

"Have not found any log file for sshd jail", at hindi magsisimula ang Fail2ban. Ito ang lumang auth.log problem, at sa Ubuntu 24.04 ay mangyayari lang ito kung may na-override sa default ng package — isang pip install na walang defaults-debian.conf, isang container na walang journal, o isang stray backend = auto na na-paste sa jail.local. Sa isang file backend na walang /var/log/auth.log, hindi mahanap ng sshd jail ang log nito kaya mag-aabort ang buong daemon. Ipinapakita ng fail2ban.log ang:

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

Dahil fatal ang error na iyon, hindi magsisimula ang service, at ire-report ng fail2ban-client status ang downstream symptom:

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

Ang "socket path" line na iyon ay hindi nangangahulugang sira ang Fail2ban — ibig sabihin lang nito ay hindi ito nagsimula 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 mag-aayos sa dalawang mensahe nang sabay.

Active ang jail pero hindi gumagalaw ang Total failed. Tumatakbo ang daemon at binabasa ang journal, pero ang mga totoong failure ay naiipon sa journalctl -u ssh habang ang counter ay nasa 0. Unang i-rule out ang mga halata: nagte-test ka mula sa isang address na nasa listahan ng ignoreip, kaya ang sarili mong mga failure ay exempt by design. Kung hindi ito ang dahilan, nasa OpenSSH build ka kung saan ang per-connection worker ay sshd-session (9.8 at pataas), na ang journal _COMM ay sshd-session, hindi sshd, kaya hindi ito mahuli ng default match. Palawakin ang match sa [sshd] block:

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

I-restart, sadyang mag-fail ng login mula sa address na wala sa ignoreip, at kumpirmahin kung ang Total failed ay tumaas na sa wakas.

Na-ban mo ang sarili mo: Connection refused. Iniwan mong wala ang sarili mong address sa ignoreip, nag-test ng ilang maling login, at ngayon:

ssh: connect to host 10.0.0.10 port 22: Connection refused

Ang pagtanggi (refusal), sa halip na isang silent timeout, ay ang default reject verdict ng nftables action na gumagana — sa iyo. Ayusin ito gaya ng nasa Step 6: mag-unban mula sa isang session sa ibang address na hindi banned, o mula sa provider console — ang session na kasalukuyang bukas mula sa banned address ay mag-freeze din. Pagkatapos ay idagdag ang iyong address sa ignoreip para hindi na ito muling mangyari.

Sinasabi ng Fail2ban na banned ang isang address, pero nakaka-connect pa rin ito. Tumaas ang counter sa status sshd, pero ang address ay nakakaabot pa rin sa port 22. Ito ay ban-action-versus-firewall mismatch, at sa Ubuntu 24.04 ay halos laging nangangahulugan ito na na-override mo ang gumaganang banaction = nftables gamit ang banaction = iptables-multiport na kinuha sa lumang guide, sa isang system na walang iptables layer. Ipinapakita ng fail2ban.log ang:

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

Burahin ang override na iyon at hayaan ang packaged nftables action, o, kung pinamamahalaan mo ang firewall nang buo gamit ang ufw at gusto mong lumabas ang mga ban doon, i-set ang banaction = ufw sa [DEFAULT]. I-restart at kumpirmahin kung lumabas ang rule gamit ang sudo nft list ruleset | grep f2b.

Hindi magsisimula ang Fail2ban pagkatapos i-edit ang jail.local. Isang typo — isang maling heading o maling time value — ang dahilan kung bakit hindi magsisimula ang service. Utusan ang Fail2ban na i-check ang config bago ito tumakbo:

sudo fail2ban-client -t

Pangalanan nito ang file at ang jail na may problema, halimbawa Errors in jail 'sshd'. Skipping..., para maayos mo ang source sa halip na manghula.

FAQ

Nagba-ban ba talaga ng SSH attacks ang stock Fail2ban install sa Ubuntu 24.04?

Oo. Kasama sa package ang /etc/fail2ban/jail.d/defaults-debian.conf, na nag-e-enable ng sshd jail, nagse-set ng backend = systemd para basahin ang systemd journal sa halip na ang kulang na /var/log/auth.log, at nagse-set ng banaction = nftables para ipatupad ang mga ban gamit ang firewall ng Ubuntu. Protektado na ang SSH mula sa unang boot dahil sa apt install fail2ban. I-verify ito gamit ang sudo fail2ban-client status sshd at tingnan kung ang Total failed ay hindi zero.

Bakit walang bina-ban na kahit ano ang Fail2ban sa machine ko?

Suriin ang tatlong karaniwang sanhi nang sunod-sunod. Maaaring nagte-test ka mula sa address sa ignoreip, na sadyang exempt. Maaari mo ring na-override ang default settings sa pamamagitan ng pag-paste ng backend = auto sa jail.local mula sa lumang guide; sinisira nito ang pagbabasa ng journal sa mga image na walang auth.log. O kaya naman ay nasa loob ka ng container na walang systemd journal na mababasa. I-check ang Total failed sa fail2ban-client status sshd: kung hindi ito tumataas habang ang journalctl -u ssh ay nagpapakita ng mga totoong failure, mali ang binabasa ng jail na location.

Paano ko i-uunban ang sarili kong IP address?

I-run ang sudo fail2ban-client set sshd unbanip YOUR.IP.HERE, na magbabalik ng 1 kapag successful, o sudo fail2ban-client unban --all para i-clear ang lahat ng ban. Kung na-lockout ka sa SSH, gamitin ang web o VNC console ng iyong provider para i-run ang parehong command — nire-reject ng ban ang lahat ng packet mula sa iyong address papunta sa port 22, kaya kahit ang session na dati nang bukas ay hihinto sa paggana. Pagkatapos, i-add ang iyong address sa ignoreip para hindi na ito maulit.

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

Naglalaman ang jail.conf ng mga upstream default ng Fail2ban at na-o-overwrite ito sa bawat package upgrade, kaya mawawala ang anumang edit doon. Ang Debian/Ubuntu package ay naglalagay ng sarili nitong settings sa pamamagitan ng jail.d/defaults-debian.conf. Ang iyong mga pagbabago ay dapat ilagay sa jail.local, na huling binabasa at mas matimbang kaysa sa dalawa, at hindi binabago ng mga upgrade. Gamitin lamang ang jail.conf bilang read-only reference.

Pinapalitan ba ng Fail2ban ang key-based SSH authentication?

Hindi. Nililimitahan ng Fail2ban ang bilis ng paulit-ulit na failure mula sa isang address; wala itong magagawa laban sa mabagal at distributed na guessing kung saan ang bawat address ay nananatili sa ilalim ng threshold. Ang key-only authentication (PasswordAuthentication no) ay ginagawang imposible ang password guessing, at ang Fail2ban naman ay naglilinis ng log noise at nagtatanggal ng mga scanner nang maaga. Gamitin ang pareho, at mas mainam kung pananatilihing off ang SSH sa public internet.