Brute Force Saldırılarına Karşı Sunucu Koruması: Net Rehber

Brute force saldırıları (parola tahminine dayalı denemeler) çoğu sunucuda kimlik doğrulama noktalarını hedefler. Sorun sadece "kötü niyetli giriş" değil; yanlış yapılandırılmış loglar, zayıf parola politikaları ve eksik erişim kontrolleri yüzünden saldırı tırmanır. Bu rehberde, 31.05.2026 senaryolarına uygun şekilde brute force saldırılarına karşı uçtan uca bir koruma planını adım adım kuracaksın. Hangi ayarı neden yapacağını, hangi ölçümle işe yaradığını ve hangi sırayla ilerleyeceğini net biçimde öğreneceksin.

1) Brute force nerede patlar: saldırı yüzeyi haritası

Brute force saldırısının etkin olabilmesi için saldırganın tekrar tekrar deneme yapabileceği açık bir giriş noktası gerekir. Bu yüzden ilk iş “hangi servisler deneme alıyor?” sorusunu netleştirmektir.

Hedeflenen tipik alanlar

SSH (22/2222): Özellikle parola ile giriş açıksa.
Panel girişleri: cPanel, Plesk, özel admin panelleri.
Web formlarındaki login: /login, /admin, REST auth endpoint’leri.
Mail sistemleri: IMAP/POP parola denemeleri.
API anahtarları / token yenileme: Yanlış rate limit varsa.

30 gün içinde kontrol listesi (pratik)

Aşağıdakileri tek tek doğrula: - Sunucunda internetten erişilen tüm yönetim portları gerçekten gerekli mi? (Örn. SSH sadece belirli IP’ler açık mı?) - Yönetici kullanıcıları için parola politikası var mı? (minimum uzunluk, parola tekrarları yok mu?) - Kullanıcı adı/eposta doğrulaması uygulama katmanında “yanıtı tutarlı” mı? (Saldırganın kullanıcı adı tahminini hızlandırmaması için) - “Başarısız deneme” logları merkezi bir yerde toplanıyor mu?

Net ölçüm hedefi: 24 saat içinde en az şu raporu çıkarabilmen gerekir: “Hangi IP hangi endpoint’e kaç deneme yaptı, hangi saat aralığında yoğunlaştı?”

2) Kimlik doğrulamayı sertleştir: MFA + parola politikası

Brute force’a karşı en güçlü katman, parola denemelerinin tek başına yetmemesini sağlamaktır.

MFA’yı (multi-factor authentication) zorunlu yap

Panel girişleri ve yönetim arayüzleri için MFA kullan.
Yalnızca SSH tarafında MFA aramak yerine web panelini ve uygulama login’lerini de kapsa.
Uygulama seviyesinde: yöneticilere ve kritik kullanıcı rollerine zorunlu MFA.

Net kural: Yönetici rollerinde MFA kapalıysa, bruteforce maliyeti saldırgan için düşer; sonuç olarak tespit zorlaşır.

Parola politikasını sayıya bağla

Parola minimum uzunluğu: en az 12 karakter (12 altı genellikle brute force maliyetini düşürür).
İçerik: rastgelelik ve tekrar yasakları.
Parola yeniden kullanımı engeli: son X parola (ör. 5) kontrolü.

Kullanıcı adı doğrulama davranışını standardize et

Var/yok kullanıcı adlarına göre farklı hata mesajı verme.
“Kullanıcı adı hatalı” / “parola hatalı” gibi ayrım saldırganın kullanıcı listelemesini hızlandırır.

3) SSH’yi brute force’a kapat: net yapılandırma adımları

SSH, brute force denemelerinin en sık görüldüğü noktadır. Burada hedef “deneme sayısını düşürmek” ve “deneme yapabilecek yüzeyi daraltmak” olmalıdır.

Saldırı yüzeyini azalt

SSH’yi varsayılan port dışına taşımak tek başına çözüm değildir; tek başına yapma. Asıl farkı IP kısıtlaması sağlar.
Sunucu yönetimi için statik ofis/IP aralığın varsa: sadece o IP’lerden SSH aç.

Parola ile girişi devre dışı bırak (en net kazanım)

Mümkünse SSH anahtarı (key-based auth) kullan.
Parola ile giriş kapalı olunca brute force denemeleri anlamsızlaşır.

Fail2ban ile denemeleri kilitle

Fail2ban, başarısız giriş denemelerini tespit eder ve IP’yi geçici süreyle engeller. Bunu sadece SSH için değil, web login ve panel için de log tabanlı uygulayabilirsin.

Aşağıdaki mantık, ayarların hedefini netleştirir: - Eşik: ör. 10 deneme / 10 dakika - Blok süresi: ör. 1-24 saat (risk durumuna göre) - Aynı IP sürekli deniyorsa: kademeli (bazen “bant genişliği” gibi düşün)

Burada kritik nokta: Fail2ban ban süresi ve deneme eşiğini körlemesine koyma. Uygulama loglarını inceleyerek karar ver.

4) Uygulama ve panel koruması: rate limit + WAF/IDS

SSH sertleştirmesi tek başına yetmez; brute force web login endpoint’lerini de hedefler.

Uygulama katmanında rate limit

