Cách cài Fail2ban trên Ubuntu 24.04 chặn SSH bot

Fail2ban thực sự làm gì

Fail2ban là một daemon đọc log. Nó theo dõi các thông báo xác thực SSH của bạn và, sau một vài lần thất bại từ một địa chỉ trong một khoảng thời gian ngắn, nó sẽ chạy một lệnh firewall để chặn địa chỉ đó trong một lúc. Đó là ý tưởng cốt lõi. Nó chỉ gồm khoảng ba mươi dòng config trong một file, và trên Ubuntu 24.04, việc cài đặt chỉ là một lệnh apt duy nhất giúp bạn được bảo vệ trước khi bạn kịp chỉnh sửa bất cứ thứ gì.

Hãy phân biệt rõ nó là gì và không phải là gì. Fail2ban không xác thực bất kỳ ai, không mã hóa bất cứ thứ gì, và không ngăn chặn được một nỗ lực đăng nhập quyết liệt duy nhất — nó chỉ chặn những nỗ lực lặp đi lặp lại từ cùng một nguồn. Nó là một bộ lọc nhiễu và bộ giới hạn tốc độ (rate limiter), không phải là một ổ khóa. Nhiệm vụ của nó là khiến việc quét cổng 22 liên tục ở background ngừng lãng phí CPU, băng thông và không gian lưu trữ log của bạn, đồng thời làm chậm bất kỳ kẻ tấn công nào vốn phải thực hiện từ một địa chỉ tại một thời điểm.

Những gì Fail2ban không thay thế

Fail2ban là lớp thứ ba, không phải lớp thứ nhất. Nếu server của bạn vẫn chấp nhận SSH password, một botnet trải dài trên hàng ngàn địa chỉ có thể tiếp tục dò mật khẩu, vì mỗi địa chỉ đều nằm dưới ngưỡng ban của bạn và không bao giờ kích hoạt nó. Cách phòng thủ thực sự chống lại điều đó là xác thực chỉ bằng key, giúp việc dò mật khẩu trở nên bất khả thi bất kể có bao nhiêu nỗ lực được thực hiện. Fail2ban chạy trên nền xác thực key thực hiện hai việc hữu ích: nó lọc bỏ nhiễu brute-force khỏi log của bạn, và nó trục xuất các scanner sớm để chúng ngừng tấn công cổng. Hãy coi nó là phòng thủ theo chiều sâu (defence in depth). Nó nằm sau xác thực key và sau một firewall, không bao giờ nằm trước chúng.

Điều kiện tiên quyết, và thực tế trên Ubuntu 24.04

Bạn cần một VPS chạy Ubuntu 24.04 với quyền root hoặc sudo, và SSH đã hoạt động — lý tưởng nhất là dùng xác thực bằng key. Fail2ban rất tiết kiệm: chỉ tốn vài chục megabytes RAM, không cần tinh chỉnh các giới hạn.

Bây giờ là phần mà mọi hướng dẫn cũ đều làm sai. Trong nhiều năm, lời khuyên tiêu chuẩn là "cài đặt Fail2ban, sau đó thêm backend = systemd, vì Ubuntu đã ngừng ghi /var/log/auth.log." Lời khuyên đó mô tả một thay đổi thực tế — các image server và cloud hiện đại được phát hành mà không có rsyslog, vì vậy SSH chỉ ghi log vào systemd journal và file text đó không còn nữa — nhưng trên Ubuntu 24.04, package Fail2ban đã tính đến điều này. Package sẽ cài đặt /etc/fail2ban/jail.d/defaults-debian.conf, và chính file đó, chứ không phải các default từ upstream, là thứ mà server của bạn thực sự chạy:

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

[sshd]
enabled = true

