Web sitesinde bot trafiği nasıl sınıflandırılır?

Web sitesindeki bot trafiğini yalnızca User-Agent bilgisine bakarak değil; isteğin kaynağı, davranış biçimi, doğrulanabilir kimliği ve sunucu üzerindeki etkisini birlikte değerlendirerek sınıflandırın. Pratikte her isteği doğrulanmış iyi bot, şüpheli veya bilinmeyen bot, kötü amaçlı bot ya da insan trafiği olarak etiketlemek yeterli bir başlangıçtır. Bunlar kesin kimlik kanıtı değil, güven düzeyi ve gerekçesi olan operasyonel etiketlerdir. Bot kimliği, amacı ve izin politikasını ayrı değerlendirin; doğrulanmış bot sizin sitenizde otomatik izinli demek değildir. Etiket kararını loglarda saklayın; böylece engelleme, hız sınırlama veya izleme kararlarını sonradan denetleyebilirsiniz.

Hangi sinyaller kullanılmalı?​

Tek bir sinyal güvenilir sınıflandırma için yeterli değildir. User-Agent kolayca taklit edilebilir; IP adresi de tek başına kesin kimlik kanıtı sayılmaz. Aşağıdaki sinyalleri birlikte inceleyin:

• Kimlik: User-Agent, istek yapılan yol, kullanılan HTTP başlıkları ve varsa botun resmî doğrulama yöntemi.
• Kaynak: IP adresi, ağ sağlayıcısı ve ters DNS sonucu. Ters DNS adı tek başına yeterli değildir; ileri DNS doğrulamasıyla tutarlı olup olmadığı da kontrol edilmelidir.
• Davranış: İstek sıklığı, aynı sayfaların tekrar tekrar çağrılması, robots.txt ve site haritasına uyum, oturum açma veya yönetim yollarına yönelme.
• Sonuç: Çok sayıda hata, arka arkaya parola denemesi, pahalı arama sorguları veya olağan dışı bant genişliği kullanımı.
• İçerik işleme: JavaScript çalıştırma, çerez kabul etme ve sayfalar arasında insan davranışına benzeyen geçişler. Bunlar yardımcı sinyallerdir; tek başına bot kanıtı değildir.

Meşru arama motoru tarayıcıları veya hizmet botları için sağlayıcının yayımladığı doğrulama yöntemini kullanın. Sadece User-Agent içinde tanınan bir ad bulunması, isteğin gerçekten o hizmetten geldiğini göstermez.

Uygulanabilir sınıflandırma adımları​

1. Web sunucusu, CDN veya güvenlik duvarı loglarında en az zaman, istemci IP'si, User-Agent, istek yolu, durum kodu, yanıt boyutu ve istek süresini toplamaya başlayın. Mümkünse istek kimliği ve uygulamanın ürettiği hata türünü de kaydedin.
2. Aynı IP, User-Agent ve oturum bilgisiyle yapılan istekleri kısa zaman aralıklarında gruplayın. Aynı kaynaktan gelen hızlı ve tekrarlı istekleri, tek tek isteklerden daha anlamlı bir davranış göstergesi olarak değerlendirin.
3. Bilinen bir bot iddiasını bağımsız olarak doğrulayın. DNS sonucu tutarsızsa, kaynak ağı güvenilir değilse veya davranış hizmetin beklenen amacıyla uyuşmuyorsa isteği doğrulanmamış kabul edin.
4. Her gruba bir sınıf ve gerekçe atayın: verified_good, human, unknown veya malicious. Bir isteğin neden bu sınıfa girdiğini kısa bir kural koduyla saklayın; örneğin ua_spoof_suspected veya login_burst.
5. Önce unknown trafiği gözlemleyin. Kaynak tüketimi veya saldırı belirtisi varsa hız sınırlayın; açıkça zararlı davranışta engelleme ya da uygulama katmanında ek doğrulama uygulayın. Meşru olabilecek trafiği yalnızca belirsizlik nedeniyle kalıcı olarak engellemeyin.
6. Loglardaki sınıf dağılımını, hata oranını ve hedeflenen yolları periyodik olarak inceleyin. Yanlış sınıflandırılan örnekleri kurala ekleyerek kararları düzeltin.

Varsayımsal örnek​

Bir içerik sayfasına gelen üç istek düşünün. İlk istek, kimliği bağımsız doğrulanmış bir tarayıcıdan gelir; robots.txt'ye uyar, sayfaları düşük hızda dolaşır ve hata üretmez. Bu istek verified_good olarak işaretlenebilir. İkinci istek kendisini aynı tarayıcı gibi tanıtır, fakat doğrulama başarısızdır ve saniyeler içinde binlerce farklı URL ister. Bu trafik unknown olarak başlayıp davranış sürdüğünde malicious sınıfına alınabilir. Üçüncü kaynak yönetim giriş sayfasına kısa sürede çok sayıda başarısız parola isteği gönderir; User-Agent normal görünse bile davranış açıkça saldırı göstergesidir.

Aşağıdaki tablo, sınıf ile uygulanacak ilk tepkiyi ayırır:


Tablo bir karar başlangıcıdır; aynı IP'den farklı kullanıcıların çıkabildiği NAT, mobil ağ ve proxy ortamlarında IP'yi tek başına kişi veya bot kimliği olarak yorumlamayın.

Hızlı istek veya JavaScript/çerez yokluğu insanı kesin dışlamaz; erişilebilirlik araçları, API istemcileri ve gizlilik ayarları aynı sinyali üretebilir. Kimliği doğrulanmış arama tarayıcısı, AI eğitim tarayıcısı ve kullanıcı adına çalışan ajan için izin politikası farklı olabilir. DNS doğrulamasında tam alan sınırı kullanın: benzer görünen sahte son ekleri kabul etmeyin. Cookie/tokenı düz loglamayın; IP ve davranış verisini sınırlı erişim ve gerekli saklama süresiyle tutun.

Sık yapılan hatalar​

Yalnız User-Agent'a güvenmek en yaygın hatadır; saldırganlar bunu kolayca değiştirebilir. Her hızlı isteği kötü bot saymak da doğru değildir; önbellek temizliği, izleme hizmetleri veya büyük bir içerik güncellemesi kısa süreli yoğunluk yaratabilir. robots.txt'yi güvenlik mekanizması sanmak başka bir hatadır; bu dosya uyumlu tarayıcılar için bir yönergedir, zorunlu erişim kontrolü değildir. Son olarak, yalnızca engelleme uygulayıp log tutmamak sorunun kaynağını ve yanlış pozitifleri görmenizi engeller. Önce ölçün, gerekçeli sınıflandırın, sonra sınıfa uygun tepki verin.

Kaynaklar​

• Cloudflare: Bot amaçları ve davranışları
• Google: Bot kaynağı doğrulama

Sık sorulan sorular​

Bot sınıfını IP adresine göre kalıcı olarak saklamak doğru mu?​

Genellikle hayır. IP'ler değişebilir ve aynı adres birden fazla kullanıcıyı veya hizmeti temsil edebilir. Sınıflandırmayı zaman aralığı, davranış ve doğrulama kanıtıyla birlikte değerlendirin.

Bilinmeyen botu hemen engellemeli miyim?​

Kaynak tüketimi veya saldırı belirtisi yoksa önce gözlem ve hız sınırlama daha güvenlidir. Yönetim ve kimlik doğrulama yollarına yönelik açık kötüye kullanım varsa engelleme kararını ilgili olay kayıtlarıyla birlikte uygulayın.