Botnet Trafiğini Veritabanınıza Ulaşmadan Durdurun

Çoğu uygulama mimarisi “nazik” davranmak üzere tasarlanır. Bir istek gelir, router bunu controller’a iletir, controller veritabanı bağlantısı açar, sorgu çalıştırır ve yanıtı render eder. İnsan kullanıcılar için gayet normal bir akıştır. Botnet içinse davetiye gibidir.

Dağıtık bir botnet’in size zarar vermek için illa bir güvenlik açığına ihtiyacı yoktur. Uygulamanızın sürekli “evet” demesi yeterlidir: giriş formuna evet, arama endpoint’ine evet, şifre sıfırlama e-postasına evet, bağlantı havuzundan bir bağlantı daha açmaya evet. Trafik ORM katmanınıza ulaştığında TLS maliyetini, oturum kontrolünü ve veritabanı gidiş dönüşünü çoktan ödemiş olursunuz — üstelik bu maliyet dakikada binlerce node ile çarpılır.

En ucuz istek, hiç işlemediğiniz istektir. Edge’de IP seviyesinde filtrelemenin özü tam olarak budur.

Bir botnet IP katmanında nasıl görünür?

Botnet trafiği çoğu zaman tek bir adresten gelmez. Çok sayıda adresten gelir ve bu adreslerin önemli bir kısmı birkaç tanıdık grupta toplanır:

• Ele geçirilmiş ev kullanıcıları. Ev router’ları, IoT cihazları ve enfekte masaüstü bilgisayarlar. Tek tek düşük hacimlidirler ama toplamda devasa bir trafiğe dönüşürler.
• Kiralık datacenter kapasitesi. Toplu şekilde ayağa kaldırılan ucuz VPS’ler. Gerçek bir müşterinin ödeme sayfanızı AWS, OVH veya Hetzner IP aralıklarından gezmesi oldukça nadirdir.
• Ticari proxy ağları. Gigabyte bazında satılan residential ve mobil proxy havuzları. Genellikle IP tabanlı engellemeleri aşmanın yolu olarak pazarlanırlar.
• Herkese açık VPN ve TOR çıkışları. Gizliliğine önem veren kullanıcılar için meşru araçlardır; ancak kötüye kullanım trafiğinde de normalin üzerinde temsil edilirler.

Bu grupların hiçbiri tek başına “kesin zararlı” anlamına gelmez. Bir datacenter IP’si sizin özellikle kurduğunuz bir izleme probu olabilir. Bir VPN çıkışı, otel Wi-Fi’ına bağlı gerçek bir müşteriye ait olabilir. Bu yüzden karar, kör bir blocklist’e değil size ait olmalıdır: Önce sınıflandırmaya ihtiyacınız var; ardından kendi politikanızı uygularsınız.

Veritabanından sonra değil, önce engellemek

Sıralama, tek bir sinyalin doğruluğundan çoğu zaman daha kritiktir. Aynı login endpoint’inin iki farklı versiyonunu düşünün.

| Stage | Without IP filtering | With IP filtering first | | --- | --- | --- | | Parse request | Yes | Yes | | IP classification | — | ~1 lookup, cached | | Session / user lookup | Yes | Only if allowed | | Password hash verify | Yes (expensive by design) | Only if allowed | | Rate-limit write | Yes | Only if allowed |

Şifre hash’leme bilerek yavaştır; zaten görevi budur. Korumasız bir login endpoint’ine yapılan credential stuffing saldırısı, kendi güvenlik önleminizi bir denial-of-service aracına dönüştürebilir. IP kararını bu adımdan önceye almak, saldırgan node’un hash-map erişimi maliyetine 403 alması; veritabanı bağlantı havuzunuzun ise gerçek müşterilere ayrılması anlamına gelir.

Aynı mantık full-text indekslerine dokunan arama endpoint’leri, transactional e-posta tetikleyen kayıt formları ve her denemede audit satırı yazan tüm endpoint’ler için de geçerlidir.

Duvar değil, uygulanabilir bir politika

Şüpheli görünen her şeyi sert şekilde engellemek, destek ekibinin önüne kızgın kullanıcı talepleri yığmanın kısa yoludur. Katmanlı bir yanıt modeli daha iyi çalışır. Her adres için bir risk skoru ve tür bilgisi olduğunda bunu ifade etmek de kolaydır:

• Sessizce izin verin. Düşük risk skoruna sahip residential ve kurumsal ISP adresleri. Gerçek trafiğin ezici çoğunluğu bu gruptadır.
• Sürtünme ekleyin. VPN veya TOR çıkışlarında yalnızca hassas işlemlerde — kayıt, şifre sıfırlama, ödeme hesabı değişikliği gibi — ek kontrol uygulayın. Challenge gösterin, e-posta doğrulaması isteyin, ücretsiz deneme hakkını otomatik vermeyin.
• Sert şekilde yavaşlatın. İnsan kullanıcıya dönük endpoint’lere gelen datacenter ve hosting aralıklarını kısıtlayın. Meşru entegrasyonlar login formunuzda değil, API anahtarıyla API’nizde olmalıdır.
• Edge’de reddedin. Kimlik doğrulama endpoint’lerini döven, kötüye kullanımı bilinen proxy altyapısını veya IP başına tanımladığınız bütçeyi aşmış trafiği daha uygulamaya ulaşmadan kesin.

