Bot koruması neyi çözmeye çalışır?
Bot koruması, bir isteğin gerçek bir kullanıcıdan mı yoksa otomasyondan mı geldiğini ayırmaya çalışır. Amaç tüm botları kapatmak değildir. Arama motoru tarayıcısı gibi istediğiniz botlara izin verirken, içerik kazıyan, hesap deneyen veya stok toplayan botları durdurursunuz.
Bunun tek bir kesin cevabı yoktur. Her yöntem bir sinyal verir ve saldırgan bu sinyali taklit etmeye çalışır. Pratik hedef, saldırının maliyetini kazancın üzerine çıkarmaktır. WAF bilinen saldırı kalıplarını yakalar; bot koruması ise isteğin kimden geldiğine bakar.
Hangi bot türleri var?
| Tür | Örnek | Genelde ne yapmalı |
|---|---|---|
| İyi tarayıcılar | Arama motoru botları | İzin ver, kimliğini doğrula |
| Kazıyıcılar (scraper) | Fiyat, içerik toplayanlar | Hız sınırla, doğrulama iste |
| Credential stuffing | Sızan parolaları giriş formunda deneyenler | Giriş yolunu ayrıca koru, çok faktörlü doğrulama |
| Stok toplayıcılar (scalper) | Sınırlı ürünü kapan botlar | Satın alma yolunda güçlü doğrulama |
| Hacimsel botlar | HTTP seli üretenler | Otomatik doğrulama, rate limit |
Credential stuffing özellikle zordur, çünkü istekler sıradan giriş denemelerine benzer. Her IP'den birkaç deneme gelir ve toplam hacim düşük kalır.
Bot tespiti hangi katmanlarla yapılır?
Katmanlar birbirini tamamlar; tek biri atlatıldığında diğerleri skoru etkiler.
- IP itibarı. Bilinen kötü amaçlı ağ aralıkları ve veri merkezi blokları şüphe puanı taşır. Bu katman ucuzdur ama NAT arkasındaki meşru kullanıcıları da etkileyebilir.
- TLS ve HTTP parmak izleri. İstemcinin TLS el sıkışması ve HTTP/2 ayarları hangi yazılım yığınını kullandığını gösterir. Ayrıntılar için TLS parmak izi rehberine bakın.
- Davranış. Fare ve dokunma hareketi, yazma ritmi, sayfa akışı. İnsan düzensizdir, basit botlar fazla düzenlidir.
- Challenge. İstemciden bir iş yapmasını istersiniz: bulmaca çözmek, hesaplama yapmak, JavaScript çalıştırmak.
Challenge türleri nasıl karşılaştırılır?
| Tür | Kullanıcı maliyeti | Gizlilik | Erişilebilirlik | Ana zayıflık |
|---|---|---|---|---|
| Görsel/tıklamalı CAPTCHA | Yüksek, her seferinde bulmaca | Çoğu zaman üçüncü taraf betik ve çerez | Zayıf | Model ve insan çözücü servisleri |
| Proof-of-work | Düşük, birkaç saniye CPU | Üçüncü tarafa veri gerekmez | İyi, etkileşim yok | Paralel çözüm çiftlikleri |
| Zaman kilitli (RSW) PoW | Düşük, birkaç saniye CPU | Üçüncü tarafa veri gerekmez | İyi | Özel donanım (ASIC/FPGA) |
| Görünmez, risk tabanlı | Çoğu kullanıcı için sıfır | Davranış verisi toplar | Genelde iyi | Sinyaller taklit edilebilir |
W3C, görsel CAPTCHA'nın erişilebilirlik sorunlarını "Inaccessibility of CAPTCHA" notunda ele alır. Görme veya bilişsel engeli olan kullanıcı için bulmaca doğrudan bir bariyerdir.
Proof-of-work neden tek başına yetmez?
Proof-of-work (PoW), istemciden küçük bir hesaplama ister. Kullanıcı için maliyet birkaç saniyelik CPU zamanıdır. Saldırgan için maliyet istek sayısıyla çarpılır; bu, kitlesel botları pahalılaştırır.
Ancak ekonomi iki yönlüdür. Saldırgan bulmacayı kendi sunucusunda, hızlı ve paralel çözebilir. Bulmaca tarayıcı yerine yerel (native) bir programla çözülürse JavaScript'ten daha hızlı çalışabilir. Çok çekirdekli bir "çözüm çiftliği" istek başına maliyeti daha da düşürür.
Zaman kilidi (RSW) fikri nedir?
Zaman kilidi bulmacası, çözümü sırayla hesaplanması gereken adımlara bağlar. Rivest, Shamir ve Wagner'in 1996'da önerdiği yapıda her adım bir öncekinin sonucunu kullanır (art arda modüler kareleme). Adımlar paralel çalıştırılamaz, yani 1.000 işlemci eklemek süreyi kısaltmaz.
Bunu pratik bir benzetmeyle düşünün: sıradan PoW "bin kez zar at" der ve bin kişi paylaşırsa iş hızlanır. Zaman kilidi ise "şu sayıyı sırayla bin kez ikiye katla" der; sıra bağımlı olduğu için ekip büyüklüğü işe yaramaz. Yalnızca tek bir adımı daha hızlı yapan donanım, örneğin ASIC veya FPGA, avantaj sağlar. Bu yüzden zaman kilidi çözümü ucuzlaştıran paralelliği kapatır, ama donanım hızlandırmasını kapatmaz.
Gizlilik ve erişilebilirlik neden belirleyici?
Görsel CAPTCHA'lar çoğunlukla üçüncü taraf betik yükler ve ziyaretçi verisini o tarafla paylaşır. Bu, çerez bildirimi ve KVKK yükümlülüklerini etkileyebilir; ayrıntı için KVKK ve güvenlik logları rehberine bakın. Etkileşimsiz bir proof-of-work ise tıklama, görüntü seçimi veya üçüncü taraf çerezi gerektirmez.
Erişilebilirlikte iki ölçüt işe yarar: bulmaca klavye ve ekran okuyucuyla çözülebiliyor mu, ve doğrulama kullanıcıdan bilişsel çaba istiyor mu. Etkileşimsiz yöntemler bu iki soruda daha rahat geçer. Buna karşılık JavaScript çalıştırmayan istemciler doğrulamayı geçemez; bu kısıtı açıkça belgeleyin.
Nexren Shield bunu nasıl ele alır
Nexren Shield doğrulamayı katmanlı yürütür:
- Bot skoru. Sezgisel bir skor, davranış telemetrisi ve IP itibarı birleşir. IP itibarı için Spamhaus DROP ve FireHOL level1 listeleri günlük yenilenir.
- TLS ve HTTP parmak izleri. JA3/JA4 ve HTTP/2 parmak izleri doğrulama anındaki risk değerlendirmesine girer.
- Risk modeli. El ile belirlenmiş başlangıç ağırlıklarıyla çalışan lojistik regresyon modeli skora en fazla 30 puan ekler.
- Challenge. Görselsiz, tıklamasız ve gizlilik dostu bir proof-of-work. Zaman kilitli (RSW) bulmaca WebAssembly ile çalışır: ardışık modüler kareleme yapılır, paralelleştirilemez ve GPU yardımcı olmaz. Varsayılan değer t=75.000 karelemedir. Bir BLAKE2b PoW ile birlikte çalışır.
- Gecelik kural evrimi. Bot kuralları her gece çalışan bir evrim sürecinden geçer.
- Doğrulanmış arama tarayıcıları. Google, Bing, Yandex, Apple, Baidu ve DuckDuckGo tarayıcıları ileri teyitli ters DNS ile doğrulanır ve ayrı ele alınır.
Gerçek tarayıcılar genellikle birkaç saniyede geçer. JavaScript çalıştıramayan veya bulmacayı çözemeyen istemciler engellenir.
Dürüst sınırlar. Dahili bot test matrislerinde atlatma yolları bulduk, bu yüzden %100 engelleme iddia etmiyoruz. Zaman kilidinde ASIC veya FPGA gibi özel donanım teorik olarak daha hızlı olabilir. Risk modelinin ağırlıkları başlangıçta elle belirlenmiştir. Bot koruması, WAF ve rate limit ile birlikte düşünülmelidir. Saldırı sırasında devreye giren mod için Under Attack rehberine bakın.
Hangi yöntemi seçmelisiniz?
Karar, kullanıcı kitlenize ve riskinize bağlıdır:
- Herkese açık içerik sitesi: arka planda risk skoru, şüphede hafif PoW.
- Giriş ve kayıt formları: PoW artı hız sınırı, kritik işlemlerde çok faktörlü doğrulama.
- API: bulmaca değil, token ve rate limit.
- Sınırlı stoklu satış: satın alma adımında güçlü doğrulama ve oturum başına sınır.
Her halükarda izleyin: bloklanan oranı, doğrulamayı geçme süresini ve şikayetleri ölçün. Önce yalnızca kayıt tutan bir izleme kipinde başlamak yanlış pozitifleri görmenizi sağlar.
Kaynaklar
İlgili ürün sayfaları:Teknoloji
Sık sorulan sorular
Görsel CAPTCHA neden artık yetersiz kalıyor?
Görüntü tanıma modelleri ve ücretli insan çözücü servisleri bu bulmacaları çözebiliyor. Meşru kullanıcı ise zaman kaybeder ve görme engelliler için bariyer oluşur.
Proof-of-work bot sorununu tek başına çözer mi?
Hayır. Saldırgan çok sayıda işlemciyi paralel çalıştırırsa hesaplama maliyeti istek başına çok düşer. Zaman kilitli bulmaca bu paralelleştirmeyi zorlaştırır ama ortadan kaldırmaz.
Arama motoru botlarını engeller miyim?
İyi tasarlanmış bir sistem doğrulanmış arama motoru tarayıcılarını ayrı ele alır. Doğrulama, ters DNS sorgusunun ileri DNS ile teyit edilmesine dayanır, yalnızca User-Agent'a güvenilmez.
Bot koruması KVKK açısından sorun çıkarır mı?
Davranış verisi ve IP adresi kişisel veri sayılabilir. Ne topladığınızı, ne kadar sakladığınızı ve hukuki dayanağını belirtin; ayrıntı için KVKK rehberine bakın. Bu yazı hukuki tavsiye değildir.
Mobil uygulamalar ve API istemcileri bu doğrulamayı geçer mi?
Tarayıcı tabanlı doğrulama JavaScript çalıştırır. Arka plan API istemcileri için ayrı yollar gerekir: API token, rate limit ve hariç tutulan yollar. Tek bir kural bunları kapsamaz.
İlgili rehberler
WAF nedir? Web uygulama güvenlik duvarı nasıl çalışır
WAF (web uygulama güvenlik duvarı), uygulamanıza giden HTTP isteklerini kurallara göre inceler ve SQL injection, XSS gibi saldırıları uygulamaya ulaşmadan engeller.
TLS Parmak İzi (JA3, JA4): Ne Kanıtlar, Ne Kanıtlamaz
TLS parmak izi, istemcinin el sıkışma mesajındaki (ClientHello) alanlardan üretilen kısa bir özettir.
API Güvenliği: Rate Limit ve WAF Neyi Çözer, Neyi Çözmez?
API güvenliği iki ayrı iş içerir: dışarıdan gelen kötü trafiği süzmek ve uygulamanın yetki mantığını doğru kurmak.
Under Attack Modu Ne Zaman Açılır? Karar Rehberi ve Yan Etkiler
Under Attack modu, her ziyaretçiden siteye girmeden önce kısa bir doğrulama geçmesini ister.