fail2ban Kurulumu ve Yapılandırması (Ubuntu 24.04)

fail2ban, bir sunucunun kimlik doğrulama kayıtlarını izleyen ve belirli sayıda başarısız denemeden sonra o denemelerin geldiği adresi bir süre engelleyen bir araçtır. İnternete açık bir SSH portu, siz hiçbir şey yapmasanız da gün boyu otomatik tarayıcılardan ve parola deneyen botlardan deneme alır.

Bir otoparkın giriş bariyerini düşünün. Bariyerin kendisi kimseyi tanımaz; açılır ya da kapanır, o kadar. Kimin gireceğine plakaları okuyan kamera ve arkasındaki kayıt sistemi karar verir. Aynı plaka kısa sürede üst üste geçersiz bir abonelik kartı okutursa sistem bariyere “bu plakayı bir süre içeri alma” talimatı verir. Israr eden plakanın bekleme süresi uzar; personel plakaları ise listede olduğu için hiç durdurulmaz.

fail2ban bu kayıt sistemidir. Kaydı okur ve güvenlik duvarına talimat verir, bariyeri indiren ise nftables’tır. Benzetme tek bir yerde kopar. Kamera plakayı anında okur; fail2ban ise log satırı yazıldıktan sonra okur, bu yüzden eşiğe kadar olan denemeler her zaman sunucuya ulaşır. Kayda düşmeyen bir başarısızlık ise fail2ban için hiç yaşanmamış sayılır.

fail2ban’i Ubuntu 24.04 üzerinde kurup yapılandırdım, sonra lab sunucumuzda gerçek başarısız girişler üreterek davranışını ölçtüm. Banın kaçıncı denemede düştüğünü, ne kadar sürdüğünü ve tekrar eden kaynağa ne olduğunu aşağıda ölçüm çıktılarıyla göreceksiniz.

Bu makale Ubuntu Server rehberimizin sertleştirme bölümünü derinleştiriyor ve siber güvenlik önlemleri rehberimizdeki kaynak başına deneme sınırını Linux tarafında kuruyor. Sunucu güvenliğini hizmet olarak nasıl yürüttüğümüzü BT sistem yönetimi sayfamızda anlattık.

fail2ban’in Arkasındaki Prensip: Başarısızlığı Say, Kaynağı Beklet

fail2ban’i “SSH’ı koruyan program” diye anlatmak onu bir kurulum reçetesine indirger ve asıl fikri kaçırır. Programın arkasında tek bir kural durur: belirli sayıda başarısız denemeden sonra, o denemelerin geldiği kaynağı bir süre beklet. Bu kuralın SSH ile bir ilgisi yoktur. Aynı kural bir web sitesinin giriş formunda, bir mail sunucusunda ya da bir yönetim panelinde de geçerlidir. Değişen tek şey, hangi kayıt dosyasının okunduğu ve hangi başarısızlık deseninin sayıldığıdır.

İnternette okuduğum fail2ban makalelerinin çoğu SSH örneğinde kalıyor ve aracı bir komut listesi olarak sunuyor. Oysa aracı gerçekten anlamak, hangi kaydı okuduğunu ve güvenlik duvarına nasıl bağlandığını görmektir. Bunu kavradığınızda aynı yapılandırmayı nginx, postfix ya da WordPress girişi için kurmak farklı bir program öğrenmek değil, aynı kuralı başka bir loga yöneltmektir.

fail2ban bu kuralın her bir uygulamasına jail adını verir. Kelime İngilizcede hapis demektir; bu yazıda çevirmeden kullanıyorum. Bir jail dört parçayı birbirine bağlar:

• Log kaynağı, fail2ban’in hangi kaydı okuyacağını belirler.
• Filtre, o kayıtta hangi satırın başarısızlık sayılacağını belirleyen düzenli ifadedir.
• Eşik (maxretry ve findtime), kaç başarısızlıkta banın başlayacağını belirler.
• Eylem (banaction), banı güvenlik duvarında uygular.

Farklı yüzeylerde değişen yalnız okunan kayıt ve tanınan desendir:

Dört satırda da kural aynıdır. Bariyer ve kamera da aynı kalır; değişen yalnız kameranın baktığı ekrandır.

