Hız Sınırlama ve Kaba Kuvvet Koruması Nasıl Eklenir

Herhangi bir kontrol eklemeden önce, uygulamanızda kaba kuvvet veya otomatik kötüye kullanıma hedef olabilecek her uç noktayı haritalayın. Kamuya açık bir giriş veya API uç noktasını gözden kaçırmak bile saldırganlara bir kapı açar.

• Her kimlik doğrulama uç noktasını listeleyin: giriş, kayıt, şifre sıfırlama, e-posta doğrulama ve sihirli bağlantı giriş noktaları.
• Kimlik bilgisi veya token kabul eden API uç noktalarını belirleyin (OAuth token değişimi, API anahtarı doğrulaması vb.).
• Yönetici panellerini, hazırlama ortamlarını ve kullanıcıların kimliğini doğrulayan üçüncü taraf entegrasyon geri çağrılarını (callback) dahil edin.
• Kullanıcı adı numaralandırma (enumeration) güvenlik açıklarını kontrol edin — geçerli ve geçersiz kullanıcı adları için farklı yanıtlar döndüren uç noktalar saldırganlara başlangıç noktası sağlar.
• Makul hız sınırı eşikleri belirleyebilmek için her uç nokta için beklenen meşru trafik hacimlerini belgeleyin.

Hız sınırlama, tek bir istemcinin belirli bir zaman dilimi içinde yapabileceği istek sayısını kısıtlar. Otomatik saldırılara karşı ilk ve en geniş kapsamlı savunmadır — hem kaba kuvvet parola tahminini hem de kimlik bilgisi doldurmayı yavaşlatır.

