Bir betik saniyede yüzlerce istek gönderiyor. Sunucunuz ayakta ama yavaşladı, veritabanı zorlanıyor ve gerçek kullanıcılar bekliyor. Saldırı değil — yalnızca kimse bir sınır koymamış.
Bu yazı, VDS sunucu üzerinde istek hızını sınırlamayı ele alıyor.
Neden Gerekli?
Sınırsız istek kabul eden uç noktalar birkaç riski aynı anda taşır:
- Kaynak tüketimi. Tek bir istemci sunucuyu doyurabilir.
- Şifre deneme saldırıları. Giriş formları hedeftir.
- Veri kazıma. İçeriğiniz toplu olarak indirilir.
- Maliyet artışı. Dış servis çağrıları ücretlidir.
- Form kötüye kullanımı. Spam gönderimi.
Dördüncü madde gözden kaçan bir kalemdir: her isteğinizde ücretli bir dış servisi çağıran bir uç nokta, kötüye kullanıldığında doğrudan faturanızı şişirir.
Bu, teknik bir sorun olmadan önce mali bir sorundur ve genellikle ay sonunda fark edilir.
Hangi Katmanda Sınırlanmalı?
Hız sınırlama farklı seviyelerde uygulanabilir:
| Katman | Özelliği |
|---|---|
| Güvenlik duvarı | En ucuz, ama yalnızca IP bazlı |
| Web sunucusu | Uygulama çalışmadan engeller |
| Uygulama | En esnek, ama kaynak tüketir |
| Ters vekil veya CDN | Sunucuya hiç ulaşmaz |
İkinci satır çoğu senaryo için doğru dengeyi kurar: web sunucusu seviyesinde reddedilen bir istek, PHP sürecini hiç başlatmaz ve maliyeti neredeyse sıfırdır.
Uygulama seviyesinde sınırlama yapılırsa, isteği reddetmek için bile uygulamanın çalışması gerekir — ki bu, saldırı anında tam olarak kaçınmak istediğiniz durumdur.
Neye Göre Sınırlamalı?
Sınırın kime uygulanacağı önemli bir karardır:
- IP adresi. En yaygın, ama paylaşımlı IP'lerde sorunlu.
- Kullanıcı hesabı. Giriş yapmışlar için adil.
- API anahtarı. Servis kullanıcıları için.
- Oturum. Kolayca sıfırlanabilir.
- Uç nokta bazında. Farklı yollara farklı sınır.
Birinci maddedeki sorun kurumsal kullanıcılarda ortaya çıkar: tek bir ofisten çıkan yüzlerce çalışan aynı IP adresinden görünür ve IP bazlı sınır hepsini birden etkiler.
Bu yüzden giriş yapmış kullanıcılar için hesap bazlı, anonim ziyaretçiler için IP bazlı sınır uygulamak daha adil bir yapı kurar.
Sınırlama Yöntemleri
Sayacın nasıl tutulacağı davranışı belirler:
- Sabit pencere: Basit, ama pencere sınırında iki katı geçebilir.
- Kayan pencere: Daha adil, biraz daha karmaşık.
- Jeton kovası: Ani yükü tolere eder, ortalamayı korur.
Üçüncü yöntem gerçek kullanım desenine en uygun olanıdır: jeton kovası, kısa süreli yoğunluğa izin verirken uzun vadeli ortalamayı sınırlar — normal kullanıcılar engellenmez, sürekli yük ise durdurulur.
Birinci yöntemin sorunu ise sınır anındadır. Pencere başında ve sonunda yapılan istekler, kısa bir aralıkta sınırın iki katına ulaşabilir.
Doğru Yanıt Vermek
Sınır aşıldığında dönülecek yanıtın kuralları vardır:
| Öğe | İşlevi |
|---|---|
| 429 durum kodu | İstemci bunu anlar |
| Bekleme süresi başlığı | Ne zaman tekrar denenecek |
| Kalan hak bilgisi | İstemci kendini ayarlar |
| Açıklayıcı mesaj | Geliştirici anlar |
İkinci satır iyi niyetli istemcilerle işbirliğini mümkün kılar: bekleme süresini bildiren bir yanıt, düzgün yazılmış bir istemcinin kendini yavaşlatmasını sağlar — sürekli yeniden denemek yerine bekler.
Bu bilgi verilmezse istemciler agresif biçimde yeniden dener ve durum kötüleşir.
Giriş Formları İçin Özel Durum
Kimlik doğrulama uç noktaları farklı ele alınmalıdır:
- Sınır çok daha düşük olmalı. Dakikada birkaç deneme.
- Kullanıcı adı bazında da sayılmalı. IP değiştirilebilir.
- Kademeli gecikme uygulanmalı. Her hatada süre artsın.
- Başarılı girişte sayaç sıfırlanmalı.
- Hesap kilitleme dikkatli kullanılmalı.
İkinci madde dağıtık denemeleri yakalar: yalnızca IP bazlı sayım yapılırsa, farklı adreslerden aynı hesaba yapılan denemeler görünmez kalır.
Beşinci madde ise bir tuzağa dikkat çeker. Belirli sayıda hatalı denemede hesabı kilitlemek, saldırganın istediği kullanıcıyı bilerek kilitlemesine imkân verir — bu, bir hizmet engelleme yöntemine dönüşür.
İstisnalar
Bazı isteklerin sınır dışında tutulması gerekir:
- İzleme sistemleri. Sağlık kontrolü engellenmemeli.
- Arama motoru botları. Makul hızda taramaya izin verin.
- Kendi iç servisleriniz.
- Ödeme sağlayıcı bildirimleri.
Dördüncü madde ciddi bir iş kaybına yol açabilir: ödeme sağlayıcısının gönderdiği bildirim hız sınırına takılırsa, siparişler onaylanmadan kalır.
Bu tür dış servis bildirimleri genellikle belirli IP aralıklarından gelir ve beyaz listeye alınmalıdır.
Bu istisnaları yapılandırma dosyasında tanımlayabildiğiniz VDS sunucu ortamında, uç nokta bazında farklı kurallar kurmak mümkündür.
Sınırın Etkisini İzlemek
Kural koyduktan sonra takip edilmesi gerekenler:
- Kaç istek reddediliyor?
- Hangi uç noktalarda?
- Gerçek kullanıcılar etkileniyor mu?
- Reddedilenler tekrar deniyor mu?
Üçüncü madde en kritik kontroldür: çok sıkı bir hız sınırı, saldırganı değil gerçek kullanıcıları engeller ve bunu ancak şikayet geldiğinde öğrenirsiniz.
Bu yüzden yeni bir sınır önce yalnızca kayıt modunda çalıştırılmalıdır — kim engellenecekti sorusunun cevabı, kuralı canlıya almadan görülür.
Sonuç
Hız sınırlamada en önemli karar hangi katmanda uygulanacağıdır: web sunucusu seviyesinde reddedilen bir istek PHP sürecini hiç başlatmaz ve maliyeti neredeyse sıfırdır. Sınırı yalnızca IP bazında kurmayın — kurumsal ofislerde yüzlerce çalışan aynı adresten görünür. Giriş formlarında kullanıcı adı bazında da sayın, ancak hesap kilitlemede dikkatli olun: otomatik kilitleme, saldırganın istediği hesabı bilerek kilitlemesine imkân verir. Ve yeni kuralı önce kayıt modunda çalıştırın.
Sıkça Sorulan Sorular (SSS)
Hız sınırını hangi katmanda kurmalıyım?
Mümkünse web sunucusu veya ters vekil seviyesinde. Orada reddedilen bir istek uygulamanızı hiç başlatmaz ve neredeyse hiç kaynak tüketmez. Uygulama seviyesinde sınırlama yaparsanız, isteği reddetmek için bile uygulamanın çalışması gerekir.
Sadece IP bazlı sınır yeterli mi?
Değil. Kurumsal ofislerde yüzlerce çalışan aynı IP adresinden görünür ve hepsi birden etkilenir. Giriş yapmış kullanıcılar için hesap bazlı, anonim ziyaretçiler için IP bazlı sınır uygulamak daha adil bir yapı kurar.
Giriş formunda hesabı kilitlemeli miyim?
Dikkatli olun. Belirli sayıda hatalı denemede otomatik kilitleme, saldırganın istediği kullanıcıyı bilerek kilitlemesine imkân verir ve bir hizmet engelleme yöntemine dönüşür. Kademeli gecikme genellikle daha güvenli bir çözümdür.
Gerçek kullanıcıları engellemekten nasıl kaçınırım?
Yeni kuralı önce yalnızca kayıt modunda çalıştırın — kimin engelleneceğini kuralı canlıya almadan görürsünüz. Ayrıca izleme sistemleri, arama motoru botları ve ödeme sağlayıcı bildirimlerini beyaz listeye almayı unutmayın.