Bu yazının kapsamı prensibin Linux ve SSH ayağıdır. Saldırının kendisini, eşiği ve hesap kilitlemeyi burada yeniden tanımlamayacağım, çünkü onları brute force rehberinde ölçtüm. Buradaki iş, o saldırının Linux tarafındaki hazır cevabını kurmak ve sınırlarını görmektir.

fail2ban Kurulumu: Paket Kuruldu, Jail Açık mı?

Kurulum tek komuttur:

sudo apt install fail2ban

Paket kurulduğu anda servis de başlar ve açılışta otomatik başlayacak biçimde etkinleşir; ayrı bir systemctl enable adımına gerek yoktur. İsterseniz doğrulayın:

systemctl is-enabled fail2ban
systemctl is-active fail2ban

İkisi de enabled ve active döner. İnternette okuduğum makalelerin çoğu bu noktada jail.local dosyasına logpath = /var/log/auth.log satırını yazdırır. Ubuntu 24.04’te bu adım gereksizdir ve fail2ban’in gerçekte neyi okuduğunu gizler. Bunu kurulumdan hemen sonra makineye sorarak görebilirsiniz.

Varsayılan Hâli Makineden Okuyalım

fail2ban kurulur kurulmaz, hiçbir ayar yapmadan, hangi jail’lerin çalıştığını sorduğumda makinenin verdiği cevap şuydu:

sudo fail2ban-client status

Status
|- Number of jail:      1
`- Jail list:   sshd

Yani sshd jail’i kurulumla birlikte açık geliyor. Bunu ben açmadım; paket /etc/fail2ban/jail.d/defaults-debian.conf dosyasına [sshd] enabled = true yazıyor. Şimdi bu jail’e daha yakından bakalım:

sudo fail2ban-client status sshd

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 0
   `- Banned IP list:

Kritik satır Journal matches. fail2ban burada bir dosya değil, systemd journal’ını okuyor: _SYSTEMD_UNIT=sshd.service. Aynı dosya backend = systemd ayarını da getirdiği için fail2ban /var/log/auth.log’a hiç bakmıyor. Bu sunucuda rsyslog da çalıştığından auth.log mevcut, ama fail2ban onu okumuyor. logpath satırı ekleyen bir makaleyi izlerseniz var olmayan bir soruna çözüm yazmış olursunuz; jail zaten çalışır ve journal’ı okur.

Varsayılanlar: bantime, findtime, maxretry

fail2ban’in sayma davranışını üç sayı belirler. Üçünü de dosyadan tahmin etmek yerine makineden okumak gerekir:

sudo fail2ban-client get sshd bantime
sudo fail2ban-client get sshd findtime
sudo fail2ban-client get sshd maxretry

Ölçtüğüm kurulumda sırasıyla 600, 600 ve 5 döndü. Anlamları şöyle:

• findtime (600 sn) sayacın baktığı zaman penceresidir. Başarısız denemeler yalnız bu pencere içinde birikir.
• maxretry (5), pencere içinde banı başlatan başarısızlık sayısıdır.
• bantime (600 sn) banın ne kadar süreceğini belirler.

Buradaki incelik şudur: “beş deneme hakkı” cümlesi eksiktir, doğrusu “findtime penceresi içinde beş başarısızlık”tır. Pencere kayan bir penceredir, bu yüzden yavaş yayılan denemeler hiç birikmez; bunun sonucunu aşağıda, fail2ban’in işe yaramadığı yerlerde göreceksiniz.

jail.local: jail.conf’a Neden Dokunmuyoruz?

fail2ban’in ana yapılandırma dosyası /etc/fail2ban/jail.conf’tur, ama oraya elle bir şey yazmak hatadır, çünkü dosya bir sonraki paket güncellemesinde değişebilir. Dosyanın başındaki uyarı bunu açıkça söylüyor:

# YOU SHOULD NOT MODIFY THIS FILE.
# It will probably be overwritten or improved in a distribution update.

Kalıcı ayar jail.local dosyasına ya da jail.d/ altındaki bir dosyaya yazılır; fail2ban ikisini de okur ve .local değerleri .conf’u geçersiz kılar.