• Limitler uygulama sunucularınıza ulaşmadan önce zorlanacağı için hız sınırlamasını ters proxy veya yük dengeleyici düzeyinde uygulayın (ör. Nginx limit_req, HAProxy stick-table'ları, AWS WAF hız kuralları, Cloudflare Rate Limiting).
• Giriş uç noktalarında sıkı limitler belirleyin — yaygın bir başlangıç noktası IP adresi başına dakikada 5–10 istektir.
• Şifre sıfırlama ve e-posta doğrulama uç noktalarına ayrı ve daha sıkı limitler uygulayın (ör. IP başına 15 dakikada 3 istek).
• Pek çok IP'ye yayılmış dağıtık saldırılara karşı savunmak amacıyla IP adresine ek olarak kullanıcı kimliğine (kullanıcı adı veya hesap kimliği) göre de hız sınırlaması yapın.
• Meşru istemcilerin uç noktayı daha fazla zorlamadan zarif biçimde geri çekilebilmesi için Retry-After başlığıyla birlikte HTTP 429 (Too Many Requests) döndürün.
• Hata mesajlarında bilgi sızdırmaktan kaçının — hız sınırlı istekler için başarısız girişlerle aynı genel mesajı döndürün.
• API'ler için API ağ geçidi katmanında token-bucket veya kayan pencere hız sınırlaması uygulayın ve limitleri API spesifikasyonunuzda belgeleyin.
• Sensagraph, açık uç noktalarınızı sürekli olarak hız sınırlama kontrollerinin varlığı açısından tarar ve sınırsız istekleri kabul edenleri işaretler.

Yalnızca IP başına hız sınırlama, dağıtık botnet'lere karşı yetersizdir. Hesap düzeyinde kilitleme ve aşamalı gecikmeler, saldırganın kaç farklı IP adresi kullandığından bağımsız olarak bireysel kullanıcı hesaplarını koruyan ikinci bir katman ekler.

• Yapılandırılabilir sayıda başarısız giriş denemesinden sonra (ör. kayan 15 dakikalık pencerede 5–10 ardışık başarısız deneme) hesabı geçici olarak kilitleyin.
• Meşru kullanıcılara karşı hizmet reddi yaratmaktan kaçınmak için kalıcı kilitler yerine geçici kilitlemeler (ör. 15–30 dakika) tercih edin; erken kilit açmak için e-posta onayı veya MFA gerektirin.
• Alternatif veya tamamlayıcı olarak aşamalı gecikmeler (üstel geri çekilme) uygulayın — her başarısız deneme bir sonraki işlenmeden önce artan gecikme ekler (ör. 1 sn, 2 sn, 4 sn, 8 sn…).
• Başarısız deneme sayaçlarını hızlı ve paylaşımlı bir veri deposunda (Redis veya Memcached) saklayın; böylece tüm uygulama örnekleri aynı sayacı paylaşır — yalnızca sunucu başına bellekte tutulmamalıdır.
• Sayacı yalnızca başarılı girişte sıfırlayın; zaman tabanlı bir pencere de uygulamıyorsanız yalnızca zamanın geçmesiyle sıfırlamayın.
• Bir kilitleme tetiklendiğinde hesap sahibine, zaman damgası ve denemelerin yaklaşık coğrafi kökeni dahil olmak üzere e-posta ile bildirim gönderin.
• Kayıtlı e-posta adresine veya MFA cihazına erişim gerektiren self-servis kilit açma akışı sağlayın.

CAPTCHA zorlukları, her istekte değil, birkaç başarısızlıktan sonra devreye alındığında en etkilidir — bu sayede meşru kullanıcıların kullanıcı deneyimi olumsuz etkilenmez, ancak çözemeyen botlar engellenir.

• Aynı IP'den veya aynı hesap için 3–5 ardışık başarısız giriş denemesinden sonra CAPTCHA zorluğu tetikleyin.
• Meşru kullanıcılar için sürtünmeyi en aza indirmek amacıyla görünmez veya düşük sürtünmeli bir CAPTCHA çözümü kullanın (ör. Google reCAPTCHA v3, hCaptcha, Cloudflare Turnstile).
• CAPTCHA token'larını sunucu tarafında doğrulayın — asla yalnızca istemci tarafı doğrulamaya güvenmeyin.
• CAPTCHA'nın yalnızca giriş değil, kayıt ve şifre sıfırlama akışlarına da uygulandığından emin olun.
• Erişilebilirlik gereksinimleri olan kullanıcılar için bir yedek seçenek sunun (sesli CAPTCHA, e-posta zorluğu).
• CAPTCHA gizli anahtarlarını düzenli olarak değiştirin ve güvenli biçimde saklayın (kaynak kodu değil, ortam değişkenleri veya gizli yönetim sistemi).

Hız sınırlama ve kilitleme politikaları uygulanmış olsa bile, yeterli süre veya zayıf bir parola verildiğinde başarılı bir kaba kuvvet saldırısı teorik olarak mümkündür. MFA, doğru parolanın tek başına erişim sağlamaya yetmemesini garanti eder.

• Tüm yönetici ve ayrıcalıklı hesaplar için MFA'yı zorunlu kılın — istisna olmaksızın.
• Tüm kullanıcılara MFA sunun ve güvenlik avantajını açıkça ileterek uygulama içi istemler aracılığıyla benimsemeyi güçlü biçimde teşvik edin.
• Minimum olarak zamana dayalı tek kullanımlık parolaları (Google Authenticator veya Authy gibi uygulamalar aracılığıyla TOTP) destekleyin.
• En yüksek düzeyde kimlik avı ve kaba kuvvet direnci için donanım güvenlik anahtarlarını (FIDO2/WebAuthn passkey'ler) destekleyin.
• SIM değiştirme riski nedeniyle yüksek değerli hesaplar için yalnızca SMS tabanlı MFA'dan kaçının; SMS'i birincil yöntem değil, yedek olarak değerlendirin.
• MFA doğrulama girişimlerine de hız sınırlama ve kilitleme politikaları uygulayın — ikinci faktörü korumasız bırakmayın.
• Güvenli hesap kurtarma kodları (tek kullanımlık, hash'lenmiş olarak saklanan) sağlayın ve kullanıcıları bunları güvenli biçimde saklamaları konusunda bilgilendirin.

Kullanıcıların kolayca tahmin edilebilir parolalar belirlemesine izin verilirse güçlü hız sınırlama etkisiz hale gelir. Hız sınırlama kontrollerini sağlam parola politikalarıyla birleştirerek saldırganın her tahmininin değerini azaltın.

• En az 12 karakter uzunluğunda parola zorunluluğu getirin; yeni uygulamalar için 16+ karakter önerilir.
• Yeni parolaları bilinen ihlal edilmiş parolalar listesiyle karşılaştırın (ör. Have I Been Pwned Pwned Passwords API'si veya yerel bir veri seti kopyası kullanarak) ve eşleşenleri reddedin.
• Kullanıcıları öngörülebilir kalıplara yönlendiren keyfi karmaşıklık kuralları (ör. zorunlu semboller) uygulamayın — uzunluk ve ihlal denetimi daha etkilidir.
• Parolaları güçlü, yavaş bir algoritmayla hash'leyin: bcrypt (maliyet faktörü ≥ 12), Argon2id veya scrypt. MD5, SHA-1 veya tuzlanmamış hash'ler kesinlikle kullanmayın.
• Bir ihlal şüphesi yoksa sık zorunlu parola rotasyonu uygulamayın — bu durum artımlı, öngörülebilir değişikliklere yol açar.
• Parola içinde kullanıcı adı, alan adı veya ardışık karakter kullanımı gibi yaygın kalıpları tespit edip engelleyin.

Uygulama düzeyindeki hız sınırlamasının üzerine ağ düzeyinde kontroller eklemek, özellikle bilinen kötü amaçlı altyapıdan kaynaklanan büyük ölçekli otomatik saldırılara karşı ek bir bariyer sağlar.

• Botnet'ler, Tor çıkış düğümleri veya bilinen kötü aktörlerle ilişkili IP'lerden gelen istekleri otomatik olarak engellemek için bir IP itibar akışı veya tehdit istihbaratı hizmeti entegre edin (ör. WAF veya CDN'niz aracılığıyla).
• Yöneticileriniz öngörülebilir ağ konumlarından (ofisler veya VPN) çalışıyorsa yönetici panellerine IP beyaz listesiyle erişimi kısıtlamayı değerlendirin.
• Kullanıcı tabanınız coğrafi olarak belirli bir bölgede yoğunlaşmışsa, beklenmedik ülkelerden yapılan girişleri sorgulayabilir veya engelleyebilirsiniz — ancak seyahat eden meşru kullanıcıların erişimi yeniden kazanabileceği net bir mekanizma sağlayın.
• Kaba kuvvet girişim kaynaklarının otonom sistem numaralarını (ASN) günlüğe kaydedin ve inceleyin; sıkça kötüye kullanılan barındırma sağlayıcılarını tespit ederek gerekirse sağlayıcı düzeyinde engelleme uygulayın.
• Aşırı engelleme yapmamaya dikkat edin — paylaşılan NAT ortamları (kurumsal proxy'ler, mobil operatörler) pek çok meşru kullanıcının aynı IP'nin arkasında görünmesine neden olabilir.

Kontroller yalnızca çalıştıklarını doğrulayabildiğinizde ve atlatıldıklarında bunu tespit edebildiğinizde etkilidir. Kapsamlı günlükleme ve gerçek zamanlı uyarı, hem olay müdahalesi hem de eşiklerinizin sürekli ayarlanması için zorunludur.

• Her kimlik doğrulama girişimini — başarı, başarısızlık, kilitleme ve hız sınırı tetiklemesi — zaman damgası, kaynak IP, kullanıcı ajanı ve hesap tanımlayıcısıyla (asla parolanın kendisiyle değil) günlüğe kaydedin.
• Kimlik doğrulama günlüklerini uygun saklama politikalarıyla merkezi bir günlük yönetimi veya SIEM sistemine iletin (ör. ELK Stack, Splunk, Datadog, AWS CloudWatch).
• Şunlar için uyarılar oluşturun: birden fazla hesapta ani başarısız giriş denemesi artışı (kimlik bilgisi doldurma); tek bir hesap için tekrarlanan kilitleme tetiklemeleri; ardışık başarısızlıklardan hemen sonra yeni bir ülke veya cihazdan başarılı giriş.
• Uyarı eşiklerini normal trafik temel çizginize göre belirleyin — üç ayda bir gözden geçirip ayarlayın.
• Hazırlama ortamında başarısızlık senaryolarını simüle ederek uyarı hattınızı düzenli olarak test edin.
• Kimlik doğrulama günlüklerini en az 90 gün saklayın (PCI-DSS veya ISO 27001 gibi uyumluluk çerçeveleri tarafından gerekli kılınıyorsa daha uzun süre).

Test edilmemiş savunmalara güvenilmemelidir. Kontrollerinizin tüm ortamlarda ve her önemli kod veya altyapı değişikliğinden sonra beklendiği gibi davrandığını düzenli olarak doğrulayın.

• Hızlı ardışık başarısız giriş denemelerini simüle eden ve 429 yanıtı ile kilitlemenin doğru eşiklerde tetiklendiğini doğrulayan otomatik entegrasyon testleri yazın.
• Dağıtık sayacınızın (Redis vb.) tüm uygulama örnekleri arasında doğru biçimde paylaşıldığından emin olmak için hız sınırlamasını aynı anda birden fazla IP adresinden test edin.
• Hız limitlerinin dağıtım sonrasında da devam ettiğini doğrulayın — sayaçlar yeniden başlatmalar ve kayan güncellemeler boyunca kalıcı olmalıdır.
• Hesap kilit açma akışını uçtan uca test edin: kilitleme tetikleyin, bildirim e-postasını alın, kilit açma bağlantısını takip edin ve erişimin yeniden sağlandığını onaylayın.
• Üretim ortamına girmeden önce regresyonların yakalanması için CI/CD hattınıza hız sınırlama ve kilitleme kontrollerini dahil edin.
• Atlatmaları (ör. IP'leri döndürmek için X-Forwarded-For sahteciliği gibi başlık manipülasyonu) ortaya çıkarmak amacıyla özellikle kimlik doğrulama mekanizmalarını hedefleyen periyodik sızma testleri veya kırmızı takım egzersizleri gerçekleştirin.
• IP tabanlı hız sınırlamasını atlatmak için X-Forwarded-For ve benzeri başlıkların yalnızca bilinen, meşru proxy adreslerinden güvenildiğinden emin olun — uygulamanız bu başlıklara körü körüne güveniyorsa saldırgan onları sahteleyebilir.
• Sensagraph, hız sınırlama ve kaba kuvvet koruma kontrollerinin etkin ve doğru yapılandırılmış olduğunu doğrulamak için giriş ve hassas uç noktalarınızı otomatik olarak araştırır.

Hız sınırlama ve kaba kuvvet koruması bir kez kurulup unutulacak kontroller değildir. Saldırı teknikleri gelişir, trafik kalıpları değişir ve yeni uç noktalar eklenir. Düzenli bir gözden geçirme döngüsü, savunmalarınızın zaman içinde etkili kalmasını sağlar.

• Üç ayda bir veya kullanıcı trafik hacminde önemli bir değişiklikten sonra hız sınırı eşiklerini gözden geçirin.
• Yeni atlatma tekniklerini ortaya çıktıkça öğrenmek için teknoloji yığınınızla ilgili tehdit istihbarat akışlarına ve güvenlik uyarılarına abone olun.
• Kimlik doğrulamaya dayalı akış veya API kimlik doğrulaması sunan her yeni özellik için geliştirme sürecinizde güvenlik şampiyonu veya güvenlik inceleme sürecine kimlik doğrulama güvenliğini dahil edin.
• Kimlik doğrulamayla ilgili herhangi bir güvenlik olayından sonra olay sonrası analiz yapın ve kontrolleri buna göre güncelleyin.
• Aktif bir olay sırasında görevdeki mühendislerin ayarları hızlıca anlayıp düzenleyebilmesi için hız sınırlama ve kilitleme yapılandırmanızı güvenlik çalışma kitabınızda belgeleyin.