Ubuntu 24.04 Fail2ban Kurulumu ve SSH Bot Engelleme

Fail2ban gerçekte ne yapar

Fail2ban, log dosyalarını okuyan bir arka plan servisidir. SSH kimlik doğrulama mesajlarını izler ve kısa bir süre içerisinde tek bir adresten gelen birkaç başarısız denemeden sonra, o adresi belirli bir süreliğine engelleyen bir güvenlik duvarı komutu çalıştırır. Tüm mantık bundan ibarettir. Tek bir dosya içerisinde yaklaşık otuz satırlık bir yapılandırmadan oluşur ve Ubuntu 24.04 üzerinde kurulumu, herhangi bir düzenleme yapmadan önce sizi koruma altına alan tek bir apt komutundan ibarettir.

Fail2ban'in ne olduğunu ve ne olmadığını net bir şekilde anlamak gerekir. Fail2ban kimsenin kimliğini doğrulamaz, hiçbir şeyi şifrelemez ve kararlı bir giriş denemesini tek başına durduramaz; yalnızca aynı kaynaktan gelen tekrarlı denemeleri engeller. Bir kilit değil, bir gürültü filtresi ve hız sınırlayıcıdır. Görevi, 22 numaralı porttaki sürekli arka plan taramalarının CPU'nuzu, bant genişliğinizi ve log alanınızı boşa harcamasını engellemek ve aynı anda tek bir adresten gelmek zorunda olan saldırganları yavaşlatmaktır.

Fail2ban'in yerini tutmadığı şeyler

Fail2ban ilk değil, üçüncü savunma katmanıdır. Sunucunuz hala SSH parolalarını kabul ediyorsa, binlerce adrese yayılmış bir botnet tahmin yapmaya devam edebilir; çünkü her bir adres yasaklama eşiğinizin altında kalır ve tetiklemeyi asla gerçekleştirmez. Buna karşı gerçek savunma, parola tahminini kaç deneme yapılırsa yapılsın imkansız kılan anahtar tabanlı kimlik doğrulamadır. Anahtar tabanlı kimlik doğrulamanın üzerinde çalışan Fail2ban iki faydalı işlev görür: loglarınızdaki kaba kuvvet (brute-force) gürültüsünü temizler ve tarayıcıları erkenden uzaklaştırarak portu zorlamalarını engeller. Bunu derinlemesine savunma olarak değerlendirin. Fail2ban, anahtar tabanlı kimlik doğrulamanın ve güvenlik duvarının arkasında yer alır; asla önlerinde bulunmaz.

Ön gereksinimler ve Ubuntu 24.04 gerçeği

Root veya sudo yetkilerine sahip, SSH erişimi (tercihen anahtar tabanlı kimlik doğrulama ile) yapılandırılmış bir Ubuntu 24.04 VPS'e ihtiyacınız vardır. Fail2ban oldukça verimlidir: sadece birkaç on megabayt RAM tüketir ve herhangi bir limit ayarı gerektirmez.

Şimdi eski rehberlerin çoğunda hatalı aktarılan kısma gelelim. Yıllarca standart tavsiye "Fail2ban'i kurun, ardından backend = systemd ekleyin, çünkü Ubuntu artık /var/log/auth.log yazmıyor" şeklindeydi. Bu tavsiye yalnızca belirli imajlar için geçerlidir. Standart bir Ubuntu 24.04 sunucu veya bulut imajı hala rsyslog ile gelir; varsayılan kuralları auth,authpriv.* dosyasını /var/log/auth.log konumuna yazar. Bu nedenle çoğu VPS'te SSH hataları hem sistem günlüğüne hem de bu dosyaya kaydedilir. Minimal imajlar (Ubuntu 24.04 minimal bulut imajı rsyslog olmadan gelir) ve çoğu container, SSH günlüklerini yalnızca systemd günlüğüne yazar; bu durumda metin dosyası gerçekten mevcut değildir. Her iki durumda da Ubuntu 24.04 üzerindeki Fail2ban paketi bunu zaten hesaba katar. Paket, /etc/fail2ban/jail.d/defaults-debian.conf dosyasını sisteme ekler ve sunucunuz aslında yukarı akış varsayılanlarını değil, bu dosyayı çalıştırır:

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

[sshd]
enabled = true