Bütün jail’ler için geçerli bir taban ile sshd’ye özel bir ayarı ayıran sade bir jail.local şöyle görünür:

[DEFAULT]
bantime = 600
findtime = 600
maxretry = 5
bantime.increment = true
bantime.maxtime = 1w
ignoreip = 127.0.0.1/8 ::1 192.168.1.115

[sshd]
enabled = true

[DEFAULT] bölümü bütün jail’lere iner; [sshd] yalnız o jail’i açar. İlk üç satır ölçtüğüm varsayılanları açıkça yazar. bantime.increment tekrar eden kaynağın banını uzatır, bantime.maxtime bu uzamayı bir haftada durdurur, ignoreip ise listedeki adresleri hiç banlamaz. 192.168.1.115 benim yönetim iş istasyonumun adresidir; bu satırı yazmazsanız ne olduğunu kendini kilitleme tuzağı bölümünde anlattım. Değişikliği uygulamak için:

sudo fail2ban-client reload

Ban Anında Ne Oluyor? nftables ve iptables

fail2ban bir kaynağı banladığında kararı uygulayan şey güvenlik duvarıdır. Ubuntu 24.04’te bu iş iptables ile değil nftables ile yapılır, çünkü paket banaction = nftables ayarıyla geliyor.

fail2ban’in ban olmadan hiçbir kural bırakmaması ilginçtir. Kurulumdan sonra, henüz kimse banlanmamışken güvenlik duvarını sorduğumda çıktı boştu. İlk ban düştüğü anda ise nftables içinde şu yapı belirdi:

sudo nft list ruleset

table inet f2b-table {
    set addr-set-sshd {
        type ipv4_addr
        elements = { 192.168.1.15 }
    }

    chain f2b-chain {
        type filter hook input priority filter - 1; policy accept;
        tcp dport 22 ip saddr @addr-set-sshd reject with icmp port-unreachable
    }
}

Kümedeki 192.168.1.15, fail2ban’in çalıştığı lab sunucusunun (ntp01) kendi adresidir. Denemeleri sunucunun içinden yine kendisine yaptığım için banlanan kaynak da o oldu; jail.local örneğindeki 192.168.1.115 ise ayrı bir makine, benim yönetim iş istasyonumdur. Denemeleri nasıl ürettiğimi bir sonraki bölümde anlatıyorum.

Çıktıda iki ayrıntı önemli:

1. Banlı adresler bir kümede durur. fail2ban adresleri bir kümede (addr-set-sshd) tutar ve kuralı bu kümeye yöneltir. Ban ekleyip kaldırmak kuralı değiştirmek değil, kümeye adres ekleyip çıkarmaktır.
2. Süre dolunca yalnız adres silinir. Ban süresi dolduğunda tablo ve zincir yerinde kalır, yalnız kümeden adres silinir.

İkincisi, kaynak sessizce düşürülmüyor (drop), reject with icmp port-unreachable ile geri çevriliyor, bu yüzden banlı istemci “Connection refused” görür. iptables komutları anlatan eski bir makaleyi izlerseniz bu sistemde çalışan kuralı hiç göremezsiniz, çünkü kural nftables tarafındadır.

Peki UFW açıksa durum değişir mi? Ölçtüğüm sunucuda UFW kapalıydı, bu yüzden aşağıdaki cevap ölçüm değil mekanizmadır. Ubuntu 24.04’te UFW’nin kuralları da iptables-nft üzerinden nftables’a yazılır, yani iki taraf aynı güvenlik duvarında yan yana durur. nftables’ta bir zincirin verdiği accept kararı paketi yalnız o zincirden geçirir ve aynı noktadaki diğer zincirler yine değerlendirilir; reject ise kesindir. Bu yüzden UFW bir kaynağa izin verse bile fail2ban’in kümesindeki adres geçemez.

fail2ban Kaçıncı Denemede Banlıyor, Ban Ne Kadar Sürüyor?

Buraya kadarki her şeyi ölçmek için kendi lab sunucumuzda gerçek başarısız girişler ürettim. Ortam ntp01, bir Ubuntu 24.04 sunucusu. Deneme kaynağı olarak sunucunun kendi adresini (192.168.1.15) kullandım ve yönetim iş istasyonumu (192.168.1.115) ignoreip’e koydum, ki ölçüm yaparken kendi bağlantımı kesmeyeyim. bantime değerini gözlemi kolaylaştırmak için 60 saniyeye çektim.

