Cloudflare Arkasında Fail2ban Çalışmıyor: Gerçek Ziyaretçi IP'sini Geri Kazanma

Sabah ilk iş fail2ban-client status nginx-wplogin yazıyorsunuz. Jail ayakta, Currently banned: 3 diyor. Fena değil gibi görünüyor — ta ki banlı IP listesine bakana kadar: 172.69.34.11, 104.23.196.7, 162.158.90.44. Üçü de Cloudflare'in kendi kenar sunucusu. Yani fail2ban saldırganı değil, sitenizin önündeki CDN'i banlamış. Bir dakika sonra destek kutusu doluyor: site hiç kimsede açılmıyor.

Ya da tam tersi senaryodasınız: wp-login.php adresine dakikada yüzlerce POST düşüyor, fail2ban logları okuyor, hiçbir şey banlamıyor. Çünkü maxretry eşiğini gerçekten aşan tek bir istemci var ve o istemcinin adresi bütün ziyaretçilerinkiyle aynı. Fail2ban da haklı olarak "burada anormal bir şey yok" diyor. İki durum da aynı kök nedenin iki yüzüdür ve neden access.log dosyanızın ilk sütununda artık ziyaretçilerin değil, Cloudflare'in IP adresleri yazıyor.

Bu yazı, Cloudflare ile fail2ban'ın kesiştiği bu arızayı uçtan uca kapatıyor: gerçek IP'yi nginx ve Apache seviyesinde geri kazanma, fail2ban filtresini kırmadan bunu yapma, banın neden hâlâ paket düşürmediği ve — Türkçe kaynaklarda neredeyse hiç geçmeyen kısım — yapılandırmayı yanlış kurarsanız fail2ban'ı saldırgana nasıl silah olarak vermiş olacağınız.

Belirti: Ban Sistemi Çalışıyor Görünüyor Ama Kimseyi Durdurmuyor#

Teşhisi tahmine bırakmayın, üç komutla kanıtlayın.

Önce ham log satırlarına bakın. Cloudflare proxy açıkken tipik görüntü şudur:

sudo tail -3 /var/log/nginx/access.log
sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

İkinci komutun çıktısında ilk on satırın hepsi 104., 172.6x., 162.158., 108.162. gibi bloklardan geliyorsa tanı kesindir. Sitenizin gerçek trafiği yüzlerce farklı ağdan gelmesine rağmen sunucu bunların tamamını bir avuç adrese indirgemiş durumda. Log analizinin genel mantığına aşina değilseniz ham erişim kayıtlarını okuma yazısı bu çıktının hangi sütununun ne olduğunu anlatıyor.

Sonra fail2ban'ın neyi banladığına bakın:

sudo fail2ban-client status nginx-wplogin
sudo iptables -L f2b-nginx-wplogin -n -v --line-numbers

Burada iki ihtimal var. Banlı liste boşsa fail2ban eşiği hiç tetiklemiyor demektir — çünkü tek bir "istemci" var ve o istemci Cloudflare. Banlı listede Cloudflare aralıkları varsa daha kötüsü olmuş: kendi CDN'inizi engellediniz ve site kimseye açılmıyor. Bu ikinci durumda acil çözüm bandır:

sudo fail2ban-client set nginx-wplogin unbanip 172.69.34.11
sudo fail2ban-client stop

Kalıcı düzeltmeyi yapana kadar jail'i kapalı tutmak, yanlış banlarla site kesintisi yaşamaktan iyidir.

Neden Herkes Aynı Adresten Geliyor#

Cloudflare'de bir DNS kaydını turuncu buluta aldığınızda o kayıt için TCP bağlantısını artık ziyaretçi değil, Cloudflare'in kenar sunucusu kurar. Sunucunuz açısından bakıldığında karşı taraftaki soket gerçekten Cloudflare'e aittir; REMOTE_ADDR yalan söylemiyor, sadece artık başka bir şeyi ölçüyor. Hangi kaydın proxy'lendiğini, hangisinin doğrudan geldiğini karıştırıyorsanız turuncu bulut mu gri bulut mu yazısı karar tablosunu veriyor.

