Ubuntu 24.04 Fail2ban Kurulumu ve SSH Koruması

Fail2ban gerçekte ne yapar

Fail2ban bir log okuma daemon'ıdır. SSH kimlik doğrulama mesajlarını izler. Belirli bir zaman aralığında tek bir adresten gelen birkaç başarısız denemeden sonra, o adresi bir süreliğine engelleyen bir firewall komutu çalıştırır. Temel mantık budur. Tek bir dosya içinde yaklaşık otuz satırlık bir yapılandırmadan oluşur. Ubuntu 24.04 üzerinde kurulum, herhangi bir düzenleme yapmadan önce koruma sağlamak için tek bir apt komutudur.

Neyin ne olduğu konusunda net olun. Fail2ban kimseyi doğrulamaz, hiçbir şeyi şifrelemez ve kararlı bir giriş denemesini durduramaz; sadece aynı kaynaktan gelen tekrarlanan denemeleri engeller. Bir kilit değil, bir gürültü filtresi ve hız sınırlayıcıdır. Görevi, port 22 üzerindeki sürekli arka plan taramalarının CPU, bant genişliği ve log alanı tüketmesini durdurmak ve her seferinde tek bir adresten gelmek zorunda olan saldırganları yavaşlatmaktır.

Fail2ban'ın yerine geçmediği unsurlar

Fail2ban birinci katman değil, üçüncü katmandır. Sunucunuz hala SSH şifrelerini kabul ediyorsa, binlerce adrese yayılmış bir botnet sürekli deneme yapmaya devam edebilir; çünkü her bir adres ban eşiğinin altında kalır ve eşiği tetiklemez. Buna karşı gerçek savunma, kaç deneme yapılırsa yapılsın şifre tahmin etmeyi imkansız kılan anahtar tabanlı (key-only) kimlik doğrulamadır. Anahtar tabanlı kimlik doğrulama üzerine kurulan Fail2ban iki yararlı işlev sağlar: log kayıtlarındaki brute-force gürültüsünü temizler ve tarayıcıları erken aşamada uzaklaştırarak portu sürekli meşgul etmelerini engeller. Bu yapı, derinlemesine savunma (defence in depth) olarak değerlendirilmelidir. Anahtar kimlik doğrulamanın ve güvenlik duvarının (firewall) arkasında yer alır, asla önlerinde yer almaz.

Ön Koşullar ve Ubuntu 24.04 Gerçekliği

Ubuntu 24.04 yüklü, root veya sudo yetkisine sahip ve SSH erişimi aktif olan bir VPS gereklidir; SSH için anahtar tabanlı kimlik doğrulama kullanılması önerilir. Fail2ban kaynak tüketimi açısından verimlidir: sadece birkaç on megabayt RAM kullanır ve limit ayarlarının yapılandırılmasına gerek yoktur.

Eski kılavuzların hata yaptığı kısım şudur: Yıllardır verilen standart tavsiye, "Fail2ban kurun, ardından backend = systemd ekleyin, çünkü Ubuntu /var/log/auth.log yazmayı bıraktı" şeklindeydi. Bu tavsiye gerçek bir değişikliğe işaret eder; modern sunucu ve bulut imajları rsyslog olmadan gelir, bu nedenle SSH logları yalnızca systemd journal'a yazılır ve ilgili metin dosyası artık mevcut değildir. Ancak Ubuntu 24.04 üzerindeki Fail2ban paketi bu durumu zaten kapsamaktadır. Paket /etc/fail2ban/jail.d/defaults-debian.conf ile birlikte gelir ve sunucunuzun çalıştırdığı şey varsayılan ayarlar değil, bu dosyadır:

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

[sshd]
enabled = true