Denemeleri sshpass ile ürettim (sudo apt install sshpass). Ölçüm betiğinin çekirdeği, var olmayan bir kullanıcı adıyla parola girişini zorlayan tek tek SSH bağlantılarıdır ve betik her bağlantıdan sonra fail2ban-client status sshd ile sayacı okur:

for i in $(seq 1 7); do
  sshpass -p "yanlis-$i" ssh -o PreferredAuthentications=password \
    -o PubkeyAuthentication=no -o StrictHostKeyChecking=no \
    -o ConnectTimeout=5 gecersiz$i@192.168.1.15 exit
done

Bu döngüyü yalnız kendi sunucunuzda çalıştırın; başkasının sunucusunda aynı komut bir saldırıdır.

maxretry 5 görünce akla gelen cevap “beşinci denemede” olur. Ölçümde ban üçüncü bağlantı denemesinde düştü. İlk blok ölçüm betiğimin kendi çıktısı, ikincisi ban anında fail2ban-client status sshd komutunun verdiği cevaptır:

deneme 1 @ 22:32:39.136  -> failed=1 banned=0
deneme 2 @ 22:32:43.034  -> failed=1 banned=0
deneme 3 @ 22:32:45.006  -> failed=1 banned=1
>>> BAN deneme 3 sonrasi, saat 22:32:47.770