Ziyaretçinin adresi kaybolmaz; Cloudflare onu HTTP başlıklarına yazar:

Cloudflare üzerinden gelen bir istekte CF-Connecting-IP başlığını istemci belirleyemez; Cloudflare kendi gördüğü kaynak adresle üzerine yazar. Bu yüzden zincir ayrıştırma derdi olan X-Forwarded-For yerine doğrudan bunu kullanmak hem daha basit hem daha güvenlidir. Ancak bu güvence yalnızca istek gerçekten Cloudflare'den geçtiğinde vardır — yazının ilerisindeki en kritik bölüm tam olarak bunun üzerine kurulu.

Nginx'te Gerçek IP'yi Geri Kazanma#

Nginx'in ngx_http_realip_module modülü, güvendiğiniz kaynaklardan gelen isteklerde $remote_addr değerinin kendisini başlıktaki adresle değiştirir. Kritik nokta budur: yeni bir değişken tanıtmaz, mevcut olanı düzeltir. Bu sayede erişim kayıtları, limit_req bölgeleri, GeoIP eşlemeleri ve PHP'nin $_SERVER['REMOTE_ADDR'] değeri tek hamlede doğru adrese kavuşur.

Önce modülün derlenmiş olduğunu doğrulayın; dağıtım paketlerinin çoğunda vardır ama garanti değildir:

nginx -V 2>&1 | tr ' ' '\n' | grep realip

Çıktı --with-http_realip_module vermiyorsa nginx-full ya da nginx-extras paketine geçmeniz gerekir.

Yapılandırmayı ayrı bir dosyaya koyun; birazdan bunu otomatik güncelleyeceğiz:

# /etc/nginx/conf.d/cloudflare-realip.conf
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;

real_ip_header CF-Connecting-IP;

Buradaki listenin kısaltılmamış olması şart; eksik bıraktığınız her aralık, o kenar sunucusundan gelen isteklerin proxy IP'siyle loglanması demektir. Tam listeyi az sonra betikle çekeceğiz.

real_ip_recursive yönergesini bilerek yazmadık. O ayar yalnızca X-Forwarded-For gibi zincir taşıyan başlıklarda anlamlıdır; CF-Connecting-IP tek bir adres taşır, dolayısıyla özyineleme yapılacak bir şey yoktur.

Yapılandırmayı sınayıp yükleyin ve sonucu doğrulayın:

sudo nginx -t && sudo systemctl reload nginx
sudo tail -f /var/log/nginx/access.log

Telefonunuzun mobil verisinden siteye girin. Log satırının başında operatörünüzün verdiği adres görünüyorsa iş bitmiştir.

Log Formatına Dokunmayın — Fail2ban Filtresini Kıran Şey Budur#

İnternetteki pek çok anlatım bu noktada log_format satırına $http_cf_connecting_ip eklemeyi önerir. Bu tavsiye real_ip_header kullanıldığında hem gereksiz hem zararlıdır. Gereksizdir, çünkü $remote_addr zaten düzeltilmiştir. Zararlıdır, çünkü sütun düzenini bozar: fail2ban filtreleri <HOST> işaretçisini satırın belirli bir konumunda arar ve gerçek IP'yi ikinci sütuna taşıdığınızda failregex artık ilk sütundaki Cloudflare adresini yakalar. Sonuç, yazının başındaki felaket senaryosudur.

Yine de her iki adresi görmek istiyorsanız, mevcut formatı bozmadan sona ekleyin:

log_format cf_debug '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" "$http_user_agent" '
                    'edge=$realip_remote_addr';

$realip_remote_addr değişkeni, realip modülü değiştirmeden önceki adresi tutar. Böylece ilk sütun fail2ban için doğru kalır, hangi kenar sunucusunun aracılık ettiğini de satır sonundan okursunuz.

