Eğer mobil trafikle dönüşüm aniden düştüyse ve kayıt veya ödeme formu gerçek müşterilerde 403 hatası veriyorsa, muhtemelen suçlu bir hacker değil, kendi WAF'ınızdır. Güvenlik duvarı, bir mobil operatörden gelen tek bir IP adresinden binlerce isteği görür ve bunu DDoS veya brute force olarak algılar. Aslında bu IP'nin arkasında yüzlerce veya binlerce sıradan insan bulunmaktadır — bu teknoloji CGNAT'tır. Bunu tespit etmenin ve düzeltmenin yollarını inceliyoruz, gerçek saldırılar için bir açık bırakmadan.
CGNAT nedir ve neden sorun yaratır
CGNAT (Carrier-Grade NAT), mobil operatörlerin IPv4 adreslerinin kıtlığı nedeniyle kullandığı bir teknolojidir. Her aboneye benzersiz bir kamu IP adresi vermek yerine, operatör binlerce kullanıcıyı tek veya birkaç ortak adresin arkasına "saklar". Site için bu, tek bir IP'den yüzlerce farklı insandan gelen trafiğin aynı anda geldiği anlamına gelir — farklı cihazlar, farklı tarayıcılar, farklı davranışlar, ama aynı dış adres.
Normal bir web sunucusu için bu bir sorun değildir — sadece istekleri işler. Ancak, bir IP'den gelen istekleri zaman birimi olarak sayan koruma sistemleri için bu bir anomali gibi görünür. Hayal edin: bir dakikada bir adresten 200 giriş sayfası isteği geliyor. WAF için bu, klasik bir brute force veya scraping modeli. Ancak gerçekte bu, bölgenizdeki bir mobil operatörün 150 gerçek müşterisi olabilir; hepsi reklam gönderimi veya sosyal medya paylaşımlarından sonra aynı anda siteyi açmıştır.
Sorun, yüksek mobil internet yoğunluğuna sahip ülkelerde özellikle belirgindir — operatörler, çok sayıda aboneyi minimum sayıda dış IP ile birleştirir. Bu nedenle, site davranışını normal veri merkezi IP'lerinden değil, mobil proxy'lerden test etmek gerekir; bu, operatörün CGNAT altyapısından geçerek WAF'ın canlı kullanıcılar tarafından gördüğü aynı manzarayı yeniden üretmenin tek yoludur.
WAF, CGNAT'ta neden bir tehdit görüyor
Çoğu WAF çözümü — Cloudflare, AWS WAF, Imperva, Nginx/ModSecurity'nin yerleşik modülleri — botlar ve DDoS saldırılarına karşı temel koruma mekanizması olarak IP adresine göre rate-limiting kullanır. Mantık basittir: eğer bir IP'den T saniyede N'den fazla istek gelirse — yasakla veya CAPTCHA göster. Bu kural, tek bir cihazdan gelen klasik saldırılar için mükemmel çalışır, ancak CGNAT trafiğinde tamamen bozulur.
Bunun ortaya çıktığı birkaç tipik senaryo vardır:
- IP'ye göre rate-limiting. "Bir IP'den dakikada 100 istek" limiti, veri merkezi trafiği için normaldir, ancak bir adreste bir milyon abone bulunan mobil bölge için felaket niteliğindedir.
- Davranışsal puanlama. Eğer sistem, istek geçmişine dayalı olarak IP'nin "itibarını" biriktiriyorsa, CGNAT altında bir "kötü" kullanıcı, sonraki binlerce dürüst müşteri için adresin itibarını bozabilir.
- Coğrafi heuristik. WAF bazen, "normal" bir kullanıcıya ait olmayan ani aktivite artışlarını gördüğünde IP'yi şüpheli olarak işaretler — ve CGNAT adresinin davranışı tam olarak böyledir: izleyici aktivitelerinin yoğun saatlerinde pik yükler.
- Operatör ASN'ye göre yasaklama. Bazı WAF kuralları, daha önce bu aralıklardan saldırılar geldiyse, mobil operatörlerin tüm ASN aralıklarını yasaklar — bu durumda ülkedeki tüm operatör müşterileri etkilenir.
Sonuç: WAF "kutudan çıktığı gibi" ne kadar sert ayarlanmışsa, botları değil, gerçek mobil kullanıcı kitlenizi yasaklama olasılığı o kadar yüksektir — özellikle iş, gelişmiş mobil internet ve yüksek CGNAT trafiği oranına sahip ülkelere odaklanıyorsa.
Bu durumun işletmeye etkisi: kaybedilen müşteriler ve para
CGNAT yasaklamalarının sorunu, standart analitiklerde nadiren görünür. Google Analytics ve Yandex.Metrica, WAF seviyesinde 403 hatası alanları kaydetmez — bu tür ziyaretler genellikle sayaca bile ulaşmaz. Sonuç olarak, pazarlamacı dönüşümde bir düşüş görür, ancak nedenini anlamaz ve sorun altyapıda olduğu halde yaratıcıları ve açılış sayfalarını optimize etmeye başlar.
Farklı iş segmentleri için gerçek sonuçlar:
- E-ticaret. Mobil internetten bir alıcı siparişini tamamlayamaz — ödeme formu hata verir, sepet kaybolur. Özellikle TikTok Ads veya Facebook Ads'de reklam yayınladıktan sonra doğrudan gelir kaybı, ana trafik mobil olduğu için belirgin hale gelir.
- SaaS ve kayıtlar. Kullanıcı kaydolmaya veya kişisel hesabına giriş yapmaya çalışır, her adımda CAPTCHA alır veya yasaklanır — rakibe gider.
- İçerik ve reklam. Mobil cihazlardan gelen reklam trafiği, açılış sayfasında kitlesel olarak "kesiliyor", reklam bütçesi harcanıyor, ancak dönüşüm yok — reklam platformlarının algoritmaları bunu düşük kalite olarak yorumlar ve tıklama fiyatını artırır.
- Destek hizmeti. "Web siteniz açılmıyor", "Kayıt olamıyorum" gibi başvuruların sayısı artıyor — ancak teknik destek sorunu göremez, çünkü kendisi ofis Wi-Fi'si üzerinden masaüstünden CGNAT olmadan bağlanır.
En kötü durum — bu tür yasaklamaları sonradan teşhis etmek zordur, çünkü WAF kaydı, büyük sayıda istekle tek bir "şüpheli" IP gösterir ve yönetici bunu yasaklamanın doğruluğunun bir kanıtı olarak görür, yanlış bir tetikleme değil.
Sorunu bulmak için mobil IP'lerle 6 kontrol
WAF'ınızın dürüst mobil müşterileri yasaklayıp yasaklamadığını anlamak için, gerçek CGNAT koşullarını yeniden oluşturmak gerekir — yani, farklı operatörlerin ve bölgelerin gerçek mobil IP'lerinden siteyi test etmek. İşte 6 kontrol için pratik bir kontrol listesi.
Kontrol 1: Tek bir mobil IP'den toplu giriş
Aynı mobil IP üzerinden birkaç paralel oturum ayarlayın (bu, CGNAT operatörü için doğal bir durumdur) ve 50-100 sıradan işlem gerçekleştirin — sayfaları açma, sepete ekleme, bölümler arasında geçiş yapma. Belirli bir eşiği aştıktan sonra CAPTCHA veya 403 görünmeye başlarsa — bu, sorunun ilk sinyalidir.
Kontrol 2: Tek IP'de User-Agent değiştirme
Bir CGNAT adresi farklı cihazları destekler — iPhone, Android, farklı tarayıcılar. Tek bir IP üzerinden farklı User-Agent dizeleri ile istekler başlatın ve WAF kuralının "bir adresten şüpheli cihaz çeşitliliği" devreye girip girmediğini kontrol edin.
Kontrol 3: Kritik formlar üzerindeki test
Müşteri yolculuğunu tam olarak geçin — kayıt, oturum açma, sipariş verme, ödeme — tam olarak operatörün mobil IP'si üzerinden. WAF genellikle, veri girişi yapılan formlarda (giriş, ödeme) daha agresif ayarlanmıştır; burada brute force riski daha yüksektir ve gerçek müşterilerin kaybedildiği ilk yerdir.
Kontrol 4: Farklı operatörler ve bölgeler üzerinden kontrol
CGNAT davranışı, farklı operatörlerde ve ülkelerde farklılık gösterir — bir IP'nin arkasında bazen 50 abone, bazen 5000 abone gizlidir. İşletmeniz için önemli coğrafyalarda birkaç operatörün mobil IP'leri ile siteyi test edin, böylece yasaklamaların bölgesel bir özelliği olup olmadığını anlayabilirsiniz.
Kontrol 5: Sunucu yanıtını kodlar ve başlıklar üzerinden analiz etme
Sadece yasaklama faktörünü değil, aynı zamanda kesin HTTP kodunu ve yanıt başlıklarını (örneğin, cf-mitigated: challenge Cloudflare'de) kaydedin. Bu, hangi koruma mekanizmasının devreye girdiğini anlamanıza yardımcı olacaktır — rate-limit, bot tespiti veya coğrafi kural.
Kontrol 6: IP'nin itibarını uzun vadeli izleme
Aynı mobil IP üzerinden birkaç gün boyunca testi tekrarlayın. Eğer zamanla erişim görünür nedenler olmaksızın kötüleşiyorsa — bu, diğer abonelerin aynı CGNAT altında etkinliği nedeniyle adresin itibarını "bozan" bir sistematik sorundur, tek seferlik bir sorun değil.
Önemli olan:
Bu tür testler için gerçek mobil IP'lere ihtiyaç vardır, veri merkezi veya sıradan konut adresleri değil — yalnızca operatörün altyapısından geçmiş trafik, WAF'ınızın gerçek kullanıcılar üzerindeki CGNAT modelini doğru bir şekilde yeniden üretir.
Dürüst müşterileri yasaklamamak için WAF nasıl ayarlanır
Teşhis sonrasında, güvenlik kurallarını kaybetmeden gerçek mobil kullanıcıları yasaklamayı bırakacak şekilde ayarlamak gerekir. İşte ana yaklaşımlar.
| Sorun | WAF'deki Çözüm |
|---|---|
| Sert IP'ye göre rate-limit | Bilinen mobil operatörlerin ASN'leri için limiti artırmak veya saf IP yerine oturum/çerez limitine geçmek |
| IP'nin itibarını biriktirme | CGNAT aralıkları için "hafıza" süresini kısaltmak, bilinen operatörlerin ASN'leri için beyaz liste eklemek |
| Coğrafi/ASN'ye göre tam yasaklama | Tam yasaklamayı 403 yerine yumuşak bir challenge (JS kontrolü) ile değiştirmek |
| Giriş formlarında sert CAPTCHA | CAPTCHA'yı yalnızca gerçek brute force belirtileri (bir hesaptan çok sayıda başarısız girişim) olduğunda etkinleştirmek, CGNAT-IP nedeniyle değil |
İyi bir uygulama, anahtar coğrafyalarınızda bilinen mobil operatör aralıklarının kendi listenizi tutmak ve bunlara normal internet trafiğine göre daha yumuşak kurallar vermektir. Bu, ayarlama için zaman alır, ancak yanlış yasaklamaların sayısını önemli ölçüde azaltır.
Mobil proxy'lerle test araçları
Site korumasını düzenli olarak denetlemek için, bir anti-detect tarayıcı ve mobil proxy kombinasyonunu kullanmak uygundur. Anti-detect tarayıcılar (Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser), farklı cihaz izleri ile izole profiller oluşturmanıza olanak tanır, mobil proxy'ler ise operatörlerden gerçek CGNAT trafiği sağlar.
Teste adım adım yaklaşım:
- Anti-detect tarayıcısında farklı cihaz parametreleri ile birkaç profil oluşturun (farklı User-Agent, ekran çözünürlüğü, zaman dilimi).
- Her profile uygun bölge ve operatörden mobil proxy'ler bağlayın — bu, gerçek CGNAT davranışını sağlayacaktır.
- Anahtar kullanıcı senaryolarını geçin: kayıt, giriş, sepete ekleme, ödeme.
- Tüm CAPTCHA, 403 ve diğer yasaklama durumlarını kaydedin, WAF ayarlarıyla karşılaştırın.
- Karşılaştırma için konut proxy'leri ile testi tekrarlayın — bu, sorunun mobil trafik için özel olup olmadığını anlamanıza yardımcı olacaktır.
Farklı coğrafyalarda paralel testler için konut proxy'leri de faydalıdır — bunlar, WAF'ın normal ev trafiği ve mobil CGNAT için ne kadar agresif olduğunu değerlendirmenize yardımcı olur. Operatöre bağlı olmadan sunucu altyapısından yük testleri planlıyorsanız, CGNAT etkisi olmadan kontrol testleri için veri merkezi proxy'leri bağlayabilirsiniz — bunlar, mobil ağlara özgü bozulmalar olmadan temiz bir temel hat sağlar.
Bu kapsamlı yaklaşım — mobil, konut ve veri merkezi IP'lerini tek bir testte kullanmak — tam bir resim sunar: korumanın nerede devreye girdiğini ve hangi trafik türü için olduğunu kesin olarak görürsünüz, dolaylı belirtilere dayanarak tahmin yürütmek zorunda kalmazsınız.
Sıkça Sorulan Sorular
CGNAT aralıklarını WAF kurallarından tamamen çıkarmak mümkün mü?
Tavsiye edilmez — bu, mobil ağlar üzerinden de gelebilecek gerçek saldırılara karşı korumayı azaltır. Daha doğru olanı, eşikleri yumuşatmak ve sert yasaklama yerine yumuşak bir challenge'a geçmektir.
Bu tür kontrolleri ne sıklıkla yapmak gerekir?
Ayda en az bir kez ve WAF kurallarında herhangi bir değişiklik veya mobil kitleye yönelik yeni bir reklam kampanyası başlatmadan önce mutlaka yapılmalıdır.
Bu SEO'yu etkiler mi?
Evet — eğer arama botları veya gerçek mobil kullanıcılar 403 alıyorsa, bu, hemen çıkma oranını artırır ve sıralama davranış metrikleri üzerinde olumsuz bir etki yaratabilir.
Sonuç
CGNAT, mobil internetin bir tehdidi değil, özelliklerinden biridir ve mobil kitleye sahip hemen hemen her işletmenin karşılaştığı bir durumdur. Sorun, teknolojinin kendisinde değil, standart WAF ayarlarının başlangıçta onun özelliklerini dikkate almaması ve dürüst kullanıcıları, normal mobil ağlara özgü davranışları nedeniyle cezalandırmasıdır. Bu makaledeki altı kontrol, yanlış yasaklamalar nedeniyle müşterilerinizi kaybedip kaybetmediğinizi hızlı bir şekilde teşhis etmenize yardımcı olacaktır; ayrıca WAF kurallarının noktasal ayarlanması, koruma seviyesini düşürmeden dönüşümü geri kazandıracaktır.
Eğer site ve reklam hunilerinin gerçek mobil müşteriler tarafından nasıl görüldüğünü düzenli olarak test etmeyi planlıyorsanız, mobil proxy'leri kullanmanızı öneririz — bunlar, operatörlerin gerçek CGNAT trafiğini sağlar ve yanlış yasaklamaları, müşterileriniz bulmadan önce tespit etmenize olanak tanır.