Login endpoint’inde kullanıcı bazlı ve IP bazlı limit uygula.
Örn: “IP başına 15 deneme / 10 dakika” + “hesap başına 5 deneme / 10 dakika” gibi.
Limit aşıldığında doğru hata dön: saldırganın geri besleme almasını azalt.

Net öneri: Aynı anda çok farklı kullanıcı adı deneniyorsa, bu bot davranışıdır; IP limitini sıkılaştır.

WAF (Web Application Firewall) kullanımı

WAF, imza + davranış tabanlı tespitle brute force trafiğini bastırır. - WAF kurallarıyla “login sayfasına yoğun istek” desenlerini yakala. - Bot yönetimi (bot protection) varsa aktif et.

IDS/IPS ile korelasyon

IDS (Intrusion Detection System) ile “kök neden” analizi yaparsın: deneme paterni, saldırgan davranışı.
Tek tek ban etmek yerine, aynı IP/ASN’den gelen diğer istekleri de değerlendir.

5) Doğru loglama ve izleme: işe yarayıp yaramadığını kanıtla

Brute force’a karşı önlem almak kadar, önlemin çalıştığını ölçmek önemlidir. Aksi halde saldırı “azaldı gibi” görünüp devam edebilir.

Minimum log seti

Kaynak IP
Kullanılan endpoint (ör. /login, /wp-login.php, /api/auth)
Zaman damgası (UTC tercihen)
Başarısız neden (tek tip mesaj/etiket)
Kullanıcı adı (mümkünse ama gizlilik gereksinimine dikkat)
Başarı durumu (200/401/403 gibi)

Loglardan net rapor çıkar

Şu 3 soruya cevap arayacak şekilde raporu kurgula: 1. En çok deneme yapılan endpoint hangisi? 2. En agresif kaynak IP(ler) kaç deneme yaptı? 3. Önlem sonrası (rate limit / ban sonrası) denemeler gerçekten düştü mü?

Toplama stratejisi

Uygulama loglarıyla sistem loglarını aynı zaman çizelgesine bağla.
Mümkünse merkezi bir loglama çözümü kullan: tek sunucuda kalan loglar saldırgan tarafından “işlenmez” hale getirilebilir.

6) “Net plan” uygulama sırası: en hızlı kazançtan başla

Aşağıdaki sıra, genellikle en hızlı etkiyi verir ve yanlış yapılandırma riskini azaltır.

1. adım: Yönetim erişimini daralt

SSH yönetimini sadece gerekli IP’lere kısıtla.
Panel/admin portlarını genel internete kapat, VPN/allowlist ile aç.

2. adım: Parola ile girişleri azalt

SSH’de parola girişini kapat.
Panel/admin ve kritik uygulama girişlerinde MFA’yı zorunlu yap.

3. adım: Rate limit uygula

Uygulama login endpoint’lerinde IP + kullanıcı bazlı rate limit koy.
WAF üzerinde bot/abuse kurallarını etkinleştir.

4. adım: Fail2ban / benzeri otomasyon

SSH ve benzeri log tabanlı girişlerde otomatik ban uygula.

5. adım: Log/izleme ile doğrula

Öncesi/sonrası karşılaştır: deneme sayısı, ban sayısı, başarılı giriş oranı.

7) Brute force için gerçekçi risk değerlendirmesi: ölçümle karar ver

Brute force her zaman “dener ama giremez” seviyesinde kalmaz. Bu yüzden karar ağacı olmalı.

Senaryo A: Deneme var ama başarısızlık yüksek

Rate limit eşiğini artırma (körce sıkılaştırma yapma) yerine ban mekanizmasını devreye al.
MFA eksikse kapatmayı tamamla.

Senaryo B: Başarılı giriş artıyor

Parola politikası ve MFA zorunluluğunu hemen uygula.
Yönetici hesaplarını hedefleyen listeleme denemesi varsa IP kısıtlaması ekle.
Oturum yönetimini kontrol et: başarısız denemeler sonrası oturum kilidi var mı?

Senaryo C: Loglar “anlaşılmaz” (görüntü yok)

Öncelik log standardizasyonu: endpoint ve kaynak IP kesin olsun.
Uyarıları (alert) log hacmine göre ayarla; kör alarm kalabalığı oluşturma.

Sonuç: Bugün uygulanacak 5 net aksiyon

Brute force saldırılarına karşı koruma tek hamleyle bitmez; ancak doğru sırayla ilerlersen ilk 24-48 saatte belirgin düşüş görürsün. Bugün şunları uygula: (1) SSH’de parola girişini kapat ve IP allowlist uygula, (2) yönetici ve kritik panel girişlerinde MFA’yı zorunlu yap, (3) login endpoint’lerinde IP + kullanıcı bazlı rate limit kur, (4) Fail2ban (veya eşdeğer) ile başarısız denemeleri otomatik banla, (5) loglardan günlük rapor alıp “önlem sonrası deneme düşüşünü” doğrula.

Bu adımları net biçimde hayata geçirince brute force saldırıları için maliyet yükselir ve saldırı yüzeyi daralır. Sonraki aşamada WAF bot yönetimi ile birlikte daha geniş ölçekte otomatik engelleme katmanı eklemeyi planla.