Apache ve cPanel Tarafında mod_remoteip#

Apache'de aynı işi mod_remoteip yapar. Önce modülü etkinleştirin:

sudo a2enmod remoteip
sudo apachectl -M | grep remoteip

Yapılandırma dosyası:

# /etc/apache2/conf-available/cloudflare-realip.conf
RemoteIPHeader CF-Connecting-IP

RemoteIPTrustedProxy 173.245.48.0/20
RemoteIPTrustedProxy 103.21.244.0/22
RemoteIPTrustedProxy 141.101.64.0/18
RemoteIPTrustedProxy 108.162.192.0/18
RemoteIPTrustedProxy 162.158.0.0/15
RemoteIPTrustedProxy 104.16.0.0/13
RemoteIPTrustedProxy 172.64.0.0/13
RemoteIPTrustedProxy 131.0.72.0/22
RemoteIPTrustedProxy 2400:cb00::/32
RemoteIPTrustedProxy 2606:4700::/32

LogFormat "%a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" cf_combined

Burada bir incelik var ve Apache belgeleri bu konuda net: değiştirilen istemci adresinin mod_log_config tarafında karşılığı %a biçim dizesidir, gerçek TCP karşı tarafı ise %{c}a ile alınır. Varsayılan combined formatı ise %h ile başlar. Sürümden sürüme davranış farkı yaşamamak için kendi formatınızı %a ile tanımlayıp sanal konağa açıkça verin — tahmin etmek yerine sabitlemiş olursunuz:

CustomLog ${APACHE_LOG_DIR}/access.log cf_combined

cPanel/WHM sunucularında Apache yapılandırmasını elle düzenlemeyin; ilk httpd.conf yeniden üretiminde değişiklik silinir. Bunun yerine WHM » Service Configuration » Apache Configuration » Include Editor üzerinden "Pre Main Include" bölümüne yazın. Ayrıca WHM'in Tweak Settings ekranındaki güvenilir vekil (trusted proxy) listesi, cPHulk'un da doğru adresi görmesini sağlar; cPHulk ile fail2ban'ı birlikte kullanıyorsanız ikisinin de aynı listeden beslendiğinden emin olun.

Fail2ban Filtresini Yeni Log Biçimine Uydurmak#

Gerçek IP loga düştükten sonra filtreyi doğrulayın. Fail2ban'ın en değerli aracı fail2ban-regex'tir ve jail'i canlıya almadan önce mutlaka çalıştırılmalıdır. Jail mantığına, maxretry ve bantime gibi temel parametrelere hâkim değilseniz önce Fail2ban kurulumu ve yapılandırması yazısını okumak bu bölümü çok daha anlaşılır kılar.

Örnek bir filtre — WordPress giriş sayfasına yapılan POST isteklerini sayar:

# /etc/fail2ban/filter.d/nginx-wplogin.conf
[Definition]
failregex = ^<HOST> .*"(GET|POST) /(wp-login\.php|xmlrpc\.php)\S*" (200|401|403)
ignoreregex =

Jail tanımı:

# /etc/fail2ban/jail.d/nginx-wplogin.local
[nginx-wplogin]
enabled  = true
port     = http,https
filter   = nginx-wplogin
logpath  = /var/log/nginx/access.log
maxretry = 8
findtime = 300
bantime  = 3600
ignoreip = 127.0.0.1/8 ::1 203.0.113.25

Şimdi kanıt aşaması:

sudo fail2ban-regex /var/log/nginx/access.log \
     /etc/fail2ban/filter.d/nginx-wplogin.conf --print-all-matched | tail -30

Çıktının sonundaki özet bölümünde eşleşen satır sayısını ve hangi IP'lerin çıkarıldığını görürsünüz. Burada hâlâ Cloudflare adresleri listeleniyorsa web sunucusu tarafındaki düzeltme çalışmıyor demektir; fail2ban'a dokunmadan geri dönüp set_real_ip_from listesini kontrol edin.