Dikkat: 4. adım varsayılan davranış değil, en küçük kovadır. Amaç ürünü erişilmez kılmak değil; kötüye kullanımı pahalı hale getirmektir.

Kontrol uygulama stack’inizin neresinde olmalı?

Etkinlik sırasına göre üç temel yerleşim var:

• CDN veya reverse proxy. Mümkün olan en erken nokta. İstek uygulama sunucusuna hiç dokunmaz. Açıkça düşmanca görünen IP aralıklarına genel kurallar uygulamak için en iyi yerdir.
• Uygulama içinde middleware. Routing’den ve herhangi bir veritabanı çağrısından önce çalışır. Endpoint bazlı daha incelikli politikalar burada yaşar — /login için sıkı, /pricing için daha rahat.
• İş mantığının içinde. Hesap bağlamı gerektiren kararlar için uygundur. Örneğin bugüne kadar yalnızca tek bir mobil operatörden giriş yapmış bir hesapta datacenter IP’sinden gelen login denemesini işaretlemek gibi.

Çoğu ekibin önce orta katmana ihtiyacı vardır. Router’ın önüne eklenecek birkaç satır kod, arkasındaki her şeyi korumaya başlar.

Agresif cache kullanın, sorun anında açık kalın

IP reputation kontrolünün kendi başına bir kesinti sebebine dönüşmemesi için iki operasyonel kural önemlidir:

Adrese göre cache’leyin. Botnet’ler node’ları tekrar tekrar kullanır. Kısa süreli bir in-memory TTL — günler değil, dakikalar — binlerce isteği tek bir sorguya indirir ve tekrar eden saldırganlarda ek gecikmeyi mikro saniye seviyesinde tutar. Guarda sorguları tam da bu nedenle sunucu tarafında cache’ler; cache penceresi de yapılandırılabilir.

Fail open çalışın, yüksek sesle loglayın. Reputation servisine ulaşılamıyorsa isteği içeri alın ve olayı kaydedin. Üçüncü taraf bir servis kötü bir gün geçiriyor diye ödeme sayfanızı kapatan bir anti-abuse kontrolü, çoğu zaman kötüye kullanımın kendisinden daha pahalıya mal olur. Fail-closed yaklaşımını para çekme gibi gerçekten yüksek riskli işlemler için saklayın.

Sonrasında neyi ölçmelisiniz?

Filtreyi önce yalnızca log modunda devreye alın ve bir haftalık trafiği, engellemenin açık olduğu bir haftayla karşılaştırın:

• Toplam trafiğe oranla, veritabanına ulaşmadan reddedilen istekler.
• Kötüye kullanımın yoğunlaştığı saatlerde veritabanı connection pool doluluğu.
• Saatlik başarısız login denemeleri.
• “Giriş yapamıyorum” diyen destek talepleri — false positive için erken uyarı kanaryanız.
• Kayıttan doğrulanmış hesaba dönüşüm oranı; tek kullanımlık datacenter kayıtları durduğunda bu oran genellikle belirgin şekilde iyileşir.

Son iki metrik yanlış yöne gidiyorsa tüm sistemi kapatmak yerine ilgili katmanı gevşetin.

Dürüst sınırlar

IP reputation tek başına bir katmandır; bütün güvenlik duvarı değildir. Residential proxy havuzları, gerçek tüketici adresleri üzerinden döner ve müşterilerinizden ayırt edilmesi çok zor olabilir. Carrier-grade NAT nedeniyle tek bir mobil IP, binlerce kişiyi temsil edebilir. Bütçesi olan saldırgan, bütçesi olmayana göre her zaman daha temiz altyapı bulur.

IP filtrelemenin güvenilir şekilde yaptığı şey, ucuz ve yüksek hacimli çoğunluğu ortadan kaldırmaktır: kiralık sunucularda çalışan script’li flood’lar ve çoktan yanmış proxy listeleri. Böylece daha yavaş ama daha akıllı savunmalarınız — device fingerprinting, davranış analizi, MFA, hesap kapsamlı rate limit’ler — çok daha küçük ve anlamlı bir kitle üzerinde çalışır.

Gerçekçi kazanım budur: Aşılamaz bir çevre duvarı değil; saldırı altındayken bile sorgulara yanıt vermeye devam eden bir veritabanı.

Guarda’nın proxy, VPN, TOR, hosting ve risk skoru sinyalleriyle herhangi bir adresi ana sayfadaki ücretsiz kontrol aracı üzerinden sınıflandırabilir; ardından aynı çağrıyı route’larınızın önündeki middleware’e bağlayabilirsiniz.