Status for the jail: sshd
|- Filter
|  |- Currently failed: 1
|  |- Total failed:     6
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 1
   |- Total banned:     1
   `- Banned IP list:   192.168.1.15

Okurken iki satıra dikkat edin:

• failed=1 ve Currently failed: 1 başarısızlık sayısı değil, o an sayacı dolu olan adres sayısıdır. Tek kaynaktan denediğim için hep 1 kaldı.
• Total failed: 6 sayılan başarısızlık satırlarının toplamıdır. Üç denemeden altı satır çıktı.

Neden beş değil de üç? Çünkü fail2ban bağlantı değil, log satırı sayıyor. Var olmayan bir kullanıcı adıyla yapılan bir SSH denemesi journal’a şu satırları yazıyor:

Sep 22 22:38:17 ntp01 sshd[4081]: Invalid user pwtest1 from 192.168.1.15 port 51648
Sep 22 22:38:19 ntp01 sshd[4081]: Failed password for invalid user pwtest1 from 192.168.1.15 port 51648 ssh2
Sep 22 22:38:19 ntp01 sshd[4081]: Connection closed by invalid user pwtest1 192.168.1.15 port 51648 [preauth]

İlk iki satır filtreye takılır, üçüncüsü sayılmaz. Deneme başına iki satır, üç denemede altı satır eder ve beş satırlık eşik üçüncü denemenin içinde dolar. Bu yüzden “beş deneme” ifadesi bile yanıltıcıdır; sayılan şey denemeler değil, logunuza düşen satırlardır.

Var olan bir kullanıcı adıyla yanlış parola denediğimde her deneme journal’a yalnız tek satır yazdı (Failed password for sistemkusu from 192.168.1.15 port 38476 ssh2), çünkü kullanıcı geçerli olduğu için Invalid user satırı oluşmuyor. Ayrı bir turda sayacı deneme deneme izlediğimde her deneme sayacı tam bir artırdı ve ban, sayaç beşe ulaştığı anda düştü.

Yani eşik var olmayan kullanıcıda üçüncü denemede, var olan kullanıcıda beşinci denemede dolar. İnternette okuduğum makalelerde bu ayrıma rastlamadım.

Ban düştükten sonra süreyi ikinci ölçüm turunda fail2ban’in kendi logundan okudum. Ban 00:30:16,845’te uygulandı ve 00:31:16,921’de kalktı, yani bantime = 60 ile 60,08 saniye sürdü. Süre dolunca nftables kümesi boşaldı ve kaynak yeniden bağlanabilir hâle geldi.

Test yapan herkesi şaşırtabilecek bir davranış daha var. fail2ban her yeniden başladığında journal’ın son findtime kadarlık bölümünü yeniden okuyor ve o penceredeki eski başarısızlıkları geri sayıyor. Servisi tazeledikten sonra sayacın 33 ve 41 gibi değerlerle dolu geldiğini gördüm, bu yüzden birkaç deneme daha yapmadan ban düşebilir. Bu bir hata değil tasarımdır, çünkü fail2ban servis kapalıyken yapılan denemeleri de saymak ister. Temiz bir ölçüm için findtime penceresinin geçmesini beklemek gerekir.

Ban durumunu her an aynı fail2ban-client status sshd komutuyla sorabilirsiniz; Banned IP list satırı o an engelli kaynakları verir. Bir adresi süresi dolmadan elle serbest bırakmak (unban) için:

sudo fail2ban-client set sshd unbanip 192.168.1.15

bantime.increment ve recidive: Uzayan Ban Süresi

Sabit bir ban süresi ısrarlı bir kaynağa karşı zayıftır, çünkü süre dolunca saldırgan geri döner ve döngü baştan başlar. fail2ban’in cevabı, bariyerin ısrarcıya karşı beklemeyi uzatmasıdır. bantime.increment = true açıkken aynı kaynaktan üç kez ban tetikledim ve hiçbirini elle kaldırmadım, her banın süresinin kendiliğinden dolmasını bekledim. fail2ban’in kendi logu (/var/log/fail2ban.log) şunları yazdı:

2026-09-23 00:30:16,845 fail2ban.actions        [5651]: NOTICE  [sshd] Ban 192.168.1.15
2026-09-23 00:31:16,921 fail2ban.actions        [5651]: NOTICE  [sshd] Unban 192.168.1.15
2026-09-23 00:31:23,194 fail2ban.observer       [5651]: INFO    [sshd] Found 192.168.1.15, bad - 2026-09-23 00:31:22, 1 # -> 2.0
2026-09-23 00:31:35,552 fail2ban.actions        [5651]: NOTICE  [sshd] Ban 192.168.1.15
2026-09-23 00:31:35,556 fail2ban.observer       [5651]: NOTICE  [sshd] Increase Ban 192.168.1.15 (2 # 2m -> 2026-09-23 00:33:34)
2026-09-23 00:33:35,617 fail2ban.actions        [5651]: NOTICE  [sshd] Unban 192.168.1.15
2026-09-23 00:33:40,353 fail2ban.observer       [5651]: INFO    [sshd] Found 192.168.1.15, bad - 2026-09-23 00:33:40, 2 # -> 3.0
2026-09-23 00:33:42,837 fail2ban.actions        [5651]: NOTICE  [sshd] Ban 192.168.1.15
2026-09-23 00:33:42,838 fail2ban.observer       [5651]: NOTICE  [sshd] Increase Ban 192.168.1.15 (3 # 4m -> 2026-09-23 00:37:42)

Dökümde üç şey okunur:

1. Süre katlanıyor. İlk ban 60 saniye sürdü, ikincisi 2 dakika (2 # 2m), üçüncüsü 4 dakika (3 # 4m). jail.conf’taki varsayılan formül (ban.Time * (1<<(ban.Count if ban.Count<20 else 20)) * banFactor) her yeni banda süreyi ikiye katlar.
2. Tekrar edenin eşiği fiilen düşüyor. bad satırları, daha önce banlanmış kaynağın her başarısızlığının daha ağır sayıldığını gösteriyor: ikinci banda iki (1 # -> 2.0), üçüncüsünde üç (2 # -> 3.0). Bu yüzden ikinci ban üçüncü denemede, üçüncü ban ilk denemede düştü.
3. Banlar kendiliğinden kalktı. İlk denememde her banı unbanip ile elle kaldırdığımda dört turda bir kez bile Increase Ban satırı çıkmadı. Uzayan beklemeyi görmek istiyorsanız banın süresinin dolmasını bekleyin.

Bu, brute force rehberinde hesap tarafında anlattığımız “kilit yerine uzayan bekleme” fikrinin Linux karşılığıdır. Eşiği ilk aşan meşru kullanıcı kısa bir süre bekler, ısrarla dönen bir bot ise her seferinde hem daha çabuk hem daha uzun süre dışarıda kalır.

Aynı fikrin bir üst katmanı recidive jail’idir. Bu jail SSH loguna değil, fail2ban’in kendi loguna bakar, yani bir bandan çıkıp yeniden banlanan kaynakları görür ve onlara çok daha uzun bir ban verir. jail.conf’taki tanımına göre bir günlük pencerede (findtime = 1d) yeniden banlanan kaynağı bir hafta (bantime = 1w) engeller. Paketle birlikte tanımlı gelir ama kapalıdır.

Ubuntu 24.04’te yalnız enabled = true yazarak açılan recidive hiçbir şey saymaz. Ölçtüğüm sunucuda son bir gün içinde birden çok ban olduğu hâlde recidive Total failed: 0 gösterdi. Sebebi fail2ban-client status recidive çıktısındaki kaynak satırında duruyor:

`- Journal matches:	_SYSTEMD_UNIT=fail2ban.service PRIORITY=5

