Botnet koruması, kötü amaçlı yazılım bulaşmış çok sayıda cihazdan gelen otomatik istekleri tanımlayıp sınırlamaya yönelik katmanlı bir savunmadır. Web sitesi için doğru yaklaşım, yalnızca trafiği engellemek değil; giriş denemeleri, içerik tarama ve kaynak tüketimini ayrı değerlendirerek meşru ziyaretçiyi mümkün olduğunca korumaktır.
Botnet, uzaktan yönetilen ve aynı görevi birlikte yapan ele geçirilmiş cihazlar topluluğudur. Bu cihazlardan gelen istekler farklı IP adreslerine, ülkelere ve kullanıcı aracısı bilgilerine dağılabildiği için tek bir IP’yi engellemek çoğu zaman yeterli olmaz. Amaç; hesap denemek, formları kötüye kullanmak, içerik kopyalamak veya sunucunun işlem ve bant genişliği kaynaklarını tüketmek olabilir.
Bu tehdit, DDoS ile aynı şey değildir. DDoS koruması çoğunlukla yoğun ağ trafiğinin hizmeti erişilemez duruma getirmesini azaltmaya odaklanır. Botnet koruması ise düşük hızda çalışan, giriş sayfasına tekrar tekrar istek atan veya normal tarayıcı davranışını taklit eden otomasyonları da ele alır. İki savunma birlikte bulunabilir; ancak birinin varlığı diğerinin kapsamını otomatik olarak kanıtlamaz.
İlk karar, bot trafiğinin hangi işlevi hedeflediğini belirlemektir. Sorun kullanıcı hesaplarına yönelik denemelerse giriş uç noktasında hız sınırlama, başarısız deneme takibi ve çok faktörlü kimlik doğrulama önem kazanır. Sorun herkese açık API veya ürün kataloğunun yoğun taranmasıysa istek profili, önbellekleme ve otomasyon tespiti daha anlamlıdır. Trafik ağ seviyesinde ani ve çok yüksek hacme çıkıyorsa sağlayıcının ağ katmanındaki DDoS kapasitesi ayrıca incelenmelidir.
Hız sınırlama, belirli bir istemcinin belirli bir zaman aralığında kaç istek gönderebileceğini sınırlar. Bu yöntem giriş formları ve parola sıfırlama gibi pahalı işlemlerde yararlıdır; fakat yalnız IP adresine dayanırsa ortak ağ kullanan gerçek kullanıcıları da etkileyebilir. Davranış analizi, çerez, istek sırası, tarayıcı özellikleri veya hesap hareketleri gibi sinyalleri birlikte değerlendirebilir; bunun ayrıntıları kullanılan CDN, WAF veya hosting hizmetine göre değişir.
Örneğin, varsayımsal olarak küçük bir üyelik sitesinde gece boyunca farklı adreslerden aynı kullanıcı adlarına yüzlerce giriş denemesi görülüyor olsun. Sunucu yanıt süreleri normal, fakat başarısız giriş kayıtları artıyorsa ilk ihtiyaç geniş bant temizleme değil, giriş uç noktasına oran sınırlaması ve hesap güvenliğidir. Buna karşılık aynı siteye ait sayfalar farklı ülkelerden yoğun biçimde isteniyor ve işlemci kullanımı yükseliyorsa içerik önbelleği, bot davranışı kuralları ve kaynak tüketimi birlikte değerlendirilmelidir.
Bir sağlayıcının “bot koruması” ifadesini yeterli kabul etmeden önce hangi katmanda çalıştığını sorun. Koruma DNS veya CDN önünde mi uygulanıyor, yoksa yalnızca web sunucusundaki bir eklentiye mi bırakılıyor? Kural oluşturma, olay kaydı, istisna tanımlama ve yanlış pozitifleri inceleme imkânı var mı? Giriş trafiğini, arama isteklerini ve API çağrılarını aynı kuralla ele almak, meşru kullanımın gereksiz yere engellenmesine yol açabilir.
Somut bir değerlendirme için önce korunan alan adını ve kritik uç noktaları listeleyin: giriş, parola sıfırlama, iletişim formu ve varsa API yolları. Ardından hizmetin olay ekranında isteğin zamanını, hedef yolunu, uygulanan kararı ve kullanılan sinyali gösterip göstermediğini kontrol edin. Kayıt yalnızca “engellendi” diyorsa hangi kuralın çalıştığını anlamak zorlaşır; bu durum sorun giderme ve yanlış engellemeyi düzeltme sürecini sınırlar.
Giriş sayfasında korumayı sertleştirmeyi düşünüyorsanız önce başarısız giriş oranını ve normal kullanıcı akışını ölçün. Kural yalnızca aynı IP’den gelen denemeleri sınırlıyorsa dağıtık botnet trafiğini tam olarak kesmeyebilir; hesap, cihaz davranışı ve istek hızı gibi ek sinyaller gerekiyorsa sağlayıcının bunları destekleyip desteklemediğini doğrulayın. Yalnızca içerik taraması sorun oluşturmuyorsa giriş ekranına CAPTCHA eklemek yerine ilgili URL grubuna daha dar bir kural uygulamak daha uygun olabilir.
Değişiklik yapmadan önce mevcut kuralı, eşik değerini ve varsa istisnaları kaydedin. Aynı anda birden fazla ayarı değiştirmeyin; aksi halde hangi düzenlemenin sonucu etkilediği anlaşılamaz. Sağlayıcının kontrol panelinde koruma durumunun etkin olduğunu, ilgili alan adının doğru politikaya bağlı bulunduğunu ve olay kayıtlarının yeni zaman damgalarıyla oluştuğunu kontrol edin.
Daha sonra kontrollü bir doğrulama yapın: normal bir tarayıcıyla giriş, parola sıfırlama ve temel sayfa görüntüleme akışını deneyin; yetkili test ortamınız varsa beklenen sınırı aşmayan otomatik istekleri de gözlemleyin. Meşru istekler geçiyor, şüpheli istekler olay kaydında doğru kuralla sınırlanıyor ve uygulama loglarında beklenmeyen hata oluşmuyorsa politika amacına uygundur. Kullanıcılar engelleniyorsa önce istisnayı genişletmek yerine eşiği, hedef URL’yi ve ortak ağ etkisini inceleyin.
Koruma etkinleştirildiği halde sunucu kaynakları tükenmeye devam ediyorsa bunun botnet yerine pahalı bir uygulama sorgusu, önbelleksiz içerik veya ağ katmanı saldırısı olabileceğini varsayın. Yeni olay kayıtlarını aynı zaman aralığındaki sunucu ve uygulama kayıtlarıyla karşılaştırın. Sorun sürerse önceki kaydettiğiniz değere geri dönmek, tek kuralı geçici olarak daraltmak ve hizmet sağlayıcının olay inceleme kanalına başvurmak daha güvenlidir; güvenlik kontrollerini bütünüyle kapatmak güvenli bir düzeltme değildir.
Web barındırma ve sunucu güvenliği seçeneklerini incelerken hizmet kapsamını ayrıca karşılaştırmak için İyibirNet kaynaklarına göz atabilirsiniz. Sonraki adım olarak kendi sitenizde en pahalı veya en sık çağrılan üç uç noktayı belirleyip her biri için beklenen kullanıcı davranışını ve kabul edilebilir istek yoğunluğunu yazılı hale getirin.
Copyright © 2026 Tüm Hakları Saklıdır.
Türkiye (Türkçe)
Worldwide (English)