ignoreip satırındaki kendi ofis adresinizi eklemeyi ihmal etmeyin. Bu, yanlış yapılandırılmış bir filtrenin sizi kendi sunucunuzdan kilitlemesini önleyen en ucuz sigortadır.

Asıl Tuzak: Ban Yazılıyor Ama Paket Hiç Ulaşmıyor#

Buraya kadar her şeyi doğru yaptınız: log doğru IP'yi gösteriyor, fail2ban doğru IP'yi banlıyor. Yine de saldırı devam ediyor. Nedeni, çoğu rehberin hiç değinmediği bir katman uyuşmazlığıdır.

Fail2ban'ın varsayılan banaction değeri iptables-multiport'tur ve bu, paketin kaynak adresine bakarak DROP yapar. Oysa Cloudflare arkasında saldırganın paketi sunucunuza kendi adresiyle hiç gelmez; TCP bağlantısını kuran taraf Cloudflare'dir. Yani 3. katmanda yazdığınız kural, hiçbir zaman eşleşmeyecek bir adresi bekler.

Bunu bir komutla kanıtlayabilirsiniz:

sudo iptables -L f2b-nginx-wplogin -n -v

Kuralın başındaki paket ve bayt sayaçları saatlerdir 0 ise ban tamamen kozmetiktir. Üç çözüm yolu vardır:

Cloudflare tarafında banlamak için fail2ban'ın kendi paketinde gelen cloudflare-token aksiyonu kullanılır. Bu aksiyon, ban süresince bir IP Access Rule oluşturur, ban bitince siler:

[nginx-wplogin]
enabled   = true
filter    = nginx-wplogin
logpath   = /var/log/nginx/access.log
banaction = cloudflare-token
maxretry  = 8
findtime  = 300
bantime   = 3600

Kimlik bilgilerini eski global API anahtarıyla değil, yalnızca ilgili bölgede Zone » Firewall Services » Edit yetkisi verilmiş bir API token ile tanımlayın; token'ı tek başına iptal edebilirsiniz, global anahtar ise hesabınızın tamamına yetkilidir.

Bir uyarı: ücretsiz planın IP Access Rule kotası sınırlıdır. maxretry değerini çok düşük tutup dakikada onlarca ban üretirseniz kotayı doldurur ve API hataları almaya başlarsınız. Hacimsel saldırılarda doğru araç fail2ban değil, hız sınırı ve kural setleridir; nginx rate limit yapılandırması bu yükü fail2ban'a hiç bindirmeden karşılar.

set_real_ip_from Olmadan Fail2ban'ı Silaha Çevirmek#

Şimdi bu yazının en önemli bölümü. Yukarıdaki real_ip_header satırını, güvenilir kaynak listesi olmadan ya da listeyi 0.0.0.0/0 gibi geniş tutarak yazarsanız bir arızayı düzeltmiş olmazsınız — saldırgana bir silah vermiş olursunuz.

Mantık basittir. Cloudflare, kendi üzerinden geçen isteklerde CF-Connecting-IP başlığını ezer. Ama sunucunuzun gerçek IP'sini bulup doğrudan bağlanan biri için böyle bir ezme yoktur; gönderdiği başlık aynen sunucuya ulaşır. Origin IP'si sızmış bir sunucuda saldırgan şunu yapar:

for i in $(seq 1 12); do
  curl -sk -H "Host: ornek.com" \
       -H "CF-Connecting-IP: 66.249.66.1" \
       -d "log=admin&pwd=deneme" \
       https://203.0.113.10/wp-login.php > /dev/null
done

Sunucunuz bu istekleri 66.249.66.1 adresinden gelmiş gibi loglar, fail2ban eşiği aşar ve o adresi banlar. Örnekteki adres bir Googlebot tarama adresidir. Aynı yöntemle saldırgan sırasıyla arama motoru botlarınızı, ödeme sağlayıcınızın geri dönüş adreslerini, izleme servisinizi, ofisinizin sabit IP'sini ve nihayetinde Cloudflare kenar aralıklarını banlatabilir — son adım sitenizi tamamen kapatır. Kendi savunma aracınız, dışarıdan tetiklenen bir hizmet reddi mekanizmasına dönüşür.