Bunu dikkatlice okuyun, çünkü herhangi bir ayara dokunmadan önce iki soruyu yanıtlar. backend = systemd, SSH jail'inin günlüğü okuduğu anlamına gelir; bu nedenle imajınızın auth.log yazıp yazmaması bir fark yaratmaz. banaction = nftables, yasaklamaların eski iptables yerine Ubuntu 24.04'ün fiilen kullandığı güvenlik duvarı olan nftables üzerinden uygulandığı anlamına gelir. [sshd] enabled = true ise jail'in ilk açılıştan itibaren aktif olduğu anlamına gelir. Sonuç olarak: Ubuntu 24.04 üzerindeki standart bir apt install fail2ban, SSH kaba kuvvet saldırılarını kutudan çıktığı haliyle engeller. Yapacağınız işin çoğu bunu doğrulamak, politikayı ince ayar yapmak ve kendinizi dışarıda bırakmadığınızdan emin olmaktır.

Eski auth.log tuzağı hala üç durumda karşınıza çıkabilir ve bunları bilmekte fayda vardır: Fail2ban'i apt yerine pip ile kurmuş olabilirsiniz ve bu durumda defaults-debian.conf mevcut değildir; systemd günlüğü okunamayan, ayrıcalıksız bir container içindesinizdir; veya eski bir rehberi takip edip backend = auto içeriğini kendi jail.local dosyanıza yapıştırarak çalışan varsayılan ayarı geçersiz kılmışsınızdır. Birinci ve üçüncü durumlar, yalnızca rsyslog bulunmayan imajlarda (minimal imajlar gibi) SSH engellemesini bozar; çünkü rsyslog çalıştığında dosya arka ucu /var/log/auth.log dosyasını bulur ve çalışmaya devam eder. Hata modları bölümü, her bir durumun nasıl göründüğünü tam olarak açıklar.

Adım 1: Kurulum ve engelleme işleminin doğrulanması

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04, Fail2ban 1.0.2 sürümüyle gelir ve paket, zorunlu bir bağımlılık olarak python3-systemd paketini yükler; bu sayede journal arka ucu ihtiyaç duyduğu her şeye sahip olur. Servis, kurulumla birlikte otomatik olarak etkinleşir ve başlar:

sudo systemctl status fail2ban

active (running) komutunu çalıştırmanız gerekir. Ardından, halihazırda görevini yerine getiren 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 IP adreslerinin engellendiğini göreceksiniz; internet üzerindeki botlar 22 numaralı portu sürekli olarak tarar. Bu, varsayılan yapılandırmanın çalıştığının kanıtıdır. Bu noktadan itibaren sistemi sıfırdan inşa etmek yerine mevcut yapıyı iyileştiriyorsunuz.

Adım 2: jail.conf dosyasını değil, jail.local dosyasını düzenleyin

