Hız Sınırlama: Botlara Karşı Akıllı Savunma

Site yavaşladı, sunucu logu tek bir IP'den gelen tekrarlayan isteklerle doldu ve gerçek kullanıcılar da tam bu sırada sayfayı yarıda bırakıyor. Eğer şu anda bu noktaya geldiyseniz, muhtemelen hız sınırlamayı düşünüyorsunuz. Ancak Nginx'te basit bir kural yazıp bunu tüm siteye uygulamadan önce, bu aracın iki ucu keskin bir kılıç olduğunu bilmelisiniz. Yanlış yapılandırma, sağlıklı trafiğinizi de kesebilir.

Faydalı bot ile zararlı botu nasıl ayırt ederiz?

Gördüğüm ilk hata, tüm botların tek seferde engellenmesidir. Googlebot ve Bingbot gibi arama motoru botları sitenizi serbestçe tarayabilmelidir. Onları sınırlarsanız, sitenin arama sonuçlarındaki sıralaması düşer ve birkaç hafta sonra organik trafiğin yarıya indiğini fark edersiniz.

Ayırt etme yolu, User-Agent'ı incelemek ve IP'yi doğrulamaktır. Google kendi resmi IP listesini yayınlar. Faydalı bir bot genellikle:

• Bildirilen ve sabit IP'lerden gelir.
• Öngörülebilir davranış sergiler ve sayfaları mantıklı aralıklarla okur.
• robots.txt'e uyar.

Buna karşılık zararlı bot (scraper, şifre deneme botları veya içerik kazıma araçları) genellikle sahte User-Agent taşır, değişken IP'lerden gelir ve kısa aralıklarla patlama şeklinde istekler gönderir. Gerçek deseni görmek için logu şu komutla inceleyin:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Bu komut en yoğun 20 IP'yi gösterir. Bir IP bir saat içinde 5000 istek gönderdiyse, o bir tarayıcı arkasındaki kullanıcı değil, zararlı bir bottur.

Hız sınırlamayı nereye uygulamalıyız?

Hız sınırlamanın uygulandığı yer, sınırlamanın kendisi kadar önemlidir. Her biri kendi kullanım alanına sahip üç katman vardır.

Birinci katman: Web sunucusu (Nginx veya Apache)

Bu, trafiğe en yakın katmandır ve en hızlı yanıtı verir. Nginx'te bu iş limit_req modülü ile yapılır:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

server {
    location /login/ {
        limit_req zone=mylimit burst=5 nodelay;
        limit_req_status 429;
    }
}

Bu yapılandırma, her IP'nin saniyede en fazla 10 istek gönderebileceğini, burst olarak 5 ek isteğe izin verildiğini söyler. 403 yerine 429 durum kodu döndürülür, böylece istemci erişiminin yasaklandığını değil, geçici olarak sınırlandığını anlar.

İkinci katman: Güvenlik duvarı veya CDN

Trafiğiniz CDN üzerinden geçiyorsa, sınırlamayı tam orada uygulayın. Avantajı, zararlı isteklerin sunucunuza hiç ulaşmaması ve bant genişliği tüketmemesidir. Hacimsel saldırı senaryoları için, her şeyi tek bir sunucuda yönetmeye çalışmak yerine bu katmanı DDoS koruması ile birleştirmek daha mantıklıdır.

Üçüncü katman: Uygulama

