Rate Limiting Nedir? Kaba Kuvvet ve API Koruması

Rate limiting nedir sorusunu bir örnekle düşün: giriş formuna aynı hesap için bir dakikada yüzlerce parola denemesi geliyor. Gerçek bir kullanıcı bunu yapmaz. Oran sınırlama, bu tür trafiği sayar ve sınırı aşan istekleri geciktirir ya da reddeder. Kaba kuvvet saldırısını, otomatik taramayı ve API'nin kötüye kullanımını yavaşlatır. Bu yazıda algoritmaları, 429 yanıtını ve doğru kurulumu göreceksin.

Rate limiting nedir ve nasıl çalışır?

Her oran sınırının üç parçası vardır:

• Anahtar: Kimi saydığın. IP adresi, kullanıcı hesabı, API anahtarı ya da oturum olabilir.
• Pencere: Hangi süre içinde saydığın. Örneğin bir dakika.
• Sınır: Bu sürede kaç isteğe izin verdiğin.

İstek geldiğinde sistem anahtarın sayacına bakar. Sınırın altındaysa isteği geçirir ve sayacı artırır. Sınır aşıldıysa isteği bekletir ya da reddeder. Süre dolunca sayaç azalır ya da sıfırlanır.

Sayacın nerede tutulduğu önemlidir. Tek sunuculu bir uygulamada bellek yeterlidir. Birden çok sunucu varsa sayaç ortak bir veri deposunda ya da ağ geçidinde durmalıdır. Yoksa her sunucu kendi sayacını tutar ve saldırgan sınırı sunucu sayısıyla çarpar.

Hangi rate limiting algoritmaları kullanılır?

Dört yaklaşım yaygındır. Seçim, ani yoğunluğa ne kadar tolerans istediğine bağlıdır:

nginx'in oran sınırlama modülü, belgesine göre leaky bucket yöntemini kullanır. Giriş formu gibi hassas uçlarda sıkı bir pencere, genel API'de token bucket iyi bir başlangıçtır.

HTTP 429 ve Retry-After ne anlama gelir?

RFC 6585, 429 Too Many Requests durum kodunu tanımlar: kullanıcı belirli bir sürede çok fazla istek göndermiştir. Standarda göre yanıt, durumu açıklayan bilgi içermeli ve isteğe bağlı olarak Retry-After başlığı taşıyabilir. 429 yanıtları önbelleğe alınmamalıdır. Retry-After değeri, RFC 9110'a göre saniye cinsinden bir süre ya da bir tarih olabilir:

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 60

{"hata": "Çok fazla deneme. 60 saniye sonra yeniden dene."}
```

Sunucu tarafında iki kurala dikkat et. Hata mesajı, hesabın var olup olmadığını ele vermemeli. Var olan ve olmayan kullanıcı adı için aynı yanıtı döndür. İstemci tarafında ise 429 aldığında hemen yeniden deneme. Retry-After'a uy, yoksa bekleme süresini her denemede katla. Bu yönteme üstel geri çekilme denir. Çok sayıda istemci aynı anda yeniden denerse sunucu yine boğulur. Bekleme süresine küçük bir rastgele pay eklemek, istemcilerin aynı saniyede geri gelmesini önler.

Giriş formu kaba kuvvete karşı nasıl korunur?

Parola denemesine karşı tek bir IP sınırı yetmez. Saldırgan denemeleri çok sayıda adrese dağıtabilir. OWASP Authentication Cheat Sheet bu yüzden başarısız giriş sayacının IP adresine değil hesabın kendisine bağlanmasını önerir. Bir kilitleme politikasında üç değeri birlikte belirlemen gerekir: kaç hatalı denemede kilitleneceği, bu denemelerin hangi süre içinde sayılacağı ve kilidin ne kadar süreceği.

Kalıcı kilit tehlikelidir, çünkü saldırgan bilerek başkalarının hesabını kapatabilir. Daha iyi yaklaşım artan beklemedir. NIST SP 800-63B-4 de aynı yönde: bir hesapta art arda başarısız denemeleri en fazla 100 ile sınırlamayı zorunlu tutar. Kilidi yaklaştıkça artan bekleme süresi (örnekte 30 saniyeden bir saate kadar), bot tespiti ve risk temelli kontrolleri önerir. Başarılı girişten sonra o hesabın sayacının sıfırlanmasını da önerir.

İki sınırı birlikte kullan:

Saldırı araçlarının bu sınırlara nasıl takıldığını Hydra ve brute-force savunması yazısında görebilirsin. Parola doğru tahmin edilse bile girişi durduracak ikinci katman için iki adımlı doğrulama yazısına bak.

nginx'te rate limiting nasıl kurulur?

Aşağıdaki yapılandırma, giriş adresine aynı IP'den gelen istekleri ortalama dakikada 5 ile sınırlar. Kısa bir taşmaya 3 isteklik pay bırakır, fazlasını beklemeden reddeder:

limit_req_zone $binary_remote_addr zone=giris:10m rate=5r/m;

server {
location = /giris {
limit_req zone=giris burst=3 nodelay;
limit_req_status 429;
proxy_pass http://127.0.0.1:8080;
}
}
```