Bu kısmı dikkatlice okuyun, çünkü herhangi bir işlem yapmadan önce iki soruyu yanıtlamaktadır. backend = systemd, SSH jail yapısının journal okuduğu anlamına gelir; bu nedenle auth.log dosyasının eksik olması sorun teşkil etmez. banaction = nftables, yasaklamaların legacy iptables yerine Ubuntu 24.04'ün kullandığı nftables üzerinden uygulandığı anlamına gelir. [sshd] enabled = true ise jail yapısının ilk açılıştan itibaren aktif olduğu anlamına gelir. Sonuç: Ubuntu 24.04 üzerindeki standart bir apt install fail2ban, SSH brute-force saldırılarını doğrudan engeller. Yapmanız gereken işlemler; bunu doğrulamak, politikayı optimize etmek ve sistemden dışarıda kalmadığınızdan emin olmaktır.

Eski auth.log tuzağı üç durumda hala sorun yaratmaktadır ve bunlar bilinmelidir: Fail2ban'ı apt yerine pip ile kurduğunuz için defaults-debian.conf bulunmamaktadır; okunacak bir systemd journal bulunmayan yetkisiz bir konteyner içerisindesiniz; veya eski bir kılavuzu takip ederek çalışan varsayılan ayarı geçersiz kılacak şekilde jail.local içerisine backend = auto yapıştırdınız. Hata modları bölümü, her bir durumun neye benzediğini göstermektedir.

Adım 1: Kurulum yapın ve engelleme işleminin çalıştığını doğrulayın

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04 sürümü Fail2ban 1.0.2 sürümü ile birlikte gelir. Paket, python3-systemd bileşenini zorunlu bağımlılık olarak yükler; bu sayede journal backend gerekli tüm bileşenlere sahip olur. Servis, kendini etkinleştirir ve başlatır:

sudo systemctl status fail2ban

active (running) gerekmektedir. Ardından, halihazırda çalışan jail yapılandırmasını inceleyin:

sudo fail2ban-client status sshd

Birkaç dakikadır erişilebilir durumda olan halka açık bir VPS üzerinde, genellikle başarısız giriş denemelerinin sayıldığını ve adreslerin engellendiğini görürsünüz; internet port 22'yi sürekli taramaktadır. Bu durum, varsayılan yapılandırmanın çalıştığının kanıtıdır. Bu aşamadan itibaren, sıfırdan bir yapılandırma oluşturmak yerine mevcut olanı özelleştireceksiniz.

Step 2: jail.local dosyasını düzenleyin, jail.conf dosyasını asla düzenlemeyin