Kod düzeyinde (örneğin PHP veya Python'da) sınırlama daha fazla esneklik sağlar. Yalnızca IP'ye göre değil, giriş yapmış kullanıcıya göre de sınırlama tanımlayabilirsiniz. Ancak maliyeti, zararlı isteklerin uygulama katmanına kadar gelmesi ve sunucu kaynaklarını tüketmesidir. Bu katmanı tüm site için değil, giriş ve kayıt gibi hassas endpoint'leri korumak için saklayın.

İşte burada hata yapıyorlar

Pratikte gördüğüm en büyük hata, tüm siteye çok düşük bir hızla hız sınırlaması uygulamaktır. Örneğin biri tüm yollara rate=2r/s koyar. Sonuç? Bir sayfayı açan ve tarayıcısı CSS, JS ve görseller için aynı anda 15 istek gönderen kullanıcı, anında 429 hatası alır. Site ona eksik yüklenir, görseller yüklenmez ve siteyi bozuk sanır.

Belirtisi de açıktır: Logda 429 hatası ana sayfalar için değil, .css ve .js istekleri için kaydedilir. Bu deseni görürseniz, sınırlamayı statik dosyalardan kaldırın ve yalnızca dinamik endpoint'lere uygulayın.

Aşırı engellemenin maliyeti

Uyguladığınız her sınırlamanın bir maliyeti vardır: Gerçek kullanıcıyı da dışarıda bırakabilir. Paylaşımlı ağlardan (ofis, üniversite veya mobil operatör NAT'ı arkasından) gelen kullanıcıların tümü aynı IP'ye sahiptir. Sınırlamayı IP'ye göre koyarsanız, yoğun kullanan bir kullanıcı diğerlerini kurban edebilir.

Çözüm, sınırlamayı yalnızca IP'ye göre değil, IP ve yol kombinasyonuna göre tanımlamaktır. /login gibi hassas yollar için daha katı davranın, genel sayfalar için daha cömert olun. Kararların basit bir tablosu:

Daha az dikkat edilen bir nokta: Hız sınırlama, kimlik doğrulamanın yerini tutmaz. Giriş endpoint'iniz sözlük saldırısına karşı savunmasızsa, hız sınırlama yalnızca saldırının hızını azaltır, onu durdurmaz. Yanında birkaç başarısız denemeden sonra hesap kilitleme ve iki adımlı kimlik doğrulama da bulunmalıdır.

Sınırlamanın doğru çalıştığını nasıl anlarız?

Ayarları uyguladıktan sonra iki şeyi ölçmelisiniz. Birincisi, logdaki 429 hata oranı. Bu sayı aniden yükseldiyse, sınırlama aşırı katıdır. İkincisi, sunucu yanıt süresi (TTFB). Sınırlama doğru çalışıyorsa, zararlı istekler artık backend'e ulaşmadığı için TTFB düşmelidir.

Test için ab veya wrk gibi araçlar kullanın ve sitenin yük altındaki davranışını simüle edin:

ab -n 1000 -c 50 https://example.com/login/

Bu testten sonra site normal kullanıcılar için yavaşladıysa veya hata verdiyse, sınırlamanız aşırı agresiftir. Tam bu anda altyapı sağlığını kontrol etmek için servislerin anlık durumunu kontrol edin, böylece sorunun sınırlamadan mı yoksa sunucudan mı kaynaklandığından emin olun.

Pratik bir not: Hız sınırlama loglarını mutlaka saklayın. Daha sonra kimin ve ne zaman saldırdığını anlamak isterseniz, bu loglar tek kaynağınızdır. Log saklamanın önemi hakkında Denetim logu nedir ve nasıl bozulmadan saklanır? yazısında daha fazla açıklama yaptım.

Sık sorulan sorular

Hız sınırlama ile eşzamanlılık sınırlaması arasındaki fark nedir?

Hız sınırlama, birim zamandaki istek sayısını kontrol eder (örneğin saniyede 10 istek), eşzamanlılık sınırlaması ise aynı anda açık bağlantı sayısını sınırlar. Scraper botlarıyla mücadelede hız sınırlama daha etkilidir. Bir istemcinin kaynakları işgal etmesini önlemek için eşzamanlılık sınırlaması daha işe yarar. Pratikte her ikisini birlikte kullanın.

Hız sınırlama Googlebot'a da uygulanır mı?

Evet, kuralınız IP tabanlıysa ve Google'ın IP'sini istisna tutmazsanız, Googlebot da sınırlanır. Bu, sitenin sıralamasının düşmesine neden olur. Doğru yol, Google'ın resmi IP'lerini beyaz listeye almak veya yalnızca gerçek Google botunun sınırlamadan muaf tutulması için ters DNS doğrulaması kullanmaktır.

Hız sınırlamayı uyguladıktan sonra kullanıcılar neden 429 hatasından şikayet ediyor?

Genellikle hızı statik dosyaları hesaba katmadan tüm site için ayarladığınız içindir. Tarayıcı tek bir sayfayı görüntülemek için onlarca istek gönderir. Sınırlamayı dinamik ve hassas yollara uygulayın, CSS, JS ve görselleri bundan muaf tutun.

Hız sınırlamayı Nginx'te mi yoksa CDN'de mi ayarlamak daha iyi?

Trafiğiniz CDN üzerinden geçiyorsa, sınırlamayı CDN'de uygulamak daha iyidir çünkü zararlı istekler sunucunuza ulaşmaz ve kaynak tasarrufu sağlanır. Ancak uygulama mantığı üzerinde daha hassas kontrol gerekiyorsa (örneğin giriş yapmış kullanıcıya göre sınırlama), Nginx katmanı veya uygulamanın kendisi daha iyi bir seçenektir. En iyi sonuç her iki katmanın birleştirilmesiyle elde edilir.

Şu anda bir bot saldırısıyla karşı karşıyaysanız ve nereden başlayacağınızı bilmiyorsanız, önce logu inceleyin, ardından sınırlamayı yalnızca hassas yollara uygulayın ve her değişiklikten sonra sitenin davranışını ölçün. Daha karmaşık senaryolar veya hacimsel saldırılar için, ServerNet sunucu güvenliği hizmetleri sizi manuel yapılandırmalarla uğraştırmadan savunma katmanlarını sağlayabilir.