Paketin getirdiği backend = systemd yüzünden recidive fail2ban’in mesajlarını journal’da arıyor, oysa fail2ban logunu fail2ban.conf’taki logtarget ayarıyla /var/log/fail2ban.log dosyasına yazıyor. Recidive’e dosyayı okumasını söylemek gerekir:

[recidive]
enabled = true
backend = auto

Bu iki satırdan sonra recidive kaynak olarak File list: /var/log/fail2ban.log gösterdi, son bir gündeki beş banı buldu ve kaynağı hemen banladı. nftables’a eklenen kural port taşımıyor:

meta l4proto tcp ip saddr @addr-set-recidive reject with icmp port-unreachable

Yani recidive’in banı SSH ile sınırlı değildir, sunucunun bütün TCP portlarını kapatır. Açmadan önce bunu hesaba katın, çünkü yanlışlıkla banlanan bir yönetim istasyonu o hafta sunucunun hiçbir TCP servisine ulaşamaz.

fail2ban Kaynak Başına mı, Hesap Başına mı Sayar?

Burası fail2ban’i hesap kilitlemeden ayıran en önemli noktadır ve iki mekanizmayı karıştırmak yanlış bir güvenlik hissi verir.

Brute force rehberinde ölçtüğüm gibi, Active Directory hesap başına sayar. Bir saldırgan tek bir parolayı on iki farklı hesapta denediğinde hiçbir hesap eşiğe takılmaz, çünkü her hesabın sayacı ayrıdır. Password spraying’in kilitlemeyi neden atlattığının cevabı budur.

fail2ban ise kaynak (IP) başına sayar. Ölçüm sırasında denemelerimin her biri farklı bir kullanıcı adı kullandı, ama hepsi aynı adresten geldiği için sayaç o tek adreste birikti ve o adres banlandı. AD “Hangi hesaba saldırılıyor?” diye sorar, fail2ban ise “Kim saldırıyor?” diye. Aynı kaynaktan yüz farklı kullanıcı adı denenmesi fail2ban için tek bir saldırgandır ve eşiği hızla doldurur.

Bu ayrım ikisinin neden birbirini tamamladığını da açıklar. fail2ban tek bir gürültülü kaynağı susturmakta iyidir, hesap kilitleme ise dağıtık bir denemede tek bir hesabı korumakta. Biri diğerinin yerini tutmaz.

fail2ban Nerede İşe Yaramaz?

Dürüst bir rehber aracın sınırını da yazar. fail2ban üç durumda ya hiç devreye girmez ya da beklediğiniz korumayı vermez. Üçü de girişteki ayrımdan doğar, çünkü fail2ban yalnız filtresinin saydığı, eşiği dolduracak hızda gelen ve tek kaynakta yığılan başarısızlığı görür.

Şifreyle giriş kapalıysa gerçek kullanıcı adları görünmez olur. PasswordAuthentication no ayarlıyken iki seri deneme yaptım. Var olan bir kullanıcı adıyla yapılan altı denemede sayaç sıfırda kaldı, çünkü sshd bu durumda yalnız bir Connection closed by authenticating user ... [preauth] satırı yazıyor ve varsayılan filtre bu satırı saymıyor. Var olmayan kullanıcı adlarıyla yapılan denemelerde ise sshd bir Invalid user satırı yazdı, her deneme bir sayıldı ve ban beşinci denemede düştü.