Fail2ban, varsayılan ayarlarını /etc/fail2ban/jail.conf dizininde tutar. Bu dosyayı düzenlemeyin. Paketin her bir apt upgrade bileşeni bu dosyanın yerine geçebilir ve değişiklikleriniz herhangi bir uyarı olmaksızın silinir. Fail2ban dosyaları belirli bir sırayla okur: önce jail.conf, ardından jail.d/ içindeki tüm dosyalar ve son olarak jail.local; son okunan değer geçerli olur. .local dosyası kullanıcıya aittir ve paket güncellemeleri bu dosyaya dokunmaz. Aynı kural filtreler için de geçerlidir; bir *.local dosyası, paketle birlikte gelen filter.d/*.conf dosyasını geçersiz kılar.

Bu nedenle, sadece ihtiyacınız olan birkaç ayarı değiştiren küçük bir jail.local dosyası yazın. Referans olarak jail.conf ve paketle gelen jail.d/defaults-debian.conf dosyalarını orijinal haliyle bırakın.

Step 3: /etc/fail2ban/jail.local dosyasını yazın

sudo nano /etc/fail2ban/jail.local

ignoreip satırındaki adresi kendi genel IP adresinizle değiştirerek aşağıdakini dosyaya ekleyin:

[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

Her satırın bir işlevi vardır:

• bantime, findtime, maxretry politika ayarlarıdır. Varsayılan olarak gelen bantime değeri sadece on dakikadır; bir saat daha makul bir alt sınırdır. On dakika içinde bir adresten gelen beş hatalı deneme yasaklama ile sonuçlanır. Gerçek kullanıcılar bir veya iki kez şifreyi yanlış yazabilir; ancak on dakika içinde beş hata bir script kullanımına işarettir.
• ignoreip güvenlik önleminizdir. Fail2ban'ın sizi kendi sunucunuzdan kilitlememesi için bağlantı kurduğunuz genel adresi buraya yazın. IP adresi sürekli değişen bir ev bağlantısı, sondaki VPN yaklaşımını tercih etmek için bir nedendir; bu satırı atlamak için bir neden değildir.
• bantime.increment = true her tekrarlanan yasağı bir öncekinden daha uzun hale getirir — bir saat, sonra iki, sonra dört — ve bantime.maxtime değerine kadar ulaşır. Tekrar eden adresler kademeli olarak engellenir.

Beyaz listeye eklenecek adresi sunucudan değil, SSH ile bağlandığınız makineden bulun:

curl -s ifconfig.me

Portlarınıza ve yasaklama politikanıza göre ayarlanmış bir jail.local dosyasını buradan oluşturabilir ve ardından dosyaya yapıştırabilirsiniz:

Step 4: Yeniden başlatın ve journal okunduğunu doğrulayın

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

-t önce bir konfigürasyon testi gerçekleştirir. Bu sayede jail.local içindeki bir yazım hatası, servisin çalışmaz durumda kalmasına neden olmak yerine burada hata verir. Sağlıklı bir jail durumu şu şekildedir:

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'ın giriş denemelerini gerçekten okuduğunu kanıtlayan sayı Total failed değeridir. Eğer bu değer sıfırdan büyükse veya başka bir makineden kasıtlı olarak hatalı giriş denemesi yapıldığında artıyorsa, journal okunuyor demektir ve işlem tamamlanmıştır. Eğer kaç kez hatalı giriş yapılırsa yapılsın değer 0 seviyesinde kalıyorsa —ve ignoreip adresinden test yapmadığınızdan eminseniz— aşağıdaki hata modlarına geçin.

Journal matches satırının hala sshd.service ismini verdiğine dikkat edin. Ubuntu üzerinde SSH ünitesi aslında ssh.service şeklindedir; ancak beraberinde gelen filtre aynı zamanda _COMM=sshd ile de eşleşir. Ayrıca OpenSSH 24.04 sürümü, hataları sshd adlı bir işlemden loglar, bu nedenle eşleşme sağlanır. Bu ayrıntı yalnızca daha yeni bir OpenSSH (9.8 veya sonrası, bağlantı başına işçi süreci sshd-session olan sürüm) kullanıyorsanız önemlidir; hata modları bu durumu kapsamaktadır.

Step 5: Gerçek bir engelleme gerçekleşmesini izleyin veya test etmek için manuel olarak engelleyin

Herhangi bir genel VPS üzerinde gerçek engellemeler dakikalar içinde kendiliğinden gerçekleşir. Bir engellemeyi izlemek için log dosyasını takip edin:

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

Bir engelleme şu şekilde görünür:

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

Sistemi beklemek yerine uçtan uca test etmek için bir dokümantasyon adresini manuel olarak engelleyin — asla kendi adresinizi kullanmayın:

sudo fail2ban-client set sshd banip 10.0.0.66

1 çıktısı verilir ve adres fail2ban-client status sshd içindeki Banned IP list altında görünür. Şimdi engellemenin firewall üzerinde gerçekten mevcut olduğunu doğrulayın. Ubuntu 24.04 üzerinde bu iptables değil, nftables'dır:

sudo nft list table inet f2b-table

10.0.0.66 içeren addr-set-sshd adlı bir set ve bu setteki tüm kaynakları reddeden f2b-chain adlı bir chain göreceksiniz. Eğer fail2ban-client bir adresin engellendiğini söylüyor ancak nft list altında hiçbir şey görünmüyorsa, engelleme işleminiz firewall ile eşleşmiyor demektir; hata modlarındaki nftables/iptables notuna bakın.

Step 6: Kendinizi yasaklı durumdan çıkarın ve erişiminiz kesilirse kurtarın

Yanlışlıkla kendi adresinizi yasakladıysanız, bu yasağı kaldırın:

sudo fail2ban-client set sshd unbanip 10.0.0.66

İşlem başarılı olduğunda 1 döndürür. Tüm jail yapılandırmalarındaki tüm yasakları temizlemek için:

sudo fail2ban-client unban --all

Mevcut bir SSH oturumunun sizi kurtaracağını varsaymayın: nftables yasağı, yasaklı adresten 22 portuna gelen her paketi reddeder; bu durum mevcut bağlantılar için de geçerlidir. Dolayısıyla, mevcut oturum yasak uygulandığı anda donar. Kendinizi yasaklarsanız ve ignoreip kaydınız yoksa, yasak süresi dolana kadar erişiminiz kesilir. Bu durumda, SSH üzerinden çalışmayan ve sağlayıcınızın web konsolu (VNC veya serial) üzerinden kurtarma işlemi yapın; burada ya bantime süresinin dolmasını bekleyin ya da unban komutunu çalıştırın.

Adım 7: Yasaklamaları kalıcı hale getirin ve kademelendirin

Fail2ban, aktif yasaklamaları /var/lib/fail2ban/fail2ban.sqlite3 konumundaki küçük bir SQLite veritabanında tutar. Bu sayede servis yeniden başlatıldığında veya sistem yeniden başlatıldığında yasaklamalar silinmez. Daha önce eklediğiniz bantime.increment satırları, her tekrar eden ihlalci için sorunu kademeli olarak artırır; yasak süresi bir saatten bir haftaya kadar yaklaşık iki katına çıkar.

Buna ek olarak, sistem genelinde bir "üç hak" politikası için Fail2ban, kendi /var/log/fail2ban.log kayıtlarını izleyen bir recidive jail yapısı ile birlikte gelir. Bu yapı, tüm jail'lerde defalarca yasaklanan adreslere uzun süreli yasaklar uygular. [DEFAULT] artık systemd backend kullandığı için, bu jail yapısını okuması için tasarlanan log dosyasına sabitlemeniz gerekir:

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

Açıkça belirtilen logpath ile birlikte backend = auto, recidive işleminin düz fail2ban.log dosyasını okumasını sağlar. Ban satırları aslında bu dosyada görünür; küresel olarak ayarladığınız systemd varsayılanı ise bu satırların bulunmadığı journal dosyasına yönlendirme yapacaktır.

Step 8: Key-only SSH ve VPN kullanımı

Fail2ban, yalnızca anahtar tabanlı kimlik doğrulama ile etkili olur. /etc/ssh/sshd_config.d/ dizini altında, örneğin /etc/ssh/sshd_config.d/00-hardening.conf konumunda bulunan bir yapılandırma dosyasında şu ayarı yapın:

PasswordAuthentication no
KbdInteractiveAuthentication no

Ardından sudo systemctl restart ssh komutunu çalıştırın. Parola girişi devre dışı bırakıldığında, kaba kuvvet (brute force) saldırıları tamamen başarısız olur; bu durumda Fail2ban, log kalabalığını azaltmak ve tarayıcıları erkenden engellemek için kullanılır. Daha güvenli bir yöntem, SSH servisini internete tamamen kapatmaktır: SSH servisini kendi sunucunuzdaki bir WireGuard VPN arkasına yerleştirin ve 22 numaralı portu sadece tünel üzerinden yanıt verecek şekilde güvenlik duvarı ile kısıtlayın. Erişilemeyen bir port üzerinde kaba kuvvet saldırısı yapılamaz; bu durumda Fail2ban, bir ön hat olmaktan çıkıp yedek bir koruma haline gelir.

Fail2ban sadece SSH için değildir. Başarısız giriş denemelerini loglayan her servis için bir jail oluşturulabilir; örneğin bir e-posta sunucusu, bir nginx sitesi veya web girişi credential stuffing saldırılarına açık olmaması gereken kendi sunucunuzdaki bir Vaultwarden şifre yöneticisi. Bir web uygulaması Let's Encrypt sertifikalı bir nginx sitesi arkasına alındığında, SSH jail yapısında olduğu gibi, Fail2ban filtresini uygulamanın erişim loguna yönlendirin.

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

Ubuntu 24.04 üzerindeki standart Fail2ban kurulumu SSH saldırılarını gerçekten engeller mi?

Evet. Paket /etc/fail2ban/jail.d/defaults-debian.conf içerir. Bu paket sshd jail yapısını etkinleştirir, backend = systemd ayarını mevcut olmayan /var/log/auth.log yerine systemd journal okuyacak şekilde yapılandırır ve yasaklamaların Ubuntu'nun gerçek firewall'u üzerinden uygulanması için banaction = nftables ayarını yapar. Standart bir apt install fail2ban yapılandırması, ilk kurulumdan itibaren SSH'ı korur. Durumu sudo fail2ban-client status sshd ile doğrulayın ve Total failed değerinin sıfırdan farklı olduğunu kontrol edin.

Fail2ban sistemimde neden hiçbir şeyi engellemiyor?

Sırasıyla üç yaygın nedeni eleyin. Test işlemini, tasarım gereği muaf tutulan ignoreip adresinden yapıyor olabilirsiniz. Eski bir kılavuzdan jail.local dosyasına backend = auto yapıştırarak çalışan varsayılan ayarları bozmuş olabilirsiniz; bu durum, auth.log bulunmayan imajlarda journal okuma işlemini bozar. Veya okuyacak bir systemd journal'ı olmayan bir container içinde olabilirsiniz. fail2ban-client status sshd içindeki Total failed değerini kontrol edin: Eğer journalctl -u ssh gerçek hataları gösterirken bu değer hiç yükselmiyorsa, jail yanlış yeri okuyor demektir.

Kendi IP adresimin engelini nasıl kaldırırım?

Başarılı olduğunda 1 döndüren sudo fail2ban-client set sshd unbanip YOUR.IP.HERE komutunu veya tüm engelleri temizlemek için sudo fail2ban-client unban --all komutunu çalıştırın. SSH erişiminiz engellendiyse, aynı komutu çalıştırmak için sağlayıcınızın web veya VNC konsolunu kullanın; yasaklama işlemi, adresinizden 22 portuna gelen tüm paketleri reddeder, bu nedenle halihazırda açık olan bir oturum bile çalışmayı durdurur. Tekrarını önlemek için adresinizi ignoreip dosyasına ekleyin.

jail.conf ve jail.local arasındaki fark nedir?

jail.conf dosyası Fail2ban'ın orijinal varsayılan ayarlarını içerir ve her paket güncellemesinde üzerine yazılır; bu nedenle buradaki düzenlemeler silinir. Debian/Ubuntu paketi, kendi ayarlarını jail.d/defaults-debian.conf aracılığıyla bu ayarların üzerine ekler. Değişiklikleriniz, en son okunan ve her iki ayarı da geçersiz kılan, güncellemelerden etkilenmeyen jail.local dosyasına yapılmalıdır. jail.conf dosyasını sadece referans olarak salt okunur bırakın.

Fail2ban, anahtar tabanlı SSH kimlik doğrulamasının yerini tutar mı?

Hayır. Fail2ban, tek bir adresten gelen tekrarlanan hataları hız sınırına tabi tutar; her adres eşik değerinin altında kaldığı durumlarda, yavaş ve dağıtık yapılan tahmin saldırılarına karşı bir etkisi yoktur. Sadece anahtar tabanlı kimlik doğrulama (PasswordAuthentication no), parola tahmin etmeyi tamamen imkansız hale getirir; Fail2ban ise log kalabalığını azaltır ve tarayıcıları erkenden uzaklaştırır. Her ikisini de kullanın ve ideal olarak SSH'ı tamamen halka açık internetten kapatın.