Hãy đọc kỹ phần đó, vì nó giải quyết hai câu hỏi trước khi bạn chạm vào bất cứ thứ gì. backend = systemd có nghĩa là SSH jail sẽ đọc journal, vì vậy việc thiếu auth.log không quan trọng. banaction = nftables có nghĩa là các lệnh ban được thực thi thông qua nftables, vốn là firewall mà Ubuntu 24.04 thực sự sử dụng, thay vì iptables cũ. Và [sshd] enabled = true có nghĩa là jail đã được bật ngay từ lần boot đầu tiên. Kết quả là: một bản apt install fail2ban chuẩn trên Ubuntu 24.04 sẽ chặn SSH brute-force ngay lập tức. Phần lớn công việc của bạn là xác nhận điều đó, tinh chỉnh policy, và đảm bảo bạn không tự khóa chính mình.

Bẫy auth.log cũ vẫn còn gây rắc rối trong ba tình huống, và bạn nên nhận biết chúng: bạn cài đặt Fail2ban với pip thay vì apt, nên không có defaults-debian.conf; bạn đang ở trong một container không có đặc quyền và không có systemd journal để đọc; hoặc bạn đã làm theo một hướng dẫn cũ và dán backend = auto vào file jail.local của riêng mình, ghi đè lên default đang hoạt động. Phần các lỗi thường gặp (failure-modes) sẽ cho thấy chính xác từng trường hợp trông như thế nào.

Bước 1: Cài đặt và xác nhận nó đã đang chặn

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04 đi kèm với Fail2ban 1.0.2, và package này kéo theo python3-systemd như một dependency bắt buộc, vì vậy backend journal đã có mọi thứ nó cần. Service sẽ tự enable và start:

sudo systemctl status fail2ban

Bạn muốn active (running). Sau đó hãy xem jail đang thực hiện nhiệm vụ của nó:

sudo fail2ban-client status sshd

Trên một VPS công khai đã có thể kết nối được dù chỉ vài phút, bạn sẽ thường thấy các lỗi đã được đếm và các địa chỉ đã bị ban — internet quét cổng 22 liên tục. Đó là minh chứng cho thấy config chuẩn đang hoạt động. Từ đây bạn sẽ tinh chỉnh nó, chứ không phải xây dựng từ con số không.

Bước 2: Chỉnh sửa jail.local, không bao giờ chỉnh sửa jail.conf

