- Konu sahibi
- #1
Rate limiting, belirli bir IP, kullanıcı, API anahtarı veya oturumun belli bir sürede gönderebileceği istek sayısını sınırlar. DDoS koruması ise çok sayıda kaynaktan gelen saldırı trafiğini mümkün olduğunca sunucudan önce filtreleyerek ağ, uygulama ve kullanılabilirlik üzerindeki etkisini azaltır. Rate limiting bir istek kontrolü, DDoS koruması ise daha geniş kapsamlı bir trafik ve erişilebilirlik savunmasıdır. İkisi birbirinin alternatifi değil, farklı katmanlarda birlikte kullanılabilen önlemlerdir.
Rate limiting, istekleri bir sayaç veya kota mantığıyla değerlendirir. Örneğin giriş API’si için aynı IP’den kısa sürede çok fazla istek gelirse yeni istekler geçici olarak reddedilebilir. Sunucu genellikle bu durumda HTTP 429 yanıtı verir; istemci daha sonra tekrar denemelidir.
Kota yalnızca IP adresine göre konulmamalıdır. Ortak ağ kullanan gerçek kullanıcılar yanlışlıkla engellenebilir; saldırganlar da IP değiştirerek kuralı aşabilir. Uygulamaya göre kullanıcı hesabı, API anahtarı, oturum, cihaz sinyali veya uç nokta bazlı ayrı sınırlar daha uygun olabilir. Giriş, parola sıfırlama ve arama gibi pahalı işlemler genellikle herkese açık statik dosyalardan daha sıkı sınırlandırılır.
DDoS koruması, saldırı trafiğini ağ veya uygulamaya ulaşmadan önce azaltmaya, filtrelemeye ya da dağıtmaya çalışır. Ağ katmanındaki saldırılarda amaç bağlantı kapasitesinin, yönlendiricilerin veya sunucu kaynaklarının tükenmesini önlemektir. Uygulama katmanındaki saldırılarda ise HTTP isteklerinin davranışı, hedef uç nokta ve trafik örüntüsü incelenebilir.
Bir DDoS hizmeti kullanmak tek başına her kötüye kullanımı durdurmaz. Trafik hizmete ulaşsa bile uygulamaya özgü pahalı bir sorgu, kötü tasarlanmış bir API veya ele geçirilmiş geçerli hesaplar ayrıca rate limiting, kimlik doğrulama ve kaynak tüketimi kontrolleri gerektirebilir.
Rate limiting, DDoS savunmasının içinde kullanılan tekniklerden biri de olabilir. Fark, yalnız saldırgan sayısı değildir: sınırın uygulamaya ulaşmadan edge/ağ katmanında uygulanması ve hangi kaynağı koruduğu sonucu değiştirir. Tek IP’li yüksek trafik de bant genişliğini tüketebilir; çok kaynaklı düşük hacimli istekler de pahalı bir sorguyu hedefleyebilir.
Bir ürün arama uç noktanızın saniyede çok sayıda istek aldığını varsayalım. Tek bir istemci sürekli sorgu gönderiyorsa rate limiting bu istemciyi sınırlar; diğer kullanıcılar hizmeti kullanmaya devam edebilir. Ancak binlerce farklı cihaz aynı anda bağlantı açıp sunucunun ağ kapasitesini dolduruyorsa, uygulamadaki rate limiting kuralı istekleri değerlendiremeden önce sunucu erişilemez hale gelebilir. Bu durumda ağda veya CDN/koruma katmanında DDoS azaltma gerekir.
İki yaklaşımın karar farkı şöyledir:
Bu nedenle küçük ve kontrollü kötüye kullanımda önce uygun rate limiting; ağ kapasitesini etkileyen veya çok kaynaklı saldırı şüphesinde ise upstream/CDN düzeyinde DDoS azaltma değerlendirilir. Gerçek sistemlerde iki kontrolün birlikte bulunması daha sağlamdır.
Başarılı sonuç, yalnızca saldırı isteklerinin reddedilmesi değildir. Normal kullanıcıların kritik işlemleri sürdürebilmesi, uygulama kaynaklarının tükenmemesi ve koruma katmanının gerçek trafiği yanlışlıkla kesmemesi birlikte değerlendirilmelidir.
Birden fazla uygulama örneği varsa her süreçte bağımsız sayaç tutmak toplam kotanın örnek sayısıyla artmasına yol açabilir; ortak sayaç veya edge politikası gerekir. Proxy arkasında istemci IP’sini yalnız güvendiğiniz proxy’nin doğruladığı başlıktan alın; dışarıdan gelen her X-Forwarded-For değerini gerçek kimlik saymayın. Meşru kullanıcıları kilitleyen sınırsız hesap bazlı cezalar da saldırı aracına dönüşebilir.
Her şeyi IP başına sınırlamak: Ortak ağlardaki gerçek kullanıcıları topluca engelleyebilir. Kimlikli işlemlerde kullanıcı veya API anahtarını da dikkate alın.
Rate limiting’i DDoS koruması sanmak: İstek uygulamaya ulaşmadan önce bağlantı veya bant genişliği tükeniyorsa uygulama kuralı geç kalır.
Her uç noktaya aynı kotayı vermek: Hafif bir okuma isteğiyle veritabanı sorgusu veya parola denemesi aynı maliyette değildir.
Sadece 403 yanıtına güvenmek: Yanıt kodunu değiştirmek, saldırı trafiğinin ağ ve işlem maliyetini kendiliğinden ortadan kaldırmaz.
Hayır. Belirli bir kimliği veya istek kaynağını yavaşlatır; saldırgan çok sayıda kaynak kullanıyorsa veya trafik bağlantı kapasitesini dolduruyorsa ayrıca ağ seviyesinde azaltma gerekir.
Genellikle evet. DDoS katmanı hacimli trafiği azaltabilir; ancak geçerli kimlik bilgileriyle yapılan pahalı API çağrılarını, parola denemelerini ve tek hesabın kaynak tüketimini uygulama politikası daha iyi tanır.
Uygulamanın kritik ve pahalı işlemlerine rate limiting eklemek temel bir adımdır. Sunucuya erişim kesiliyor, bağlantı veya ağ kapasitesi tükeniyorsa sağlayıcı/CDN seviyesinde DDoS korumasını da yapılandırmalısınız.
Rate limiting nasıl çalışır?
Rate limiting, istekleri bir sayaç veya kota mantığıyla değerlendirir. Örneğin giriş API’si için aynı IP’den kısa sürede çok fazla istek gelirse yeni istekler geçici olarak reddedilebilir. Sunucu genellikle bu durumda HTTP 429 yanıtı verir; istemci daha sonra tekrar denemelidir.
Kota yalnızca IP adresine göre konulmamalıdır. Ortak ağ kullanan gerçek kullanıcılar yanlışlıkla engellenebilir; saldırganlar da IP değiştirerek kuralı aşabilir. Uygulamaya göre kullanıcı hesabı, API anahtarı, oturum, cihaz sinyali veya uç nokta bazlı ayrı sınırlar daha uygun olabilir. Giriş, parola sıfırlama ve arama gibi pahalı işlemler genellikle herkese açık statik dosyalardan daha sıkı sınırlandırılır.
DDoS koruması nasıl çalışır?
DDoS koruması, saldırı trafiğini ağ veya uygulamaya ulaşmadan önce azaltmaya, filtrelemeye ya da dağıtmaya çalışır. Ağ katmanındaki saldırılarda amaç bağlantı kapasitesinin, yönlendiricilerin veya sunucu kaynaklarının tükenmesini önlemektir. Uygulama katmanındaki saldırılarda ise HTTP isteklerinin davranışı, hedef uç nokta ve trafik örüntüsü incelenebilir.
Bir DDoS hizmeti kullanmak tek başına her kötüye kullanımı durdurmaz. Trafik hizmete ulaşsa bile uygulamaya özgü pahalı bir sorgu, kötü tasarlanmış bir API veya ele geçirilmiş geçerli hesaplar ayrıca rate limiting, kimlik doğrulama ve kaynak tüketimi kontrolleri gerektirebilir.
Rate limiting, DDoS savunmasının içinde kullanılan tekniklerden biri de olabilir. Fark, yalnız saldırgan sayısı değildir: sınırın uygulamaya ulaşmadan edge/ağ katmanında uygulanması ve hangi kaynağı koruduğu sonucu değiştirir. Tek IP’li yüksek trafik de bant genişliğini tüketebilir; çok kaynaklı düşük hacimli istekler de pahalı bir sorguyu hedefleyebilir.
Somut örnekle farkı
Bir ürün arama uç noktanızın saniyede çok sayıda istek aldığını varsayalım. Tek bir istemci sürekli sorgu gönderiyorsa rate limiting bu istemciyi sınırlar; diğer kullanıcılar hizmeti kullanmaya devam edebilir. Ancak binlerce farklı cihaz aynı anda bağlantı açıp sunucunun ağ kapasitesini dolduruyorsa, uygulamadaki rate limiting kuralı istekleri değerlendiremeden önce sunucu erişilemez hale gelebilir. Bu durumda ağda veya CDN/koruma katmanında DDoS azaltma gerekir.
İki yaklaşımın karar farkı şöyledir:
| Konu | Rate limiting | DDoS koruması |
|---|---|---|
| Ana hedef | İstemci veya işlem başına istek hızını sınırlamak | Saldırı trafiğinin hizmete ve altyapıya etkisini azaltmak |
| Uygulandığı yer | Uygulama, API geçidi, web sunucusu veya proxy | Ağ, CDN, trafik temizleme katmanı ve bazı durumlarda uygulama katmanı |
| Tipik sorun | Kötüye kullanım, otomasyon ve pahalı uç nokta tüketimi | Çok kaynaklı trafik, bağlantı veya bant genişliği taşması |
| Sınırlaması | Sunucuya ulaşan büyük trafik hacmini tek başına durduramaz | Uygulamaya özgü işlem maliyetini ve hesap kötüye kullanımını tek başına çözmez |
Bu nedenle küçük ve kontrollü kötüye kullanımda önce uygun rate limiting; ağ kapasitesini etkileyen veya çok kaynaklı saldırı şüphesinde ise upstream/CDN düzeyinde DDoS azaltma değerlendirilir. Gerçek sistemlerde iki kontrolün birlikte bulunması daha sağlamdır.
Uygulanabilir kurulum ve karar adımları
- Korunacak uç noktaları ve kaynak maliyetini belirleyin. Giriş, parola sıfırlama, arama, dosya oluşturma ve ödeme gibi işlemleri ayrı sınıflandırın.
- Her sınıf için kimlik türünü seçin. Kimliksiz isteklerde IP ve uç nokta; kimlikli isteklerde kullanıcı veya API anahtarı; ortak kullanılan işlemlerde ise bu ölçütlerin birleşimi kullanılabilir.
- Başarılı ve reddedilen istekleri ayrı izleyin. Limit dolduğunda tutarlı biçimde 429 döndürün, mümkünse yeniden deneme bilgisini belirtin ve istemcinin art arda daha hızlı denemesini engelleyin.
- Trafik sunucuya ulaşmadan önce kapasiteyi tüketiyorsa rate limit değerini sürekli artırmak yerine hosting, CDN veya ağ sağlayıcısının DDoS azaltma seçeneğini devreye alın.
- Normal kullanıcıların etkilenip etkilenmediğini kontrol edin. Ortak NAT, mobil ağ, arama motoru taraması veya meşru API istemcileri için ayrı ve doğrulanabilir politikalar tanımlayın.
- Saldırı sonrasında yalnız IP engellemekle yetinmeyin. Hangi uç noktanın, hesabın veya kaynak işleminin tüketildiğini inceleyip ilgili katmanda kuralı düzeltin.
Başarılı sonuç, yalnızca saldırı isteklerinin reddedilmesi değildir. Normal kullanıcıların kritik işlemleri sürdürebilmesi, uygulama kaynaklarının tükenmemesi ve koruma katmanının gerçek trafiği yanlışlıkla kesmemesi birlikte değerlendirilmelidir.
Birden fazla uygulama örneği varsa her süreçte bağımsız sayaç tutmak toplam kotanın örnek sayısıyla artmasına yol açabilir; ortak sayaç veya edge politikası gerekir. Proxy arkasında istemci IP’sini yalnız güvendiğiniz proxy’nin doğruladığı başlıktan alın; dışarıdan gelen her X-Forwarded-For değerini gerçek kimlik saymayın. Meşru kullanıcıları kilitleyen sınırsız hesap bazlı cezalar da saldırı aracına dönüşebilir.
Sık yapılan hatalar
Her şeyi IP başına sınırlamak: Ortak ağlardaki gerçek kullanıcıları topluca engelleyebilir. Kimlikli işlemlerde kullanıcı veya API anahtarını da dikkate alın.
Rate limiting’i DDoS koruması sanmak: İstek uygulamaya ulaşmadan önce bağlantı veya bant genişliği tükeniyorsa uygulama kuralı geç kalır.
Her uç noktaya aynı kotayı vermek: Hafif bir okuma isteğiyle veritabanı sorgusu veya parola denemesi aynı maliyette değildir.
Sadece 403 yanıtına güvenmek: Yanıt kodunu değiştirmek, saldırı trafiğinin ağ ve işlem maliyetini kendiliğinden ortadan kaldırmaz.
Kaynaklar
Sık sorulan sorular
Rate limiting saldırganı tamamen durdurur mu?
Hayır. Belirli bir kimliği veya istek kaynağını yavaşlatır; saldırgan çok sayıda kaynak kullanıyorsa veya trafik bağlantı kapasitesini dolduruyorsa ayrıca ağ seviyesinde azaltma gerekir.
DDoS koruması varsa uygulama içinde rate limiting gerekli midir?
Genellikle evet. DDoS katmanı hacimli trafiği azaltabilir; ancak geçerli kimlik bilgileriyle yapılan pahalı API çağrılarını, parola denemelerini ve tek hesabın kaynak tüketimini uygulama politikası daha iyi tanır.
İlk olarak hangisini kurmalıyım?
Uygulamanın kritik ve pahalı işlemlerine rate limiting eklemek temel bir adımdır. Sunucuya erişim kesiliyor, bağlantı veya ağ kapasitesi tükeniyorsa sağlayıcı/CDN seviyesinde DDoS korumasını da yapılandırmalısınız.
