# Dağıtık brute force ve DDoS'a karşı akıllı rate limiting'i nasıl kurarım?

> IP limiti dönen proxy'lere yenilir: Redis sliding-window'u hesap + IP + ASN'de anahtarlayın, hesap kilidi ekleyin, volumetrik seli edge'e bırakın.

- Soruldu: 2026-05-29
- Yanıtlandı: 2026-06-01
- Soran: Murat
- Etiketler: dayaniklilik, guvenlik, redis
- Kaynak: https://www.muhammetsafak.com.tr/sor-bakalim/dagitik-brute-force-ve-ddos-icin-akilli-rate-limiting/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
**Soru:** API'ın login endpoint'ine yoğun brute force ve DDoS saldırısı var. Standart IP tabanlı rate limiting (dakikada 60 istek) işe yaramıyor çünkü saldırgan proxy arkasından binlerce farklı IP kullanıyor.

Redis tabanlı sliding window counter ya da token bucket ile; IP, kullanıcı adı, User-Agent ve ülke kodunu kombine eden dinamik ve akıllı bir rate limiter'ı nasıl inşa ederim?


Kısa cevap: IP başına limit, dönen proxy'lere karşı çaresiz — o yüzden ölçeklemeyi yalnızca IP üzerinden yapmayın. Saldırıyı çok boyutlu anahtarlama ve katmanlı savunma ile kırın.

Asıl problem şu: saldırgan binlerce IP'yi rotasyona soktuğu için "IP başına 60" kuralı her bireysel IP için asla tetiklenmez. Saldırının ortak paydasını yakalamanız lazım.

1. **Redis sliding-window'u çok boyutta anahtarlayın.** Token bucket da bu problemi çözer; ben boyutları tek bir yapıda birleştirmek için sliding-window'u tercih ediyorum. Tek bir sayaç değil, birkaç boyutta sayaç tutun: kullanıcı adı (tek hesap spray'leniyorsa), IP, IP subnet'i / ASN, User-Agent parmak izi, ülke kodu. Bir IP temiz görünse de aynı `username`'e binlerce farklı IP'den vuran trafik o boyutta patlar.
2. **Başarısızlık oranı yükselince dinamik sıkın.** Normalde gevşek olan limitleri, hata (başarısız login) oranı ani yükseldiğinde otomatik daraltın. Sabit eşik yerine, saldırı sinyaliyle sertleşen bir eşik kullanın.
3. **Credential stuffing'e karşı hesap kilidi ve challenge ekleyin.** Başarısız login'lerde hesap bazında kademeli gecikme/kilit uygulayın; N denemeden sonra CAPTCHA veya proof-of-work isteyin. Bu, dağıtık saldırının tek hedefli versiyonunu (account takeover) ayrıca kapatır.
4. **Gerçek volumetrik DDoS'u edge'e itin.** Uygulamanız bir L3/L7 flood'unu ememez — bunu kabul edin. Hacimsel saldırıyı Cloudflare gibi bir edge katmanına bırakın; sizin Redis limiter'ınız akıllı, hedefli kötüye kullanımı durdurur, ama sel için altyapı katmanı gerekir.
5. **Login yolunu fail-closed yapın, hangi boyutun tetiklendiğini sızdırmayın.** Limiter ya da Redis hata verirse login'i kapatın (fail-closed), açık bırakmayın. Reddederken "IP'iniz engellendi" gibi hangi boyutun patladığını saldırgana söylemeyin; kararları loglayın ama sadece kendi tuning'iniz için.

**Sonuç:** Ben olsam Redis'te `hesap + IP + ASN` üzerinde sliding-window kurar, credential stuffing için hesap kilidi ekler, volumetrik kısmı edge'e bırakırdım. Tek boyut (IP) hiçbir zaman yetmez; saldırının ortak paydasını yakalayan kombinasyon işi çözer.

## İlgili Yazılar

- [Container'ı non-root çalıştırınca mount edilen storage dizinine yazamıyorum, izinleri nasıl çözerim?](https://www.muhammetsafak.com.tr/sor-bakalim/containeri-non-root-calistirinca-mount-edilen-storage-dizinine-yazamiyorum-izinleri-nasil/) — Sor Bakalım
- [Hata oranı artınca otomatik rollback yapan (self-healing) deploy altyapısını nasıl tasarlarım?](https://www.muhammetsafak.com.tr/sor-bakalim/hata-artisinda-otomatik-rollback-ve-kendi-kendini-iyilestiren-deploy/) — Sor Bakalım
- [Fintek API'si için Canary mi, Blue-Green deployment mı?](https://www.muhammetsafak.com.tr/sor-bakalim/canary-mi-blue-green-mi-fintek-api-icin-deploy-stratejisi/) — Sor Bakalım