Yani fail2ban kullanıcı adı tahmin eden botları susturmaya devam eder, ama var olan bir hesabı (her sunucuda bulunan root gibi) hedefleyen denemeyi göremez. Bunu görmek için jail’e mode = aggressive yazmak gerekir; farkı filtreyi sınama bölümünde fail2ban-regex ile gösteriyorum. Bu ölçüm, Ubuntu Server rehberinde söylediğimizi doğruluyor. Anahtar tabanlı bir sunucuda fail2ban’in koruma değeri düşer, geriye kalan faydası log gürültüsünü azaltmaktır. Kurulsun, ama birincil savunma sanılmasın.

Bu testi yaparken bir tuzağa da denk geldim, çünkü ntp01 gibi cloud-init’le kurulan Ubuntu sunucularında parola girişini kapatmak göründüğü kadar kolay değil. /etc/ssh/sshd_config.d/ altına PasswordAuthentication no yazan bir dosya bırakmak tek başına yetmeyebilir, çünkü aynı dizindeki 50-cloud-init.conf dosyası PasswordAuthentication yes diyor ve sshd bir ayar için ilk karşılaştığı değeri kullanıyor. Dosyanızın adı alfabede 50-’den sonra geliyorsa sshd onu okur ama o satır hükümsüz kalır.

Etkili değeri her zaman sudo sshd -T | grep -i passwordauthentication ile doğrulayın. Kapatmak için ya 50-cloud-init.conf’u düzenleyin ya da adı ondan önce gelen (00- gibi) bir dosya kullanın.

Yavaş deneme pencereyi atlar. findtime kayan bir penceredir ve yalnız son on dakikadaki başarısızlıkları sayar. Bir bot on dakikada bir deneme yaparsa pencerede aynı anda en fazla iki deneme, yani dört satır bulunur ve beş satırlık eşik hiç dolmaz. Bu sınırı ölçmedim; ölçtüğüm satır sayımından ve pencerenin tanımından çıkan bir hesaptır. findtime’ı uzatmak bu boşluğu daraltır ama kapatmaz.

Dağıtık deneme kaynak başına sayımı boşa çıkarır. fail2ban kaynağı banladığı için, denemelerini çok sayıda farklı adrese yayan bir saldırgan her adresi eşik altında tutar ve hiçbiri banlanmaz. Onlarca adrese bölünmüş bir deneme, fail2ban’in gözünde onlarca küçük ve zararsız kaynaktır. Bunu tek kaynaklı laboratuvarda ölçemedim; ölçtüğüm kaynak başına sayımın doğrudan sonucudur. Bu durumda savunma fail2ban değil, kaynak sayısından bağımsız çalışan katmanlardır: çok faktörlü doğrulama, anahtar tabanlı giriş ve erişimin daraltılması.

fail2ban ignoreip ve Whitelist: Kendini Kilitleme Tuzağı

fail2ban’in verebileceği en pahalı ban, yöneticinin kendisine verdiği bandır. Yönetim iş istasyonunuzdan parola üst üste yanlış girilirse eşiği o adres doldurur ve fail2ban onu da bir saldırgan gibi banlar. Ban süresince yönetim SSH’ınız kapanır. Konsola erişiminiz yoksa beklemekten başka yol kalmaz.

Ölçtüğüm kurulumda bu tuzağın kapısı sonuna kadar açıktı:

sudo fail2ban-client get sshd ignoreip

No IP address/network is ignored

ignoreip listesi, yani fail2ban’in whitelist’i, kurulumla birlikte boş geliyor. Varsayılan olarak açık olan ignoreself ayarı sunucunun kendi adreslerini muaf tutmak için vardır, ama ölçümde sunucunun kendi LAN adresi olan 192.168.1.15 bile banlandı. Yönetim istasyonunuzu koruyan tek şey bu listedir. Yukarıdaki jail.local örneğindeki satır tam olarak bunu yapıyor:

ignoreip = 127.0.0.1/8 ::1 192.168.1.115

Yine de kendinizi kilitlerseniz, konsoldan tek komutla kurtulursunuz:

sudo fail2ban-client set sshd unbanip 192.168.1.115

Bu tuzak bantime.increment’in iki yüzünü de gösterir. Israrla dönen botu yoran ayar, parolasını üst üste yanlış giren yöneticiyi de yorar. Ölçümde daha önce banlanmış bir kaynak ikinci kez üç denemede, üçüncü kez tek denemede banlandı. Uzayan beklemeyi açıyorsanız ignoreip satırı isteğe bağlı değildir.

Filtreyi Sınamak: fail2ban-regex

Başta fail2ban’in arkasında tek bir kural durduğunu söyledim. Bunu ikinci bir servis kurmadan da gösterebiliriz, çünkü fail2ban’in kalbi bir filtredir: bir logdaki başarısızlık desenini tanıyan bir düzenli ifade. Bir logun filtreye nasıl takıldığını fail2ban-regex ile sınayabilirsiniz. Ubuntu 24.04’te sshd jail’i journal’ı okuduğu için komuta dosya yerine journal verilir:

sudo fail2ban-regex systemd-journal sshd

Ölçtüğüm sunucunun bütün sshd geçmişi için sonuç satırı şuydu:

Lines: 1418 lines, 473 ignored, 57 matched, 888 missed

Üç sayı üç ayrı şey söylüyor:

• matched (57) sayılan başarısızlıklardır: 29 Failed password ve 28 Invalid user satırı.
• ignored (473) filtrenin tanıdığı ama bilerek saymadığı satırlardır. 397’si başarılı girişi bildiren Accepted, 45’i Connection closed ... [preauth] satırıdır.
• missed (888) filtrenin hiçbir desenine uymayan sshd satırlarıdır.

Aynı araç, parola kapalıyken görünmez kalan denemeyi de açığa çıkarır. Parola girişi kapalıyken var olan kullanıcıyla yaptığım altı denemenin journal satırlarını bir dosyaya aldım ve dosyayı iki modda sınadım:

fail2ban-regex parola-kapali.log sshd
fail2ban-regex parola-kapali.log 'sshd[mode=aggressive]'

Lines: 6 lines, 6 ignored, 0 matched, 0 missed
Lines: 6 lines, 0 ignored, 6 matched, 0 missed

Varsayılan mod altı satırı da tanıdı ama saymadı, aggressive mod altısını da saydı. Canlı jail’de bu farkı açmak için jail.local’deki [sshd] bölümüne mode = aggressive satırı eklenir.

Önemli olan şudur: bir web sunucusu ya da mail sunucusu için de aynı iş, aynı biçimde yapılır. Yalnız log kaynağı ve filtre değişir; nginx girişi için nginx-http-auth, postfix için postfix filtresi kullanılır. Bariyer aynı bariyerdir, kamera aynı kameradır; yalnız hangi kaydı okuyacağını söylersiniz.

Sonuç: fail2ban Asıl Savunma Değil, Üstüne Binen Katmandır

fail2ban kapıyı kapatan şey değildir; kaydı okuyan ve gürültü yapan kaynağı bariyerin önünde bir süre bekleten sistemdir. İyi kurulduğunda internete açık bir sunucunun log gürültüsünü keser, otomatik botların hızını kırar ve ısrarcıyı uzayan beklemelerle yorar. Sınırları da aynı mekanizmadan doğar. Yalnız filtresinin saydığı satırı görür, bu yüzden parola kapalıyken gerçek bir kullanıcı adına yapılan denemeyi varsayılan modda hiç görmez. Pencereden yavaş gelen denemeyi kaçırır ve kaynak başına saydığı için dağıtık bir denemeye karşı kördür.

Bu yüzden fail2ban’i asıl savunma değil, savunmanın üstüne binen bir katman olarak kurun. Kapıyı gerçekten kapatan şey anahtar tabanlı kimlik doğrulama ve erişimin daraltılmasıdır; fail2ban o kapının önünde biriken gürültüyü temizler ve size logunuzda gerçek olayı görme şansı bırakır. Toplanan bu kayıtları merkezi bir yerde okunur tutmak ise ayrı bir iştir, onu merkezi log sunucusu rehberinde anlattık.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn