התקנת Fail2ban ב-Ubuntu 24.04 להגנה על SSH

מה Fail2ban עושה בפועל

Fail2ban הוא daemon הקורא לוגים. הוא עוקב אחר הודעות אימות SSH, ולאחר מספר כשלונות מאותה כתובת בפרק זמן קצר, הוא מריץ פקודת firewall שחוסמת את הכתובת הזו לתקופה מסוימת. זהו הרעיון המרכזי. ההגדרות כוללות כ-30 שורות בקובץ אחד, ובגרסת Ubuntu 24.04 ההתקנה היא פקודת apt אחת, המגנה עליכם עוד לפני שערכתם דבר.

חשוב להבין מה התוכנה עושה ומה לא. Fail2ban אינו מבצע אימות (authentication), אינו מצפין דבר, ואינו עוצר ניסיון התחברות יחיד ומכוון — הוא עוצר רק ניסיונות חוזרים מאותה כתובת מקור. הוא משמש כמסנן רעשים וכמגביל קצב (rate limiter), ולא כמנעול. תפקידו הוא להפסיק את סריקת הרקע המתמשכת של port 22 לבזבז את ה-CPU, רוחב הפס ומקום הלוגים שלכם, ולהאט תוקפים שמחויבים להשתמש בכתובת אחת בכל פעם.

מה Fail2ban אינו מחליף

Fail2ban היא השכבה השלישית, לא הראשונה. אם השרת שלכם עדיין מקבל סיסמאות SSH, רשת botnet הפרוסה על פני אלפי כתובות יכולה להמשיך בניסיונות ניחוש, מכיוון שכל כתובת נשארת מתחת לסף החסימה (ban threshold) ולא מפעילה אותו. ההגנה האמיתית מפני זה היא אימות באמצעות מפתח בלבד (key-only authentication), שהופך את ניחוש הסיסמה לבלתי אפשרי ללא קשר למספר הניסיונות. Fail2ban בשילוב עם אימות מפתח בלבד מבצעת שני דברים מועילים: היא מסירה את רעשי ה-brute-force מהיומנים (logs) שלכם, והיא מקדימה את הרחקה של סורקים (scanners) כדי שיפסיקו להכות בפורט. התייחסו לכך כהגנה רב-שכבתית (defence in depth). היא פועלת מאחורי אימות מפתח ומאחורי חומת אש (firewall), לעולם לא לפניהם.

דרישות קדם, והמציאות של Ubuntu 24.04

עליך להחזיק ב-VPS המריץ Ubuntu 24.04 עם הרשאות root או sudo, כאשר SSH פעיל — מומלץ להשתמש באימות באמצעות מפתח (key authentication). Fail2ban צורך משאבים מועטים: כמה עשרות מגה-בייט של RAM, ואין צורך בכיוונון הגדרות (limits).

כעת החלק שכל המדריכים הישנים טועים בו. במשך שנים העצה הסטנדרטית הייתה "התקן Fail2ban, ואז הוסף backend = systemd, מכיוון ש-Ubuntu הפסיקה לכתוב את /var/log/auth.log". עצה זו מתארת שינוי אמיתי — אימג'ים מודרניים של שרתים וענן מגיעים ללא rsyslog, לכן יומני ה-SSH נכתבים ל-systemd journal בלבד וקובץ הטקסט אינו קיים — אך בחבילת Fail2ban ב-Ubuntu 24.04 הדבר כבר מטופל. החבילה כוללת את /etc/fail2ban/jail.d/defaults-debian.conf, וקובץ זה, ולא ברירת המחדל המקורית, הוא מה שהשרת שלך מריץ בפועל:

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

[sshd]
enabled = true

קרא זאת בעיון, שכן זה פותר שתי שאלות לפני שתתחיל לעבוד. backend = systemd אומר ש-SSH jail קורא מה-journal, ולכן היעדר auth.log אינו משנה. banaction = nftables אומר שהחסימות מופעלות באמצעות nftables, שהוא ה-firewall ש-Ubuntu 24.04 משתמשת בו בפועל, במקום iptables הישן. ו-[sshd] enabled = true אומר שה-jail פעיל כבר מהאתחול הראשון. השורה התחתונה: התקנה סטנדרטית של apt install fail2ban ב-Ubuntu 24.04 חוסמת SSH brute-force באופן אוטומטי. רוב העבודה שלך תתמקד באימות הדבר, כיוונון המדיניות, ווידוא שלא תינעל מחוץ למערכת.

מלכוד ה-auth.log הישן עדיין רלוונטי בשלושה מצבים, וכדאי להכיר אותם: התקנת את Fail2ban באמצעות pip במקום apt, ולכן אין defaults-debian.conf; אתה נמצא בתוך container ללא הרשאות שאין לו systemd journal לקרוא; או שפעלת לפי מדריך ישן והדבקת את backend = auto בתוך ה-jail.local שלך, ובכך דרסת את ברירת המחדל שעובדת. סעיף ה-failure-modes מציג בדיוק איך כל מצב נראה.

Step 1: התקנה ואימות פעילות החסימה

sudo apt update
sudo apt install -y fail2ban

בגרסת Ubuntu 24.04 מגיע Fail2ban 1.0.2. החבילה כוללת את python3-systemd כ-dependency הכרחי, ולכן ה-journal backend כולל את כל הרכיבים הנדרשים. השירות מופעל ומתחיל באופן אוטומטי:

sudo systemctl status fail2ban

עליך לוודא ש-active (running) פעיל. לאחר מכן, בדוק את ה-jail שכבר פועל:

sudo fail2ban-client status sshd

בשרת VPS ציבורי שנגיש לרשת אפילו במשך דקות ספורות, ניתן לראות לרוב כבר ספירת כשלונות וכתובות שנחסמו — סורקי האינטרנט סורקים את port 22 ללא הרף. זהו ההוכחה שהגדרת ברירת המחדל עובדת. בשלב זה אתה משפר את ההגדרות הקיימות, ולא בונה אותן מאפס.

Step 2: Edit jail.local, never jail.conf

