Bu yazıda SSH kayıtlarını Fail2Ban filtresiyle kontrol ediyor, başarısız denemelerin jail sayacına nasıl yansıdığını gösteriyorum. Deney, sentetik günlük ve firewall kullanmayan dummy eylemiyle sınırlı. Sunucunun tüm güvenliğini veya gerçek ağ engellemesini doğruladığım anlamına gelmiyor.
Fail2Ban bir zaman aralığında filtreye uyan kayıtları sayıyor; eşik aşıldığında yapılandırılmış eylemi çalıştırıyor. Bu, tekrar eden giriş denemelerini sınırlamak için yararlı. Güncellemelerin ve güçlü kimlik doğrulamanın yerine geçmiyor. İlk iki soru şu: Başarısız giriş kaydı nerede tutuluyor, hangi filtre bu kaydı okuyacak?
Test edilen ortam
7 Ekim 2026 UTC'de Docker Engine 29.8.0 üzerinde Linux/arm64 konteynerde denedim: Debian GNU/Linux 13 (trixie, imaj metadata değeri 13.7), Debian Fail2Ban paketi 1.1.0-8, Fail2Ban v1.1.0, sistem Python 3.13.5. Gerçek SSH servisi, systemd journal, üretim sunucusu ve firewall üzerinden bağlantı engellemesi test edilmedi.
Örnek paketi indirin, fail2ban-validation dizinine geçin ve kendi dizininde çalıştırın:
docker compose --project-name example-fail2ban-validation build
docker compose --project-name example-fail2ban-validation run --rm lab
Build resmi Debian paketlerini indirir. Test konteyneri ağ bağlantısı ve host mount olmadan, UID 65534 ile çalışır; bütün Linux capabilities kaldırılır. Geçici yapılandırmalar ve sentetik loglar yalnız konteynerin /tmp alanındadır. Gerçek hesap, parola veya üretim logu gerekmez.
Önce SSH filtresini sınamak
Lab üç Failed password ve bir Accepted publickey satırı üretip şu kontrolü çalıştırır:
fail2ban-regex -c /tmp/fail2ban-validation/config /tmp/fail2ban-validation/ssh-fixture.log 'sshd[mode=normal]'
İzole çalıştırmada alınan kısa çıktı:
Lines: 4 lines, 1 ignored, 3 matched, 0 missed
Üç başarısız parola kaydı eşleşti; başarılı anahtarla giriş açıkça görmezden gelindi. Buradaki ignored ile missed aynı şey değil. Bu sonuç yalnız bu dört sentetik satırı kapsar. Gerçek log biçiminin de eşleştiğini ayrıca görmek gerekir. Normal modun davranışı Fail2Ban 1.1.0 SSH filtresinde tanımlanır.
Jail ve eylem ayrı kontroller
Lab'ın SSH jail'i, host'un /etc/fail2ban dosyasını değiştirmeden geçici yapılandırmada açılır:
[sshd-lab]
enabled = true
filter = sshd[mode=normal]
backend = polling
logpath = /tmp/fail2ban-validation/auth.log
port = 22
findtime = 10m
maxretry = 5
bantime = 10m
action = dummy[target=/tmp/fail2ban-validation/sshd-lab.dummy]
Beş uygun hata on dakikada oluşursa on dakikalık ban kararı alınır. port değeri, port kullanan firewall eylemlerinde hedef portu belirler; log kaynağının yerine geçmez. Bu lab'ın dummy eylemi port veya firewall kuralı kullanmaz.
Lab, aynı geçici config/socket/pid yollarıyla fail2ban-client -t, start, ping ve status sshd-lab komutlarını çalıştırır. Başarılı deneyde:
OK: configuration test is successful
Server ready
Server replied: pong
Jail önce sıfır sayaç gösterdi. Ardından aynı dokümantasyon IP'sinden beş hata yazıldığında:
Total failed: 5
Currently banned: 1
Total banned: 1
Banned IP list: 192.0.2.10
Bu, Fail2Ban sunucusunun kayıtları okuduğunu ve ban kararını tuttuğunu gösterir. Resmi dummy eylemi yalnız geçici dosyaya +192.0.2.10 yazdı. Lab bu kaydı, kontrol IP'sinin ban edilmediğini ve unbanip sonrasında ban durumunun temizlendiğini de doğruladı. Herhangi bir ağ bağlantısının kesildiğini test etmedim.
| Kontrol | Gösterdiği sonuç |
|---|---|
fail2ban-regex |
Verilen kayıtların filtreye uyup uymadığı |
Yapılandırma testi, ping, jail durumu |
Ayarın okunabilmesi, sunucunun çalışması ve sayaçlar |
| Dummy eylem kaydı | Yapılandırılmış dosya eyleminin çalışması |
| Ayrı istemciden gerçek bağlantı | Firewall ve trafik yolunun sonucu; bu deneyde test edilmedi |
İstemci seçenekleri resmi 1.1.0 kılavuzunda bulunuyor. Servisin çalışması doğru logu izlediğini, ban listesi de hedefe erişimin kesildiğini tek başına kanıtlamaz.
Kendi sunucusuna uyarlarken
Dağıtımın varsayılan dosyasını kopyalamak yerine /etc/fail2ban/jail.d/sshd.local gibi küçük bir dosyada yalnız değiştirilen ayarlar tutulabilir. Önce dağıtımın SSH log kaynağı, kullanılan backend ve seçilen firewall eylemi doğrulanmalı. Dosya kaydıyla systemd journal aynı yöntemle okunmaz: systemd backend'inde logpath kullanmak geçerli değildir; journalmatch ayrı kontrol edilir. Bunlar sürümlü resmi jail yapılandırmasında açıklanır. Bu yazıdaki polling deneyi journal doğrulaması değildir.
Eşleşme yoksa önce doğru dosya, zaman damgası ve filtre modu incelenir. Jail yoksa etkinleştirme ve yapılandırma testi kontrol edilir. Ban sayısı artıp erişim sürüyorsa kullanılan eylem ve gerçek trafik yolu araştırılır. Bu lab'da erişimin kesilmemesi beklenir; dummy firewall kullanmaz.
SSH ayarları veya gerçek ban eylemi denenirken mevcut oturum korunmalı ve sunucuya ulaşmak için ikinci yol hazır olmalı. SSH portunu değiştirmek tarama gürültüsünü azaltabilir; kimlik doğrulamayı güçlendirmez. Anahtarla giriş ve erişim ayarlarını değiştirmeden önce yeni bağlantıyı denemek gerekir. Ubuntu'nun OpenSSH belgesi erişimi kaybetmeden yapılacak kontrolleri anlatır; Ubuntu ortamı bu deneyde test edilmedi.