Fail2ban, varsayılan ayarlarını /etc/fail2ban/jail.conf içerisinde tutar. Bu dosyayı düzenlemeyin. Dosyanın kendi başlığında da uyarıldığı üzere, bir paket yükseltmesi bu dosyayı değiştirebilir ve yaptığınız değişiklikler kaybolabilir. Fail2ban dosyaları belirli bir sırada okur: önce jail.conf, ardından alfabetik sırayla jail.d/*.conf, sonra jail.local ve son olarak alfabetik sırayla jail.d/*.local okunur; en son okunan değer geçerli olur. Bu nedenle jail.local, paketle gelen defaults-debian.conf değerlerini geçersiz kılar; ancak jail.d/ dizinine eklediğiniz herhangi bir *.local dosyası, ondan sonra okunarak onu da geçersiz kılar. Hangi değerin aktif olduğunu bilmek için geçersiz kılma ayarlarınızı tek bir yerde tutun. .local dosyası size aittir ve paket yükseltmeleri bu dosyaya asla dokunmaz. Aynı kural filtreler için de geçerlidir; burada bir *.local dosyası, paketle gelen filter.d/*.conf dosyasını geçersiz kılar.

Bu nedenle, yalnızca ilgilendiğiniz birkaç ayarı geçersiz kılan küçük bir jail.local oluşturun ve hem jail.conf hem de paketle gelen jail.d/defaults-debian.conf dosyalarını referans olarak dokunulmadan bırakın.

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

sudo nano /etc/fail2ban/jail.local

Aşağıdaki içeriği ekleyin ve ignoreip satırındaki adresi kendi genel IP adresinizle değiştirin:

[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 amacı vardır:

• bantime, findtime ve maxretry politikayı belirler. Yazılımla birlikte gelen varsayılan bantime süresi yalnızca on dakikadır; bir saat daha makul bir alt sınırdır. On dakika içinde aynı adresten gelen beş başarısız deneme yasaklama ile sonuçlanır. Gerçek kullanıcılar şifrelerini bir veya iki kez yanlış girebilir; on dakikada beş hata ise bir betiğe işaret eder.
• ignoreip sizin güvenlik kemerinizdir. Bağlantı kurduğunuz genel IP adresini buraya yazın; böylece Fail2ban sizi kendi sunucunuzdan asla dışarıda bırakmaz. Değişken IP adresine sahip bir ev bağlantınız varsa, bu satırı atlamak yerine bölümün sonundaki VPN yaklaşımını tercih etmelisiniz.
• bantime.increment = true, her tekrarlanan yasaklamanın bir öncekinden daha uzun sürmesini sağlar; bir saat, ardından iki, sonra dört ve bantime.maxtime değerine kadar artar. Sürekli geri dönen adresler kademeli olarak daha uzun süre kilitli kalır.

Beyaz listeye eklenecek adresi sunucudan değil, SSH bağlantısını yaptığınız makineden öğrenin:

curl -s ifconfig.me

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

Adım 4: Yeniden başlatın ve günlüğü okuduğunu doğrulayın

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

-t, önce bir yapılandırma testi çalıştırır; bu nedenle jail.local içindeki bir yazım hatası, servisi ölü bırakmak yerine burada belirgin bir şekilde hata verir. Sağlıklı bir jail durumu şu şekilde görünür:

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:   203.0.113.66

Fail2ban'in girişlerinizi gerçekten okuduğunu kanıtlayan sayı Total failed değeridir. Bu değer sıfırdan büyükse veya başka bir makineden kasıtlı olarak hatalı giriş yaptığınızda artıyorsa, günlük okunuyor demektir ve işlem tamamlanmıştır. Eğer kaç kez hatalı giriş yaparsanız yapın değer 0 seviyesinde kalıyorsa ve ignoreip içindeki adresten test yapmadığınızdan eminseniz, aşağıdaki hata modlarına geçin.

Journal matches satırının hala sshd.service ismini taşıdığına dikkat edin. Ubuntu üzerinde SSH birimi aslında ssh.service'dir, ancak yüklü gelen filtre _COMM=sshd üzerinde de eşleşme sağlar ve 24.04 üzerindeki OpenSSH, hatalarını sshd isimli bir süreçten günlüğe kaydeder; bu nedenle eşleşme çalışır. Bu detay yalnızca daha yeni bir OpenSSH (bağlantı başına çalışan sürecin sshd-session olduğu 9.8 veya sonrası) kullanıyorsanız önemlidir; hata modları bu durumu da kapsamaktadır.

Adım 5: Gerçek bir yasaklamayı izleyin veya test etmek için bir tane tetikleyin

Gerçek yasaklamalar, halka açık herhangi bir VPS üzerinde dakikalar içinde kendiliğinden gerçekleşir. Bir yasaklamayı izlemek için log dosyasını takip edin:

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

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

2026-07-15 10:31:40,502 fail2ban.filter  [812]: INFO    [sshd] Found 203.0.113.66 - 2026-07-15 10:31:40
2026-07-15 10:31:44,118 fail2ban.actions [812]: NOTICE  [sshd] Ban 203.0.113.66

Mekanizmanın uçtan uca çalıştığını beklemek zorunda kalmadan kanıtlamak için, kendi adresiniz olmayan bir dokümantasyon adresini manuel olarak yasaklayın. 203.0.113.66, dokümantasyon için ayrılmış bir blok olan TEST-NET-3 içerisinde yer alır; bu nedenle gerçek bir sunucu veya sağlayıcınızın ağındaki özel bir adres olamaz:

sudo fail2ban-client set sshd banip 203.0.113.66

Komut 1 çıktısını verir ve adres fail2ban-client status sshd içerisindeki Banned IP list altında görünür. Şimdi bloğun güvenlik duvarında gerçekten var olduğunu doğrulayın. Ubuntu 24.04 üzerinde bu işlem iptables değil, nftables ile yapılır:

sudo nft list table inet f2b-table

203.0.113.66 adresini barındıran addr-set-sshd isimli bir küme ve bu kümedeki herhangi bir kaynaktan gelen trafiği reddeden bir f2b-chain zinciri göreceksiniz. Eğer fail2ban-client bir adresin yasaklandığını söylüyor ancak nft list içerisinde hiçbir şey görünmüyorsa, yasaklama eyleminiz güvenlik duvarınızla uyumlu değildir; hata modları bölümündeki nftables/iptables notuna bakın.

Adım 6: Kendi yasağınızı kaldırma ve kilitlendiğinizde kurtarma

Yanlışlıkla kendi IP adresinizi veya yasaklamamanız gereken bir adresi yasakladıysanız, şu komutla kaldırın:

sudo fail2ban-client set sshd unbanip 203.0.113.66

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

sudo fail2ban-client unban --all

Açık bir SSH oturumunun sizi kurtaracağına güvenmeyin: nftables yasağı, yasaklı adresten 22 numaralı porta gelen tüm paketleri (kurulu bağlantılar dahil) reddeder; bu nedenle yasak uygulandığı anda mevcut oturum donar. Kendinizi yasakladıysanız ve bir ignoreip girişiniz yoksa, yasak süresi dolana kadar kilitli kalırsınız. Bu durumda SSH üzerinden geçmeyen, sağlayıcınızın web konsolu (VNC veya seri konsol) üzerinden erişim sağlayın ve ya bantime süresinin dolmasını bekleyin ya da yasak kaldırma komutunu oradan çalıştırın.

Adım 7: Yasakların kalıcı olmasını sağlama ve tırmandırma

Fail2ban, aktif yasakları /var/lib/fail2ban/fail2ban.sqlite3 konumundaki küçük bir SQLite veritabanında tutar; böylece servis yeniden başlatıldığında veya sistem reboot edildiğinde yasaklar kaybolmaz. Zaten eklemiş olduğunuz bantime.increment satırları, her mükerrer ihlali yapan kullanıcı için cezayı yaklaşık bir saatten bir haftaya kadar ikiye katlayarak tırmandıran bir sorun haline getirir.

Bunun üzerine sistem genelinde bir "üç ihtar" politikası uygulamak için Fail2ban, kendi /var/log/fail2ban.log dosyasını izleyen ve tüm jail'ler genelinde defalarca yasaklanan adreslere uzun süreli yasaklar uygulayan bir recidive jail'i ile birlikte gelir. [DEFAULT] yapılandırmanız artık systemd arka ucunu kullandığından, bu jail'i okuması için tasarlandığı log dosyasına sabitleyin:

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

Açık bir logpath parametresi ile backend = auto kullanmak, recidive aracının düz fail2ban.log dosyasını okumaya devam etmesini sağlar. Saydığı Ban satırları aslında burada görünür; global olarak ayarladığınız systemd varsayılanı, aracı journal dosyasına yönlendirecektir ancak bu satırlar orada bulunmaz.

Adım 8: Anahtar tabanlı SSH ile eşleştirin ve daha iyisi bir VPN kullanın

Fail2ban, yalnızca anahtar tabanlı kimlik doğrulama ile birlikte kullanıldığında gerçek değerini gösterir. /etc/ssh/sshd_config.d/ altındaki bir yapılandırma dosyasında, örneğin /etc/ssh/sshd_config.d/00-hardening.conf içinde şunları ayarlayın:

PasswordAuthentication no
KbdInteractiveAuthentication no

Ardından sudo systemctl restart ssh komutunu çalıştırın. Parola girişi kapatıldığında, kaba kuvvet (brute force) saldırıları hiçbir şekilde başarılı olamaz; Fail2ban bu noktada günlük kayıtlarındaki gürültüyü azaltmak ve tarayıcıları erkenden engellemek için görev yapar. Daha da güvenli bir yöntem, SSH'yi genel internete tamamen kapatmaktır: SSH'yi kendi barındırdığınız bir WireGuard VPN arkasına alın ve 22 numaralı portu yalnızca tünel üzerinden yanıt verecek şekilde güvenlik duvarı ile kısıtlayın. Kimse erişemediği bir portu kaba kuvvet ile zorlayamaz; bu durumda Fail2ban bir ön cephe değil, bir yedek güvenlik katmanı haline gelir.

Fail2ban yalnızca SSH için değildir. Başarısız giriş denemelerini günlüğe kaydeden herhangi bir servis, bir posta sunucusu, bir nginx sitesi veya kimlik bilgisi doldurma (credential stuffing) saldırılarına açık bırakmak istemeyeceğiniz kendi barındırdığınız bir Vaultwarden parola yöneticisi için bir jail (hapishane) oluşturulabilir. Bir web uygulaması Let's Encrypt sertifikasına sahip bir nginx sitesi arkasına alındığında, SSH jail'inin journal'ı izlediği gibi, bir Fail2ban filtresini de ilgili uygulamanın erişim günlüğüne yönlendirin.

Hata modları ve karşılaşacağınız kesin ifadeler

"Have not found any log file for sshd jail" hatası ve Fail2ban'in başlamaması. Bu, eski bir auth.log sorunudur. Ubuntu 24.04 üzerinde bu hatayla yalnızca /var/log/auth.log bulunmadığında (rsyslog içermeyen minimal bir imaj veya container gibi) ve journal okunmadığında karşılaşırsınız: defaults-debian.conf içermeyen bir pip kurulumu, journal'ı olmayan bir container veya jail.local içine yapıştırdığınız hatalı bir backend = auto. /var/log/auth.log içermeyen bir dosya arka ucunda, sshd jail'i günlük dosyasını bulamaz ve tüm daemon durur. fail2ban.log şunu gösterir:

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

Bu hata ölümcül olduğu için servis asla ayağa kalkmaz ve fail2ban-client status ardından aşağı yönlü belirtiyi bildirir:

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

"socket path" satırı Fail2ban'in bozuk olduğu anlamına gelmez; bir jail günlük dosyasını bulamadığı için servisin hiç başlamadığı anlamına gelir. Ubuntu paketinin sizin yerinize zaten yaptığı gibi [DEFAULT] içinde backend = systemd ayarını yapmak, her iki mesajı da aynı anda düzeltir.

Jail aktif ancak Total failed hiç artmıyor. Daemon çalışıyor ve journal okunuyor, ancak gerçek başarısızlıklar journalctl -u ssh içinde birikmesine rağmen sayaç 0 değerinde kalıyor. İlk olarak bariz olanı eleyin: ignoreip içinde listelenen bir adresten test yapıyorsunuz, bu nedenle kendi başarısızlıklarınız tasarım gereği muaf tutuluyor. Eğer sorun bu değilse, bağlantı başına çalışan işçinin sshd-session olduğu (9.8 ve sonrası) bir OpenSSH sürümündesiniz demektir; bu sürümde journal _COMM değeri sshd değil, sshd-session şeklindedir, bu yüzden varsayılan eşleşme bunu yakalayamaz. [sshd] bloğundaki eşleşmeyi genişletin:

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

Yeniden başlatın, ignoreip içinde olmayan bir adresten kasıtlı olarak hatalı giriş yapın ve Total failed değerinin nihayet arttığını doğrulayın.

Kendinizi banladınız: Connection refused. Kendi adresinizi ignoreip dışında bıraktınız, birkaç hatalı giriş denediniz ve şimdi:

ssh: connect to host 10.0.0.10 port 22: Connection refused

Sessiz bir zaman aşımı yerine bağlantının reddedilmesi, nftables aksiyonunun varsayılan reject kararının sizin üzerinizde çalışmasından kaynaklanır. 6. Adım'da belirtildiği gibi düzeltin: banlanmamış farklı bir adresten veya sağlayıcı konsolundan banı kaldırın; banlanan adresten açık olan bir oturum da donacaktır. Ardından, bunun tekrar yaşanmaması için adresinizi ignoreip içine ekleyin.

Fail2ban bir adresin banlandığını söylüyor ancak bağlantı hala kurulabiliyor. status sshd içindeki sayaç artıyor ancak adres hala 22 numaralı porta ulaşabiliyor. Bu, ban aksiyonu ile güvenlik duvarı arasındaki bir uyumsuzluktur. Ubuntu 24.04 üzerinde bu durum, neredeyse her zaman iptables katmanı olmayan bir sistemde, çalışan banaction = nftables ayarını eski bir rehberden kopyalanan banaction = iptables-multiport ile geçersiz kıldığınız anlamına gelir. fail2ban.log şunu gösterir:

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

Bu geçersiz kılma ayarını silin ve paketle gelen nftables aksiyonunun kalmasını sağlayın. Eğer güvenlik duvarını tamamen ufw üzerinden yönetiyorsanız ve banların orada görünmesini istiyorsanız, [DEFAULT] içinde banaction = ufw ayarını yapın. Yeniden başlatın ve kuralın sudo nft list ruleset | grep f2b ile göründüğünü doğrulayın.

jail.local düzenlendikten sonra Fail2ban başlamıyor. Bir yazım hatası, hatalı bir başlık veya yanlış bir zaman değeri, servisin ayağa kalkmasını engeller. Fail2ban'den çalışmadan önce yapılandırmayı kontrol etmesini isteyin:

sudo fail2ban-client -t

Bu komut, sorunun olduğu dosyayı ve jail'i (örneğin Errors in jail 'sshd'. Skipping...) belirtir; böylece tahmin yürütmek yerine kaynağı düzeltirsiniz.

FAQ

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

Evet. Paket, /etc/fail2ban/jail.d/defaults-debian.conf dosyasını içerir; bu dosya sshd jail'ini etkinleştirir, imajınızın /var/log/auth.log dosyasına yazıp yazmadığına bakılmaksızın systemd günlüğünü okuması için backend = systemd ayarını yapılandırır ve yasaklamaların Ubuntu'nun gerçek güvenlik duvarı üzerinden uygulanması için banaction = nftables ayarını yapar. Standart bir apt install fail2ban kurulumu, SSH'i ilk açılıştan itibaren korur. Bunu sudo fail2ban-client status sshd ile doğrulayabilir ve sıfır olmayan bir Total failed değeri olup olmadığını kontrol edebilirsiniz.

Fail2ban sunucumda neden hiçbir şeyi yasaklamıyor?

Yaygın üç nedeni sırasıyla eleyin. Tasarım gereği muaf tutulan ignoreip içindeki bir adresten test yapıyor olabilirsiniz. Eski bir kılavuzdan backend = auto içeriğini jail.local dosyasına yapıştırarak çalışan varsayılan ayarları geçersiz kılmış olabilirsiniz; bu durum, rsyslog dosyası bulunmayan ve dolayısıyla auth.log içermeyen bir imajda SSH yasaklamasını bozar. Ya da hiç systemd günlüğü bulunmayan bir container içinde olabilirsiniz. fail2ban-client status sshd içindeki Total failed değerini kontrol edin: journalctl -u ssh gerçek başarısızlıkları gösterirken bu değer hiç artmıyorsa, jail yanlış yeri okuyor demektir.

Kendi IP adresimin yasağını nasıl kaldırırım?

Başarılı olduğunda 1 dönen sudo fail2ban-client set sshd unbanip YOUR.IP.HERE komutunu veya tüm yasakları 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, adresinizden 22 numaralı porta gelen her paketi reddettiği için halihazırda açık olan bir oturum bile çalışmayı durdurur. Ardından, durumun tekrarlanmaması için adresinizi ignoreip içine ekleyin.

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

jail.conf, Fail2ban'in yukarı akış varsayılanlarını tutar ve paket yükseltmesiyle değiştirilebilir, bu nedenle orada yapılan her düzenleme risk altındadır. Debian/Ubuntu paketi, kendi ayarlarını jail.d/defaults-debian.conf aracılığıyla bunların üzerine katmanlar halinde ekler. Sizin değişiklikleriniz, her ikisinden sonra okunan, onlara üstün gelen ve yükseltmelerin asla dokunmadığı jail.local dosyasına aittir. Yalnızca jail.d/ içindeki bir *.local dosyası daha sonra okunur, bu yüzden orada başıboş dosyalar bırakmayın. jail.conf dosyasını salt okunur bir referans olarak bırakın.

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

Hayır. Fail2ban, tek bir adresten gelen tekrarlayan başarısızlıkları hız sınırına tabi tutar; her adresin eşik değerin altında kaldığı yavaş ve dağıtık tahminlere karşı hiçbir şey yapamaz. Yalnızca anahtar tabanlı kimlik doğrulama (PasswordAuthentication no), parola tahminini doğrudan imkansız hale getirir; Fail2ban ise bu noktada günlük gürültüsünü azaltır ve tarayıcıları erkenden uzaklaştırır. Her ikisini de kullanın ve ideal olarak SSH'i genel internete tamamen kapatın.