Fail2ban שומר את ברירת המחדל המקורית ב-/etc/fail2ban/jail.conf. אל תערוך את הקובץ הזה. כל apt upgrade של החבילה יכול להחליף אותו, והשינויים שלך יימחקו ללא אזהרה. Fail2ban קורא קבצים בסדר קבוע — jail.conf תחילה, לאחר מכן כל מה שנמצא ב-jail.d/, ואז ב-jail.local — והערך האחרון הוא הקובע. קובץ ה-.local הוא שלך, ושדרוגי חבילה לעולם לא נוגעים בו. כלל זה תקף גם ל-filters, שבהם קובץ *.local דורס את ה-filter.d/*.conf המגיע עם החבילה.

לכן, יש לכתוב jail.local קטן שדורס רק את מספר ההגדרות הרלוונטיות עבורך, ולהשאיר גם את jail.conf וגם את ה-jail.d/defaults-debian.conf המקורי ללא שינוי כסימוכין.

Step 3: Write /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, היא של עשר דקות בלבד; שעה היא מינימום הגיוני יותר. חמישה כשלים מאותה כתובת בתוך עשר דקות יגרמו לחסימה. בני אדם טועים בהקלדת הסיסמה פעם או פעlichen; חמישה כשלים בתוך עשר דקות מעידים על script.
• ignoreip היא הגנת הבטיחות שלך. הזן כאן את הכתובת הציבורית ממנה אתה מתחבר, כדי ש-Fail2ban לא יוכל לחסום אותך מהשרת שלך. חיבור ביתי עם IP משתנה הוא סיבה להעדיף את שיטת ה-VPN בסוף המדריך, אך אין זה סיבה לדלג על שורה זו.
• bantime.increment = true גורמת לכל חסימה חוזרת להיות ארוכה מהקודמת — שעה, אחר כך שעתיים, אחר כך ארבע — עד bantime.maxtime. כתובות שחוזרות שוב ושוב ייחסמו למשך זמן ממושך יותר בכל פעם.

מצא את הכתובת שיש להוסיף לרשימת הכתובות המורשות (whitelist) מהמכונה ממנה אתה מבצע SSH, ולא מהשרת:

curl -s ifconfig.me

ניתן ליצור קובץ jail.local המותאם לפורטים ולמדיניות החסימה שלך כאן, ולאחר מכן להדביק אותו בתוך הקובץ:

Step 4: Restart and verify it is reading the 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. אם המספר גבוה מ-0, או אם הוא עולה כאשר נכשל בהתחברות במכוון ממכשיר אחר, ה-journal נקרא והתהליך הושלם. אם המספר נשאר על 0 ללא קשר למספר הכשלונות — ואתה בטוח שאינך בודק מהכתובת ב-ignoreip — עבור למצבי הכשל (failure modes) המפורטים להלן.

שים לב ששורת ה-Journal matches עדיין מציינת את sshd.service. ב-Ubuntu יחידת ה-SSH היא למעשה ssh.service, אך הפילטר המצורף מתאים גם ל-_COMM=sshd, ו-OpenSSH בגרסה 24.04 רושם כשלים מתהליך בשם sshd, ולכן ההתאמה עובדת. פרט זה רלוונטי רק אם אתה משתמש ב-OpenSSH חדש יותר (גרסה 9.8 ומעלה, שבה ה-per-connection worker הוא sshd-session); מצבי הכשל מכסים גם מקרה זה.

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: Unban yourself, and recover if you are locked out

אם חסמת כתובת שלא היית אמור לחסום — למשל את הכתובת של עצמך — הסר אותה:

sudo fail2ban-client set sshd unbanip 10.0.0.66

הפקודה מחזירה 1 בהצלחה. כדי לנקות את כל החסימות מכל ה-jail:

sudo fail2ban-client unban --all

אל תסתמך על כך שסשן SSH פתוח יציל אותך: חסימת nftables דוחה כל חבילה (packet) מהכתובת החסומה לפורט 22 — כולל חיבורים קיימים (established connections) — לכן סשן קיים יקפא ברגע החסימה. אם חסמת את עצמך ואין לך רשומה ב-ignoreip, אתה תהיה נעול עד שתפוג החסימה — ניתן לשחזר את הגישה דרך ממשק ה-web console של הספק (VNC או serial), שאינו עובר דרך SSH, ולקרוא פקודת unban או להמתין עד שbantime יתפוג.

Step 7: Make bans persist and escalate

Fail2ban שומרת חסימות פעילות בבסיס נתונים SQLite קטן ב-/var/lib/fail2ban/fail2ban.sqlite3, כך שהן נשמרות גם לאחר הפעלה מחדש של השירות או של המערכת; המידע לא יאבד. שורות ה-bantime.increment שהוספת הופכות כל עבריין חוזר לבעיה הולכת וגוברת עבורו — משך החסימה מכפיל את עצמו تقريبًا, מ-one hour ועד one week.

כדי להחיל מדיניות "שלוש אזהרות" על כל המערכת, Fail2ban מספקת jail מסוג recidive המנטרת את ה-/var/log/fail2ban.log של עצמה. ה-jail מעניקה חסימות ארוכות לכל כתובת שנחסמה שוב ושוב בכל ה-jails. מכיוון ש-[DEFAULT] משתמשת כעת ב-systemd backend, יש להגדיר את ה-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, שם הן לא מופיעות.

Step 8: Pair it with key-only SSH, and better still a VPN

Fail2ban יעיל באמת רק כאשר משתמשים באימות באמצעות מפתח (key authentication) בלבד. צור קובץ הגדרות תחת /etc/ssh/sshd_config.d/ — לדוגמה /etc/ssh/sshd_config.d/00-hardening.conf — והגדר:

PasswordAuthentication no
KbdInteractiveAuthentication no

לאחר מכן בצע את sudo systemctl restart ssh. כאשר אימות באמצעות סיסמה מבוטל, מתקפות brute force לא יוכלו להצליח כלל; במצב זה, תפקיד Fail2ban הוא לצמצם את רעש הלוגים ולהרחיק סורקים (scanners) בשלב מוקדם. פתרון חזק עוד יותר הוא להסיר את SSH מהאינטרנט הציבורי לחלוטין: השתמש ב-WireGuard VPN המארח בעצמך וחסום ב-firewall את פורט 22, כך שהוא יקבל תגובה רק דרך ה-tunnel. לא ניתן לבצע brute-force על פורט שאינו נגיש, ו-Fail2ban הופך למנגנון הגנה משלים ולא לקו ההגנה הראשון.

Fail2ban אינו מיועד ל-SSH בלבד. כל שירות שמ记录 (logs) ניסיונות התחברות כושלים יכול לקבל jail — שרת דואר, אתר nginx, או מנהל סיסמאות Vaultwarden המארח בעצמך שאת לא תרצה להשאיר פתוח להתקפות credential stuffing. ברגע שאפליקציית Web נמצאת מאחורי אתר nginx עם תעודת Let's Encrypt, הפנה פילטר של Fail2ban אל ה-access log שלה, בדיוק כפי ש-SSH jail מפנה אל ה-journal.

Failure modes, with the exact strings you will see

"Have not found any log file for sshd jail", and Fail2ban will not start. This is the old auth.log problem, and on Ubuntu 24.04 you only hit it if something has overridden the packaged default — a pip install with no defaults-debian.conf, a container with no journal, or a stray backend = auto you pasted into jail.local. On a file backend with no /var/log/auth.log, the sshd jail cannot find its log and the whole daemon aborts. fail2ban.log shows:

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

Because that error is fatal, the service never comes up, and fail2ban-client status then reports the downstream symptom:

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

That "socket path" line does not mean Fail2ban is broken — it means it never started because one jail could not find its log. Setting backend = systemd in [DEFAULT], which the Ubuntu package already does for you, fixes both messages at once.

Jail is active but Total failed never moves. The daemon is running and the journal is being read, yet real failures pile up in journalctl -u ssh while the counter sits at 0. First rule out the obvious: you are testing from an address listed in ignoreip, so your own failures are exempt by design. If that is not it, you are on an OpenSSH build where the per-connection worker is sshd-session (9.8 and later), whose journal _COMM is sshd-session, not sshd, so the shipped match misses it. Widen the match in the [sshd] block:

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

Restart, fail a login on purpose from an address not in ignoreip, and confirm Total failed finally climbs.

You banned yourself: Connection refused. You left your own address out of ignoreip, tested a few bad logins, and now:

ssh: connect to host 10.0.0.10 port 22: Connection refused

The refusal, rather than a silent timeout, is the nftables action's default reject verdict doing its job — on you. Fix it as in Step 6: unban from a session on a different, unbanned address, or from the provider console — a session already open from the banned address freezes too. Then add your address to ignoreip so it cannot happen again.

Fail2ban says an address is banned, but it can still connect. The counter in status sshd rises, yet the address still reaches port 22. This is a ban-action-versus-firewall mismatch, and on Ubuntu 24.04 it almost always means you overrode the working banaction = nftables with banaction = iptables-multiport copied from an older guide, on a box with no iptables layer. fail2ban.log shows:

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

Delete that override and let the packaged nftables action stand, or, if you manage the firewall entirely through ufw and want bans to show up there, set banaction = ufw in [DEFAULT]. Restart and confirm the rule appears with sudo nft list ruleset | grep f2b.

Fail2ban will not start after editing jail.local. A typo — a stray heading or a bad time value — makes the service refuse to come up. Ask Fail2ban to check the config before it runs:

sudo fail2ban-client -t

It names the file and the jail with the problem, for example Errors in jail 'sshd'. Skipping..., so you fix the source rather than guessing.

FAQ

האם התקנת Fail2ban המקורית ב-Ubuntu 24.04 באמת חוסמת התקפות SSH?

כן. החבילה כוללת את /etc/fail2ban/jail.d/defaults-debian.conf, המפעיל את ה-jail של sshd, מגדיר את backend = systemd כדי לקרוא את ה-systemd journal במקום את ה-/var/log/auth.log החסר, ומגדיר את banaction = nftables כך שהחסימות יוחלו דרך ה-firewall האמיתי של Ubuntu. הגדרה פשוטה של apt install fail2ban מגנה על SSH כבר מההפעלה הראשונה. ניתן לוודא זאת באמצעות sudo fail2ban-client status sshd ולחפש ערך שאינו 0 ב-Total failed.

מדוע Fail2ban לא חוסם דבר במערכת שלי?

בדקו את שלושת הגורמים הנפוצים לפי הסדר. ייתכן שאתם בודקים מכתובת שנמצאת ב-ignoreip, שהיא מוחרגת מהחסימה על פי תכנון. ייתכן ששיניתם את ברירת המחדל התקינה על ידי הדבקת backend = auto בתוך jail.local מתוך מדריך ישן, מה שמשבש את קריאת ה-journal ב-image ללא auth.log. לחלופין, ייתכן שאתם בתוך container ללא systemd journal לקריאה. בדקו את Total failed בתוך fail2ban-client status sshd: אם הערך אינו עולה בזמן ש-journalctl -u ssh מראה כשלונות אמיתיים, ה-jail קורא מהמקום הלא נכון.

איך אני מבטל חסימה (unban) של כתובת ה-IP שלי?

הריצו את sudo fail2ban-client set sshd unbanip YOUR.IP.HERE, שמחזיר 1 בהצלחה, או את sudo fail2ban-client unban --all כדי לנקות את כל החסימות. אם נשארתם מחוץ ל-SSH, השתמשו ב-web console או ב-VNC של ספק השירות כדי להריץ את אותה פקודה — החסימה דוחה כל חבילה (packet) מכתובתכם לפורט 22, ולכן גם סשן שהיה פתוח כבר יפסיק לעבוד. לאחר מכן, הוסיפו את הכתובת שלכם ל-ignoreip כדי למנוע חסימה חוזרת.

מה ההבדל בין jail.conf לבין jail.local?

jail.conf מכיל את ברירת המחדל המקורית של Fail2ban ומוחזר בכל שדרוג חבילה, לכן כל עריכה שם תאבד בסופו של דבר. החבילה של Debian/Ubuntu רושמת הגדרות משלה מעל באמצעות jail.d/defaults-debian.conf. השינויים שלכם צריכים להיכתב ב-jail.local, שנקרא אחרון ומבטל את שניהם, ואינו משתנה בשדרוגים. השאירו את jail.conf כקובץ ייחוס בלבד (read-only).

האם Fail2ban מחליף אימות SSH מבוסס מפתחות?

לא. Fail2ban מגביל את קצב הכשלונות החוזרים מכתובת אחת; הוא אינו עושה דבר נגד ניסויים איטיים ומבוזרים שבהם כל כתובת נשארת מתחת לסף. אימות באמצעות מפתח בלבד (PasswordAuthentication no) הופך ניחוש סיסמה לבלתי אפשרי לחלוטין, ו-Fail2ban נועד לצמצם רעש ביומנים (logs) ולגרש סורקים (scanners) בשלב מוקדם. מומלץ להשתמש בשניהם, ובתנאים אידיאליים להשאיר את SSH מנותק מהאינטרנט הציבורי לחלוטין.