limit_req_zone satırı http bloğunda yer alır. Saniyede birden az istek için r/m yazılır. Önemli bir ayrıntı: nginx belgesine göre reddedilen isteklerin varsayılan durum kodu 503'tür. limit_req_status 429; satırını eklemezsen istemci, sunucunun çöktüğünü sanır. Canlıya almadan önce limit_req_dry_run ile sınırı kayıt modunda deneyebilirsin.

Bu örnek IP'ye göre sayar. Hesap başına sınırı ise uygulama kodunda, kullanıcı adını anahtar alarak kurarsın.

Sınır değerini nasıl belirlersin?

Doğru sayı, uygulamanın gerçek kullanımından çıkar. Tahminle konan sınır ya gerçek kullanıcıyı engeller ya da saldırganı hiç yavaşlatmaz. Şu sırayı izle:

1. Ölç: Her uç nokta için normal bir kullanıcının dakikada kaç istek attığını günlüklerden çıkar. Ortalamaya değil, en yoğun kullanıcılara bak.
2. Kayıt modunda başlat: Sınırı önce yalnız kayıt tutacak biçimde aç. Kimlerin takıldığını gör.
3. Uca göre ayır: Giriş ve kod doğrulama için sıkı, liste ve arama için daha gevşek değer seç.
4. Yapılandırmada tut: Sınırı koda gömme. Bir saldırı anında kodu yeniden yayınlamadan değeri sıkılaştırabilmelisin.
5. 429 sayısını izle: Ani artış, ya bir saldırının ya da hatalı çalışan bir istemcinin işaretidir. İkisi de incelemeye değer.

Rate limiting'i işe yaramaz hâle getiren hatalar nelerdir?

• İstemcinin gönderdiği başlığa güvenmek: Sınırı X-Forwarded-For başlığındaki adrese göre koyuyorsan ve bu başlığı yalnız kendi vekilinden kabul etmiyorsan, saldırgan her istekte farklı bir adres yazar.
• Vekilin adresini saymak: Uygulama bir vekilin arkasındaysa ve gerçek istemci adresini okumuyorsa bütün kullanıcılar tek istemci görünür. Sonuç ya herkesin engellenmesi ya da hiç kimsenin engellenmemesidir.
• Anahtarı normalleştirmemek: [email protected] ile [email protected] aynı hesapsa aynı sayaca yazılmalı. Büyük küçük harf ve boşluk farkını sayaçtan önce temizle.
• Sayacı yanlış sıfırlamak: IP sayacını o adresten gelen herhangi bir başarılı girişte sıfırlarsan, saldırgan araya kendi hesabıyla giriş ekleyerek sayacı sürekli sıfırlar.
• Sınırı tek uca koymak: Giriş korunurken parola sıfırlama ya da tek kullanımlık kod doğrulama ucu açık kalırsa saldırgan oradan dener.

Rate limiting tek başına yeterli mi?

Değil. Oran sınırlama saldırının hızını düşürür, saldırıyı ortadan kaldırmaz. Çok kaynaklı trafik için DDoS koruması, uygulama katmanındaki saldırı kalıpları için WAF gerekir. API tarafında istek sayısı kadar yanıt boyutu, işlem süresi ve SMS gibi ücretli hizmetlerin harcaması da sınırlanmalıdır. OWASP bunu API4:2023 Unrestricted Resource Consumption başlığıyla listeler, ayrıntısı OWASP API Top 10 yazısında.

Oran sınırını uygulamalı denemek istersen saha görevlerinde aynı isteği yüzlerce kez tekrarlayan bir kaynağı bulup sınırladığın ve sonucu yeniden doğruladığın bir senaryo var.

Kaynaklar

• RFC 6585: 429 Too Many Requests
• RFC 9110: Retry-After başlığı
• OWASP Authentication Cheat Sheet: Hesap kilitleme
• NIST SP 800-63B-4: Oran sınırlama
• nginx: ngx_http_limit_req_module