Korunmanın üç katmanı vardır ve üçü de gereklidir:

1. set_real_ip_from / RemoteIPTrustedProxy listesini yalnızca Cloudflare aralıklarıyla doldurun. Liste dışından gelen bir isteğin başlığı hiç dikkate alınmaz.
2. Origin sunucusunu Cloudflare dışına kapatın (sonraki bölüm).
3. Cloudflare aralıklarını ve kendi yönetim adreslerinizi fail2ban ignoreip satırına ekleyin. Bu, birinci ve ikinci katman bir şekilde delinse bile "tüm CDN'i banlama" felaketini engelleyen son emniyet kemeridir.

Cloudflare Aralıklarını Otomatik Güncel Tutmak#

Cloudflare aralıkları nadiren ama değişir. Elle kopyaladığınız liste bir gün eksik kalır ve o aralıktan gelen istekler proxy IP'siyle loglanmaya başlar — üstelik sessizce. İşi cron'a devredin:

#!/usr/bin/env bash
# /usr/local/sbin/cf-realip-update.sh
set -euo pipefail

OUT=/etc/nginx/conf.d/cloudflare-realip.conf
TMP=$(mktemp)

{
  echo "# Otomatik üretildi: $(date -Is)"
  for url in https://www.cloudflare.com/ips-v4 https://www.cloudflare.com/ips-v6; do
    curl -fsS --max-time 10 "$url" | awk 'NF {print "set_real_ip_from " $0 ";"}'
  done
  echo "real_ip_header CF-Connecting-IP;"
} > "$TMP"

# Boş veya bozuk indirmeye karşı akıl sağlığı kontrolü
if [ "$(grep -c set_real_ip_from "$TMP")" -lt 10 ]; then
  echo "Beklenenden az aralık indirildi, dosya güncellenmedi." >&2
  rm -f "$TMP"; exit 1
fi

install -m 0644 "$TMP" "$OUT"
rm -f "$TMP"

nginx -t && systemctl reload nginx

Betiği çalıştırılabilir yapıp haftalık çalıştırın:

sudo chmod +x /usr/local/sbin/cf-realip-update.sh
echo '17 4 * * 1 root /usr/local/sbin/cf-realip-update.sh' | sudo tee /etc/cron.d/cf-realip

Betikteki iki ayrıntı bilinçlidir. Geçici dosyaya yazıp doğrulama yaptıktan sonra yerine koymak, ağ hatasında yapılandırmanın boş kalmasını önler. nginx -t ile sınamadan reload yapmamak ise hatalı bir dosyanın web sunucusunu düşürmesini engeller.

Origin'i Yalnızca Cloudflare'e Açmak#

Başlık sahteciliğine karşı yapısal çözüm, 80 ve 443 portlarını Cloudflare dışına kapatmaktır. Bu adımı atlarsanız yukarıdaki bütün savunma tek bir "origin IP'si sızdı" olayına bağımlı kalır.

# Mevcut kuralları temizlemeden önce SSH erişiminizin açık olduğundan emin olun
sudo ufw allow OpenSSH