Fail2ban giữ các default từ upstream trong /etc/fail2ban/jail.conf. Đừng chỉnh sửa file đó. Mọi apt upgrade của package đều có thể ghi đè lên nó, và các thay đổi của bạn sẽ biến mất mà không có cảnh báo. Fail2ban đọc các file theo thứ tự cố định — jail.conf trước, sau đó mọi thứ trong jail.d/, rồi đến jail.local — và giá trị cuối cùng sẽ được áp dụng. File .local là của bạn, và các bản nâng cấp package không bao giờ chạm vào nó. Quy tắc tương tự cũng áp dụng cho các filter, nơi một file *.local sẽ ghi đè lên file filter.d/*.conf đi kèm.

Vì vậy, bạn viết một file jail.local nhỏ để chỉ ghi đè một vài settings mà bạn quan tâm, và để cả jail.conf và jail.d/defaults-debian.conf của package nguyên vẹn để làm tham chiếu.

Bước 3: Viết /etc/fail2ban/jail.local

sudo nano /etc/fail2ban/jail.local

Hãy đưa nội dung này vào, thay đổi địa chỉ ở dòng ignoreip thành IP public của chính bạn:

[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

Mỗi dòng đều có vai trò riêng:

• bantime, findtime, maxretry là policy. Default đi kèm bantime chỉ là mười phút; một giờ là một mức sàn hợp lý hơn. Năm lần thất bại từ một địa chỉ trong mười phút sẽ bị ban. Người thật chỉ gõ sai mật khẩu một hoặc hai lần; năm lần thất bại trong mười phút là một script.
• ignoreip là dây an toàn của bạn. Hãy đặt địa chỉ public mà bạn dùng để kết nối từ đó vào đây để Fail2ban không bao giờ khóa bạn khỏi server của chính mình. Một kết nối gia đình với IP thay đổi liên tục là lý do để ưu tiên cách dùng VPN ở phần cuối, chứ không phải là lý do để bỏ qua dòng này.
• bantime.increment = true làm cho mỗi lần ban lặp lại sẽ dài hơn lần trước — một giờ, rồi hai giờ, rồi bốn giờ — lên đến bantime.maxtime. Các địa chỉ cứ quay lại liên tục sẽ bị khóa dần dần.

Tìm địa chỉ để whitelist từ máy mà bạn dùng để SSH vào server, chứ không phải từ chính server:

curl -s ifconfig.me

Bạn có thể tạo một jail.local được tinh chỉnh theo các port và policy ban của bạn tại đây, sau đó dán nó vào file:

Bước 4: Khởi động lại và xác nhận nó đang đọc journal

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

-t sẽ chạy một bài kiểm tra config trước, vì vậy một lỗi typo trong jail.local sẽ báo lỗi ngay tại đây thay vì để service bị chết. Trạng thái jail hoạt động bình thường sẽ trông như thế này:

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

Con số chứng minh Fail2ban thực sự đang đọc các lượt đăng nhập của bạn là Total failed. Nếu nó lớn hơn zero, hoặc tăng lên khi bạn cố tình đăng nhập sai từ một máy khác, nghĩa là journal đang được đọc và bạn đã xong. Nếu nó giữ ở mức 0 bất kể bạn thất bại bao nhiêu lần — và bạn chắc chắn mình không đang test từ địa chỉ trong ignoreip — hãy xem các lỗi ở phần dưới.

Lưu ý dòng Journal matches vẫn gọi tên sshd.service. Trên Ubuntu, unit SSH thực tế là ssh.service, nhưng filter đi kèm cũng khớp với _COMM=sshd, và OpenSSH trên 24.04 ghi log các lỗi từ một process tên là sshd, nên việc khớp (match) vẫn hoạt động. Chi tiết đó chỉ quan trọng nếu bạn đang dùng OpenSSH mới hơn (9.8 hoặc mới hơn, nơi worker cho mỗi kết nối là sshd-session); phần các lỗi sẽ bao quát trường hợp đó.

Bước 5: Xem một lệnh ban thực tế, hoặc ép buộc một lệnh ban để test

Các lệnh ban thực tế sẽ tự xuất hiện trong vòng vài phút trên bất kỳ VPS công khai nào. Để theo dõi, hãy tail log:

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

Một lệnh ban trông như thế này:

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

Để chứng minh toàn bộ quy trình mà không cần chờ đợi, hãy ban một địa chỉ tài liệu bằng tay — đừng bao giờ ban chính mình:

sudo fail2ban-client set sshd banip 10.0.0.66

Nó in ra 1, và địa chỉ đó xuất hiện dưới mục Banned IP list trong fail2ban-client status sshd. Bây giờ hãy xác nhận lệnh chặn thực sự tồn tại trong firewall. Trên Ubuntu 24.04, đó là nftables, không phải iptables:

sudo nft list table inet f2b-table

Bạn sẽ thấy một set tên là addr-set-sshd chứa 10.0.0.66, và một chain f2b-chain từ chối bất kỳ source nào trong set đó. Nếu fail2ban-client nói một địa chỉ đã bị ban nhưng không có gì xuất hiện trong nft list, nghĩa là hành động ban của bạn không khớp với firewall — hãy xem lưu ý nftables/iptables trong phần các lỗi.

Bước 6: Unban chính mình, và khôi phục nếu bạn bị khóa

Nếu bạn lỡ ban một địa chỉ mà bạn không nên — chính bạn — hãy gỡ nó ra:

sudo fail2ban-client set sshd unbanip 10.0.0.66

Nó trả về 1 nếu thành công. Để xóa mọi lệnh ban trong mọi jail:

sudo fail2ban-client unban --all

Đừng trông chờ vào một session SSH đang mở để cứu bạn: lệnh ban của nftables sẽ từ chối mọi packet từ địa chỉ bị ban đến cổng 22 — bao gồm cả các kết nối đã thiết lập (established) — vì vậy một session hiện có sẽ bị đóng băng ngay khi lệnh ban có hiệu lực. Nếu bạn tự ban chính mình và không có entry ignoreip, bạn sẽ bị khóa cho đến khi lệnh ban hết hạn — hãy khôi phục thông qua console web của nhà cung cấp (VNC hoặc serial), vốn không đi qua SSH, và đợi cho đến khi hết bantime hoặc chạy lệnh unban ở đó.

Bước 7: Làm cho các lệnh ban được duy trì và leo thang

Fail2ban lưu trữ các lệnh ban đang hoạt động trong một database SQLite nhỏ tại /var/lib/fail2ban/fail2ban.sqlite3, vì vậy chúng sẽ tồn tại sau khi restart service hoặc reboot; bạn không bị mất chúng. Các dòng bantime.increment mà bạn đã thêm sẽ biến mỗi kẻ vi phạm lặp lại thành một vấn đề leo thang đối với chính chúng — tăng dần khoảng gấp đôi từ một giờ lên đến một tuần.

Để có chính sách "ba lần vi phạm" trên toàn hệ thống, Fail2ban cung cấp một jail recidive theo dõi /var/log/fail2ban.log của chính nó và đưa ra các lệnh ban dài cho bất kỳ địa chỉ nào đã bị ban lặp lại qua tất cả các jail. Vì [DEFAULT] của bạn hiện đang dùng backend systemd, hãy ghim jail này quay lại file log mà nó được thiết kế để đọc:

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

backend = auto với logpath cụ thể sẽ giữ cho recidive đọc file fail2ban.log thuần túy, nơi mà các dòng Ban mà nó đếm thực sự xuất hiện — default của systemd mà bạn thiết lập toàn cục sẽ trỏ nó vào journal, nơi mà chúng không tồn tại.

Bước 8: Kết hợp với SSH chỉ dùng key, và tốt hơn nữa là một VPN

Fail2ban chỉ thực sự hữu ích khi đi cùng với xác thực bằng key. Trong một file drop-in dưới /etc/ssh/sshd_config.d/ — ví dụ /etc/ssh/sshd_config.d/00-hardening.conf — hãy thiết lập:

PasswordAuthentication no
KbdInteractiveAuthentication no

Sau đó là sudo systemctl restart ssh. Khi đã tắt password, brute force không thể thành công; khi đó Fail2ban tồn tại để giảm nhiễu log và trục xuất các scanner sớm. Mạnh mẽ hơn nữa là giữ SSH hoàn toàn không xuất hiện trên internet công cộng: đưa SSH ra sau một WireGuard VPN tự host và firewall cổng 22 để nó chỉ phản hồi trong tunnel. Không ai có thể brute-force một cổng mà họ không thể kết nối tới, và Fail2ban trở thành lớp bảo vệ dự phòng thay vì là tuyến đầu.

Fail2ban không chỉ dành cho SSH. Bất kỳ dịch vụ nào có ghi log các lượt đăng nhập thất bại đều có thể có một jail — một mail server, một trang nginx, hoặc một trình quản lý mật khẩu Vaultwarden tự host mà bạn không muốn để lộ web login cho credential stuffing. Một khi web app nằm sau một trang nginx với chứng chỉ Let's Encrypt, hãy trỏ một Fail2ban filter vào access log của nó tương tự như cách SSH jail trỏ vào journal.

Các lỗi thường gặp, với các chuỗi ký tự chính xác bạn sẽ thấy

"Have not found any log file for sshd jail", và Fail2ban sẽ không khởi động. Đây là vấn đề auth.log cũ, và trên Ubuntu 24.04 bạn chỉ gặp phải nếu có thứ gì đó đã ghi đè lên default của package — một bản cài đặt pip không có defaults-debian.conf, một container không có journal, hoặc một backend = auto lạc lõng mà bạn dán vào jail.local. Với một file backend không có /var/log/auth.log, sshd jail không thể tìm thấy log và toàn bộ daemon sẽ dừng lại. fail2ban.log hiển thị:

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

Vì lỗi đó là lỗi nghiêm trọng, service không bao giờ khởi động, và fail2ban-client status sau đó báo cáo triệu chứng hệ quả:

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

Dòng "socket path" đó không có nghĩa là Fail2ban bị hỏng — nó có nghĩa là nó chưa bao giờ khởi động vì một jail không thể tìm thấy log. Thiết lập backend = systemd trong [DEFAULT], điều mà package Ubuntu đã làm sẵn cho bạn, sẽ sửa cả hai thông báo cùng một lúc.

Jail đang hoạt động nhưng Total failed không bao giờ thay đổi. Daemon đang chạy và journal đang được đọc, nhưng các lỗi thực tế đang tích tụ trong journalctl -u ssh trong khi bộ đếm vẫn đứng yên ở 0. Đầu tiên hãy loại trừ nguyên nhân hiển nhiên: bạn đang test từ một địa chỉ nằm trong danh sách ignoreip, nên các lỗi của chính bạn được miễn trừ theo thiết kế. Nếu không phải vậy, bạn đang dùng bản OpenSSH mà worker cho mỗi kết nối là sshd-session (9.8 trở lên), có journal _COMM là sshd-session chứ không phải sshd, nên filter đi kèm sẽ bỏ lỡ nó. Hãy mở rộng phạm vi khớp trong block [sshd]:

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

Khởi động lại, cố tình đăng nhập sai từ một địa chỉ không nằm trong ignoreip, và xác nhận Total failed cuối cùng đã tăng lên.

Bạn đã tự ban chính mình: Connection refused. Bạn đã để sót địa chỉ của chính mình trong ignoreip, thử vài lần đăng nhập sai, và bây giờ:

ssh: connect to host 10.0.0.10 port 22: Connection refused

Sự từ chối, thay vì là timeout im lặng, là kết quả mặc định reject của hành động nftables đang thực hiện — lên chính bạn. Hãy sửa nó như ở Bước 6: unban từ một session trên một địa chỉ khác không bị ban, hoặc từ console của nhà cung cấp — một session đã mở từ địa chỉ bị ban cũng sẽ bị đóng băng. Sau đó hãy thêm địa chỉ của bạn vào ignoreip để điều này không lặp lại.

Fail2ban nói một địa chỉ đã bị ban, nhưng nó vẫn có thể kết nối. Bộ đếm trong status sshd tăng lên, nhưng địa chỉ đó vẫn kết nối được tới cổng 22. Đây là sự không khớp giữa ban-action và firewall, và trên Ubuntu 24.04 điều này hầu như luôn có nghĩa là bạn đã ghi đè banaction = nftables đang hoạt động bằng banaction = iptables-multiport copy từ một hướng dẫn cũ, trên một máy không có lớp iptables. fail2ban.log hiển thị:

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

Hãy xóa phần ghi đè đó và để action nftables đi kèm hoạt động, hoặc nếu bạn quản lý firewall hoàn toàn qua ufw và muốn các lệnh ban xuất hiện ở đó, hãy thiết lập banaction = ufw trong [DEFAULT]. Khởi động lại và xác nhận rule xuất hiện bằng sudo nft list ruleset | grep f2b.

Fail2ban không khởi động sau khi chỉnh sửa jail.local. Một lỗi typo — một heading thừa hoặc một giá trị thời gian sai — khiến service từ chối khởi động. Hãy yêu cầu Fail2ban kiểm tra config trước khi chạy:

sudo fail2ban-client -t

Nó sẽ chỉ ra file và jail gặp vấn đề, ví dụ là Errors in jail 'sshd'. Skipping..., để bạn sửa đúng nguồn thay vì đoán mò.

FAQ

Bản cài đặt Fail2ban chuẩn trên Ubuntu 24.04 có thực sự chặn các cuộc tấn công SSH không?

Có. Package đi kèm với /etc/fail2ban/jail.d/defaults-debian.conf, giúp enable jail sshd, thiết lập backend = systemd để nó đọc systemd journal thay vì /var/log/auth.log đã mất, và thiết lập banaction = nftables để các lệnh ban được thực thi thông qua firewall thực sự của Ubuntu. Một bản apt install fail2ban chuẩn sẽ bảo vệ SSH ngay từ lần boot đầu tiên. Hãy xác nhận bằng sudo fail2ban-client status sshd và tìm kiếm một giá trị Total failed khác không.

Tại sao Fail2ban không chặn bất cứ thứ gì trên máy của tôi?

Hãy loại trừ ba nguyên nhân phổ biến theo thứ tự. Có thể bạn đang test từ một địa chỉ trong ignoreip, vốn được miễn trừ theo thiết kế. Có thể bạn đã ghi đè default đang hoạt động bằng cách dán backend = auto vào jail.local từ một hướng dẫn cũ, điều này làm hỏng việc đọc journal trên một image không có auth.log. Hoặc bạn đang ở trong một container không có systemd journal để đọc. Kiểm tra Total failed trong fail2ban-client status sshd: nếu nó không bao giờ tăng trong khi journalctl -u ssh cho thấy các lỗi thực tế, nghĩa là jail đang đọc sai chỗ.

Làm thế nào để unban địa chỉ IP của chính tôi?

Chạy sudo fail2ban-client set sshd unbanip YOUR.IP.HERE, trả về 1 nếu thành công, hoặc sudo fail2ban-client unban --all để xóa mọi lệnh ban. Nếu bạn bị khóa SSH, hãy dùng console web hoặc VNC của nhà cung cấp để chạy cùng lệnh đó — lệnh ban sẽ từ chối mọi packet từ địa chỉ của bạn đến cổng 22, nên ngay cả một session đã mở cũng sẽ ngừng hoạt động. Sau đó hãy thêm địa chỉ của bạn vào ignoreip để tránh lặp lại.

Sự khác biệt giữa jail.conf và jail.local là gì?

jail.conf chứa các default từ upstream của Fail2ban và sẽ bị ghi đè sau mỗi bản nâng cấp package, vì vậy bất kỳ chỉnh sửa nào ở đó cuối cùng cũng sẽ mất. Package Debian/Ubuntu sẽ xếp các settings của riêng nó lên trên thông qua jail.d/defaults-debian.conf. Các thay đổi của bạn nên nằm trong jail.local, file này được đọc cuối cùng và có ưu tiên cao hơn cả hai, và các bản nâng cấp không bao giờ chạm vào nó. Hãy để jail.conf ở chế độ chỉ đọc để tham khảo.

Fail2ban có thay thế xác thực SSH bằng key không?

Không. Fail2ban giới hạn tốc độ các lỗi lặp lại từ một địa chỉ; nó không làm gì được trước một cuộc dò mật khẩu chậm, phân tán nơi mỗi địa chỉ đều nằm dưới ngưỡng. Xác thực chỉ bằng key (PasswordAuthentication no) khiến việc dò mật khẩu trở nên bất khả thi ngay lập tức, và khi đó Fail2ban sẽ giúp giảm nhiễu log và trục xuất các scanner sớm. Hãy dùng cả hai, và lý tưởng nhất là giữ SSH hoàn toàn không xuất hiện trên internet công cộng.