Bot ve kötüye kullanım trafiği çoğu zaman patlama şeklinde değil, yavaş ve sürekli davranış olarak görünür. Bir IP dakikada 30-50 istek yapıyor olabilir; bu tek başına felaket değildir, fakat 10 dakika boyunca devam ettiğinde scraping, otomasyon veya parola deneme davranışına dönüşebilir. Anlık rate-limit bu davranışın zamana yayılan karakterini her zaman doğru yakalayamaz.
WAAP imzaları farklı bir soruyu çözer: Bu istek bilinen bir saldırı desenine uyuyor mu? SQL injection, XSS veya command injection gibi kötü içerik desenleri yakalanabilir. Fakat meşru görünen ama yoğun trafik üreten scraping, fiyat takibi, hesap denemesi veya agresif API kullanımı imza tabanlı korumadan kaçabilir.
Bu iki yaklaşım arasında geçici izolasyon modeli gerekir. Belirli bir kaynak son N dakikada eşik aşan davranış göstermişse, kalıcı olarak yasaklanmadan M dakikalığına karantinaya alınmalıdır. Bu süre boyunca trafiği bloklanabilir, açıklama sayfasına alınabilir veya başka bir akışa yönlendirilebilir. Süre dolunca kaynak otomatik serbest kalır.
Bu model için iki ayrı mekanizma gerekir: davranışı ölçen izleme penceresi ve izolasyonu uygulayan karantina penceresi. İzleme kısa, karantina daha uzun tutulabilir; ya da uygulama hassasiyetine göre tersi seçilebilir. Aksiyonun da tek tip olmaması gerekir: bazı kaynaklara sessiz blok, bazılarına açıklama sayfası, bazılarına yönlendirme daha doğru olabilir.
TR7 Trafik Karantinası bu modeli sağlar: izleme ve karantina için iki ayrı zaman penceresi, dört anahtar tipi, üç aksiyon türü, karantina durumunun başka kurallarda koşul olarak kullanılabilmesi ve vService ekranından canlı görünürlük ile manuel müdahale.
TR7 Trafik Karantinası, davranış izleme ile geçici izolasyonu aynı politika motorunda birleştirir.
Her karantina kuralında izleme penceresi ve karantina penceresi ayrı tanımlanır. İzleme penceresi kaynağın davranışını ölçer; karantina penceresi ise eşik aşıldıktan sonra aksiyonun ne kadar süreceğini belirler.
Kaynak yalnızca IP olarak tanımlanmak zorunda değildir. IP, IP+kullanıcı ajanı, Host+IP ve Host+IP+kullanıcı ajanı seçenekleriyle çoklu domain, NAT ve çoklu kiracı senaryolarında daha doğru ayrım yapılır.
Karantina sırasında trafik bloklanabilir, başka bir URL'ye yönlendirilebilir veya özel içerik sayfası gösterilebilir. Böylece saldırgan trafiğe sessiz blok, gerçek kullanıcıya açıklamalı mesaj veya iş akışına uygun yönlendirme uygulanabilir.
Karantinaya alınmış kaynak, sistem genelinde kullanılabilir bir durum sinyaline dönüşür. Diğer trafik, yönlendirme ve içerik kuralları bu sinyali koşul olarak kullanarak kompozit politika oluşturabilir.
Trafik Karantinası, davranış izleme, geçici izolasyon ve operatör kontrolünü tek çalışma modelinde toplar.
Her kuralda izleme süresi ve karantina süresi bağımsız ayarlanır. İzleme penceresi içinde kaynak davranışı sayılır; eşik aşıldığında kaynak karantina penceresi boyunca ayrı listede tutulur. Süre dolduğunda kayıt otomatik düşer. Bu yapı kalıcı yasak yerine kontrollü ve süreli izolasyon sağlar.
`ip` seçeneği klasik kaynak IP bazlı izleme sağlar. `ipUa`, aynı IP arkasındaki farklı kullanıcı ajanlarını ayırır. `hostIp`, çoklu domain ortamlarında aynı IP'nin farklı hostlara giden davranışını ayrı sayar. `hostIpUa` ise çoklu kiracı ve çoklu istemci ortamlarında en granüler ayrımı sağlar.
Operatör, belirli zaman penceresinde istek sayısı için eşik tanımlayabilir. "Son 10 dakikada 100 istekten fazla" gibi kurallar davranış tabanlı karantina başlatır. Karar tek isteğe değil, pencere içindeki toplam davranışa dayanır. Bu yaklaşım rate-limit'ten farklı olarak gözleme dayalıdır.
`block` aksiyonu karantinadaki kaynağın trafiğini sessiz şekilde düşürmek için kullanılır. Bot ve otomasyon trafiğinde bu davranış çoğu zaman daha etkilidir; saldırgan net bir uygulama cevabı alamaz. Bu aksiyon, açıklama gösterilmesi gerekmeyen yüksek riskli abuse senaryolarında uygundur. Gerçek kullanıcı etkisi vService monitör ekranından takip edilebilir.
`showContent`, karantinadaki kaynağa özel HTTP durum kodu ve içerik döndürür. Örneğin fazla istek nedeniyle geçici olarak sınırlandığını anlatan bir sayfa gösterilebilir. Bu model, yanlış pozitif ihtimali bulunan veya kullanıcı deneyiminin önemli olduğu senaryolarda bloktan daha yumuşak davranır. Mesaj içeriği kurumun destek ve marka diline göre hazırlanabilir.
`redirect`, karantinadaki kaynağı farklı bir URL'ye yönlendirmek için kullanılır. CAPTCHA sayfası, açıklama portalı, abonelik yükseltme sayfası veya destek sayfası hedef olabilir. Böylece karantina yalnızca engelleme değil, kullanıcıyı doğru iş akışına taşıma aracı hâline gelir. Çoklu tenant ve SaaS senaryolarında bu seçenek özellikle değerlidir.
Bir kaynağın karantinada olması başka kurallarda koşul olarak kullanılabilir. Karantinadaki kaynaklar farklı kurum servisine yönlendirilebilir, özel header alabilir, özel içerik cevabı görebilir veya ikinci bir daha sert kuralın kapsamına girebilir. Bu özellik, tek karantina kuralını sistem genelinde davranış değişikliği tetikleyen sinyale dönüştürür. TR7'nin en önemli ayrıştırıcı noktalarından biridir.
Trafik Karantinası hem HTTP hem TCP servisleri için kullanılabilir. HTTP tarafında istek bazlı davranış izlenirken, TCP tarafında bağlantı seviyesinde karar verilir. Protokole göre aksiyonun teknik sonucu değişebilir; fakat temel model aynıdır: izle, eşiği aşanı geçici izolasyona al, süre dolunca serbest bırak.
vService canlı izleme ekranında karantinadaki aktif kaynaklar listelenir. Operatör hangi anahtarın, hangi kural nedeniyle, ne kadar süreyle karantinada olduğunu görebilir. Yanlış pozitif veya öncelikli kullanıcı durumunda manuel çıkarma yapılabilir. Süresi dolan kayıtlar otomatik temizlendiği için manuel müdahale zorunlu değildir.
Aynı vService altında birden fazla karantina kuralı birlikte çalışabilir. Örneğin ilk kural fazla istekte uyarı sayfası gösterirken, ikinci kural hâlâ devam eden kaynağı daha uzun süre bloklayabilir. vService başına 5 paralel karantina kuralı desteklenir. Bu yapı yumuşaktan serte ilerleyen abuse kontrolü oluşturur.
Trafik Karantinası; tablo yaşam döngüsü, küme davranışı, yeniden yükleme etkisi, izleme ekranı ve audit kayıtlarıyla birlikte operasyonel olarak yönetilir.
Her karantina kuralı izleme ve karantina için iki ayrı canlı izleme alanı kullanır. Kayıtlar süreyle tutulur ve TTL dolduğunda otomatik temizlenir. Yeni istek geldikçe izleme penceresi davranışı güncellenir. Bu yapı karantinayı kalıcı yasak değil, süreli davranış kontrolü olarak tutar.
Her istekte önce anahtar formülü hesaplanır, ardından izleme değeri güncellenir ve karantina koşulu değerlendirilir. Kaynak zaten karantinadaysa tanımlı aksiyon uygulanır. Kaynak karantinada değilse normal trafik akışı devam eder. Karar veri yolunda düşük maliyetle gerçekleşir.
Çift düğümlü kurulumlarda karantina tabloları yerel veya senkron çalışacak şekilde tasarlanabilir. Senkronizasyon etkin değilse failover sonrası yeni aktif düğüm karantina geçmişini baştan oluşturur. Senkronizasyon etkin olduğunda failover sonrası karantina durumu korunabilir. Bu seçim operasyonel ihtiyaç ve kurulum modeline göre değerlendirilmelidir.
Karantina tabloları bellekte tutulur ve kalıcı blacklist gibi davranmaz. Yumuşak yeniden yükleme veya tablo sıfırlama sonrasında aktif karantina durumu temizlenebilir. Bu kabul edilebilir bir davranıştır; çünkü karantina geçici izolasyon mekanizmasıdır. Uzun süreli yasaklama gerekiyorsa IP itibar beslemeleriyle birlikte kullanılmalıdır.
vService monitör ekranında aktif karantina kayıtları görülebilir ve operatör belirli kaynağı karantinadan çıkarabilir. Bu işlem tablo kaydını siler; sonraki istek normal akışta değerlendirilir. VIP kullanıcı, yanlış pozitif veya destek talebi durumunda hızlı müdahale sağlar.
Karantinaya alma ve karantinadan çıkarma olayları audit kayıtlarına yazılabilir. SIEM log streaming etkinse olaylar dış toplayıcıya gönderilebilir. Hangi anahtarın, hangi kural nedeniyle, hangi aksiyonla ve ne kadar süre karantinaya alındığı sonradan incelenebilir.
Aktif anahtar sayısı ve anahtar tipi bellek tüketimini etkiler. IP bazlı anahtarlar daha sade, Host+IP+kullanıcı ajanı gibi birleşik anahtarlar daha fazla alan tüketir. vService başına paralel 5 karantina kuralı desteklendiği için kapasite planı trafik profiline göre yapılmalıdır.
E-ticaret sitesi, fiyat scraping yapan kaynakları `ipUa` anahtarıyla izleyebilir. 5 dakikada 100 isteği aşan IP+kullanıcı ajanı kombinasyonu 30 dakika bloklanır; aynı IP arkasındaki farklı gerçek kullanıcılar ayrı anahtar olarak değerlendirilebilir.
Bankacılık portalı, login endpoint'inde tekrarlı denemeleri IP veya IP+kullanıcı ajanı bazında izleyebilir. Eşik aşıldığında kaynak 60 dakika açıklamalı sayfaya alınır ve gerçek kullanıcıya geçici kısıtlama nedeni gösterilir.
Çoklu domain barındıran SaaS platformu, `hostIp` anahtarıyla her tenant trafiğini ayrı izleyebilir. Bir tenant'ın agresif kullanımı diğer tenant trafiğini etkilemeden redirect veya geçici blok aksiyonuna alınabilir.
İlk kural fazla istek atan kaynağı 10 dakika uyarı sayfasına yönlendirir. Kaynak karantinadayken hâlâ trafik üretmeye devam ederse ikinci kural devreye girer ve 60 dakika blok uygular. Karantina durumunun başka kurallarda koşul olması bu kademeli modeli mümkün kılar.
Davranış tabanlı geçici izolasyon, kompozit kural yapısı ve canlı operatör görünürlüğü. Kendi ortamınızda nasıl çalıştığını birlikte inceleyelim.