for ip in $(curl -fsS https://www.cloudflare.com/ips-v4) \
          $(curl -fsS https://www.cloudflare.com/ips-v6); do
  sudo ufw allow proto tcp from "$ip" to any port 80,443 comment 'cloudflare'
done

sudo ufw --force enable
sudo ufw status numbered | head -20

Kural listesini doğruladıktan sonra 80/443 için genel izinleri kaldırın. Güvenlik duvarı yönergelerinin ayrıntısı için UFW ile güvenlik duvarı yazısına bakabilirsiniz.

İki not: ödeme sağlayıcısı geri dönüşleri, kargo entegrasyonları ya da izleme servisleri doğrudan origin'e bağlanıyorsa onların adreslerini de açmayı unutmayın; aksi hâlde sipariş bildirimleri sessizce düşmeye başlar. Ayrıca yalnızca web portlarını kısıtladığınızı, SSH ve panel portlarının ayrı bir politikayla yönetildiğini aklınızda tutun.

Kurulum Sonrası Doğrulama Listesi#

Bu beş satırın hepsi yeşile döndüğünde fail2ban artık gerçekten çalışıyor demektir. Ülke bazlı kısıtlama da eklemeyi düşünüyorsanız, GeoIP modülünün doğru ülkeyi görebilmesi de aynı real_ip düzeltmesine bağlıdır; ülke bazlı IP engelleme yazısı o katmanı ele alıyor.

Sıkça Sorulan Sorular#

Cloudflare'i kapatmadan fail2ban'ı kullanmanın daha kolay bir yolu var mı#

Kolay ama eksik bir yol var: fail2ban'ı sunucu loglarına değil, Cloudflare'in kendi güvenlik olaylarına dayandırmak. Bu, ücretli planlarda Logpush ile mümkündür ve gerçek zamanlı değildir. Ücretsiz planda pratik yöntem yazıdaki gibi gerçek IP'yi geri kazanmaktır; kurulum bir kez yapılır, sonrasında bakım gerektirmez.

X-Forwarded-For yerine neden CF-Connecting-IP kullanmalıyım#

X-Forwarded-For virgülle ayrılmış bir zincirdir ve istemcinin gönderdiği değer korunarak sonuna ekleme yapılır. Zinciri yanlış yerden okursanız saldırganın kendi yazdığı sahte adresi gerçek sanırsınız. CF-Connecting-IP tek bir değer taşır ve Cloudflare gelen içeriği ezer, dolayısıyla ayrıştırma hatası yapma ihtimaliniz yoktur.

Gerçek IP'yi düzelttim ama fail2ban hâlâ hiçbir şey banlamıyor#

Sırayla üç şeyi kontrol edin. fail2ban-regex çıktısında eşleşme sayısı sıfırsa sorun filtre ifadesindedir. Eşleşme var ama ban yoksa findtime penceresi içinde maxretry eşiğine ulaşılmıyordur. Ban listesi doluyor ama saldırı sürüyorsa sorun banaction katmanındadır; iptables sayaçlarına bakın, muhtemelen sıfırdır.

Fail2ban'ın Cloudflare aksiyonu için hangi API yetkisi gerekiyor#

Yalnızca ilgili bölge için Firewall Services düzenleme yetkisi yeterlidir. Global API anahtarını kullanmayın; o anahtar hesabınızdaki her şeyi yönetebilir ve sunucunuzda düz metin durur. Token'ı tek bölgeye kısıtlayıp ayrıca IP kısıtı tanımlarsanız, sunucu ele geçirilse bile zarar o bölgenin güvenlik duvarı kurallarıyla sınırlı kalır.

Sunucumu Cloudflare dışına kapatırsam sertifika yenilemem bozulur mu#

HTTP-01 doğrulaması Cloudflare üzerinden geçtiği için normalde bozulmaz; sertifika otoritesi alan adına bağlanır, doğrudan origin'e değil. Bozulma ihtimali proxy'nin kapalı olduğu (gri bulut) kayıtlarda ya da doğrudan IP ile doğrulama yapan senaryolarda ortaya çıkar. Bu durumda DNS-01 doğrulamasına geçmek en temiz çözümdür.

Ban süresi bitince Cloudflare tarafındaki kural otomatik siliniyor mu#

Evet. Fail2ban'ın Cloudflare aksiyonu ban başladığında kuralı oluşturur, bantime dolduğunda aynı API üzerinden siler. Fail2ban servisi ban süresi dolmadan çökerse kural kenarda asılı kalabilir; bu yüzden Cloudflare panelindeki IP Access Rules listesini ayda bir gözden geçirip artık gerekli olmayan kayıtları temizlemek iyi bir alışkanlıktır.