E-Pin Scriptinde DDoS Saldırılarına Karşı Alınması Gereken Önlemler

Sitenize aynı anda binlerce sahte istek düşüyor, sunucu CPU'su tavan yapıyor, gerçek müşterileriniz sepete ürün ekleyemiyor ve siz panelde çaresizce yenile tuşuna basıyorsunuz — e-pin sektöründe bu senaryo sanıldığından çok daha sık yaşanıyor. Çünkü e-pin ve dijital ürün siteleri, hem rakipler hem de kötü niyetli botlar için diğer e-ticaret sitelerine göre çok daha "verimli" bir hedef. Bu yazıda saldırının nereden geldiğini, hangi katmanda durdurulması gerektiğini ve hem sunucu hem uygulama seviyesinde alınması gereken somut önlemleri anlatıyoruz.

E-Pin Siteniz Neden DDoS Saldırganları İçin Bu Kadar Cazip Bir Hedef?

Normal bir blog veya kurumsal site DDoS'a uğradığında kaybedilen şey genelde sadece trafik ve itibardır. Ama bir e-pin sitesinde işin içine anlık stok kontrolü, bakiye sorgusu, ödeme entegrasyonu ve tedarikçi API çağrıları girer. Bu da saldırganın aynı miktarda istekle çok daha fazla hasar verebilmesi anlamına gelir.

• Rakip bayiler, kampanya döneminde sizi devre dışı bırakıp kendi trafiğini artırmak isteyebilir.
• Bot ağları, stok/fiyat API'nizi kazımak (scraping) için sürekli istek gönderirken farkında olmadan bir DDoS etkisi yaratabilir.
• Kart/kod doğrulama denemeleri yapan dolandırıcılar, login ve ödeme uçlarınıza yoğun otomatik trafik bindirir.
• Küçük ve orta ölçekli siteler genelde büyük e-ticaret devleri kadar güçlü altyapı yatırımı yapmadığı için "kolay lokma" olarak görülür.

Kısacası e-pin scriptinizde saldırı yüzeyi sadece ana sayfa değil; sepet, kod teslim ekranı, bakiye yükleme ve admin paneli gibi kritik uçların hepsidir. Önlem planı da bu uçların hepsini kapsamalıdır.

Saldırı Hangi Katmandan Geliyor? L3/L4 mü, Yoksa Sinsi L7 mi?

Doğru önlemi seçebilmek için önce saldırının türünü anlamak gerekir. Saha tecrübesinde iki tip saldırı bariz farklı davranır ve farklı savunma ister.

• Ağ katmanı (L3/L4) saldırıları: SYN flood, UDP flood gibi ham bant genişliği/bağlantı tüketimine dayalı saldırılardır. Sunucunuzun ağ arayüzünü ve bağlantı tablosunu doldurur. Bunlara karşı en etkili savunma, trafiği sunucuya ulaşmadan önce filtreleyen bir CDN/anti-DDoS katmanıdır.
• Uygulama katmanı (L7) saldırıları: Gerçek tarayıcı gibi görünen ama otomatik olarak ürün sayfasını, arama kutusunu veya sepet API'sini defalarca çağıran isteklerdir. Bunlar bant genişliğini değil, veritabanınızı ve PHP-FPM işçilerinizi tüketir — tespit edilmesi çok daha zordur çünkü tek tek istekler "normal" görünür.

E-pin sitelerinde en çok görülen ve en çok göz ardı edilen tip L7'dir. Çünkü saldırgan genelde 10.000 farklı IP'den saniyede birer istek gönderir; klasik "IP başına limit" mantığı bu durumda işe yaramaz. Bu yüzden davranışsal analiz (aynı endpoint'e anormal sıklıkta, insan olmayan aralıklarla gelen istekler) şart olur.

Cloudflare Arkanızda Diye Rahat mısınız? Aslında Neyi Kaçırıyor Olabilirsiniz?

Cloudflare veya benzeri bir CDN kullanmak doğru bir başlangıçtır ama tek başına yeterli değildir. Çoğu e-pin sitesi sahibi sadece "proxy'yi turuncu yapıp" işin bittiğini düşünür; oysa varsayılan ayarlarla birçok L7 saldırısı hâlâ sızabilir.

• WAF kuralları özelleştirilmeli: Sepet, giriş ve kod teslim endpoint'lerine özel rate-limit kuralları tanımlanmalı, sadece genel WAF'a güvenilmemeli.
• Under Attack Mode hazır tutulmalı: Saldırı anında tek tıkla devreye alınabilecek JS-challenge modu, panelde nerede olduğu bilinmeden işe yaramaz.
• Bot Fight Mode / Managed Rules test edilmeli: Bazı meşru ödeme webhook'ları (PayTR, Shopier bildirim URL'leri) yanlışlıkla bot olarak işaretlenip engellenebilir; bu yüzden istisna listesi önceden tanımlanmalı.
• Gerçek IP gizlenmeli: Sunucunuzun asıl IP adresi açık kalırsa saldırgan CDN'i tamamen bypass edip doğrudan sunucuya saldırabilir — bu, gördüğümüz en sık atlanan konfigürasyon hatasıdır.

Sunucunuzda ve Kodunuzda Hangi Kilitler Olmalı?

CDN katmanı geçilirse ikinci savunma hattı sunucu ve uygulama seviyesindeki kısıtlamalardır. Bunları kurmak için büyük bir ekibe ihtiyaç yok, doğru sırayla ilerlemek yeterli.

• Nginx/Apache seviyesinde rate limiting: `limit_req` gibi modüllerle aynı IP'nin saniyede/dakikada kaç istek atabileceği sınırlanmalı, özellikle `/sepet`, `/giriş`, `/kod-teslim` gibi uçlarda daha sıkı tutulmalı.
• Fail2ban veya benzeri araçlarla otomatik IP banı: Kısa sürede çok sayıda 4xx/5xx hatası üreten IP'ler otomatik olarak belirli süreliğine engellenmeli.
• Login ve kod sorgulama formlarında görünmez captcha: Kullanıcı deneyimini bozmadan bot trafiğini ayıklamak için hCaptcha/Turnstile gibi çözümler sadece şüpheli davranışta devreye girmeli.
• Veritabanı sorgularının önbelleklenmesi: Stok ve fiyat gibi sık sorgulanan veriler her istekte veritabanına gitmek yerine kısa süreli (5-30 saniye) önbellekten dönmeli — bu tek başına saldırı sırasında sunucuyu ayakta tutabilir.
• PHP-FPM işçi sayısı ve zaman aşımı ayarları gözden geçirilmeli: Tek bir yavaş sorgu tüm işçileri kilitlememeli, timeout değerleri makul tutulmalı.

Bu önlemlerin çoğu tek seferlik bir kurulum işidir ama script güncellendikçe veya yeni endpoint eklendikçe tekrar gözden geçirilmesi gerekir — çoğu site sahibi bunu ilk kurulumdan sonra bir daha hiç kontrol etmiyor.

Tedarikçi API'niz Çökerse Ne Olur? Stok ve Bakiye Sorgularını Nasıl Korursunuz?

E-pin scriptlerinde gözden kaçan bir nokta var: DDoS saldırısı doğrudan sizi hedef almasa bile, sitenizdeki yoğun trafik Turkpin veya Pinabi gibi tedarikçi API'lerine giden istek sayısını patlatabilir. Tedarikçi tarafında rate limit'e takılırsanız gerçek müşterileriniz bile stok sorgulayamaz hale gelir — saldırı bitse bile hizmet kesintisi devam eder.

• Tedarikçi çağrılarını sıraya (queue) alın: Her sayfa yüklemesinde tedarikçiye direkt gitmek yerine, istekleri kuyruklayıp kontrollü şekilde işleyen bir yapı kurun.
• Circuit breaker mantığı ekleyin: Tedarikçi API'si art arda hata döndürdüğünde sistem otomatik olarak "yerel önbellekten yanıt ver" moduna geçmeli, sürekli deneyip tıkanıklığı büyütmemeli.
• Ödeme bildirim URL'lerini ayrı ele alın: PayTR/Shopier bildirim (webhook) uçları, genel trafik limitlerinden muaf tutulmalı çünkü bu istekler kaçırılırsa ödeme alınıp ürün teslim edilmeme riski doğar.

Bu noktada bayi sistemi olan siteler için ek bir risk daha var: alt bayilerin API üzerinden yaptığı toplu sorgular da normal trafiğe karışıp gerçek saldırıyla karıştırılabilir. Bayi API anahtarlarına ayrı, daha yüksek ama yine de sınırlı bir kota tanımlamak bu karışıklığı önler.

Saldırı Anında Panik mi, Prosedür mü? Doğru İlk Dakikalar

Önlemler ne kadar iyi olursa olsun, bir gün gerçek bir saldırı yaşama ihtimaliniz sıfır değil. Bu durumda önceden hazırlanmış bir prosedürünüz olması, ilk 15 dakikada verdiğiniz kararların kalitesini doğrudan belirler.

• 1. Trafiği doğrula: Panelde/loglarda gerçekten anormal bir istek yığılması var mı, yoksa gerçek bir kampanya/haber kaynaklı meşru trafik artışı mı — ikisini karıştırmak yanlış aksiyona yol açar.
• 2. CDN'de saldırı modunu aç: Cloudflare Under Attack Mode veya benzeri bir JS-challenge katmanını devreye alın; bu, çoğu botu anında eler.
• 3. Kritik uçları geçici olarak sıkılaştırın: Bakiye yükleme ve kod teslim gibi hassas işlemlerde ek doğrulama isteyin, gerekirse geçici olarak kapatın.
• 4. Ödeme sağlayıcınızı ve tedarikçinizi bilgilendirin: Anormal trafik onların tarafında da fark edilip hesabınız otomatik askıya alınabilir; önceden haber vermek bunu önler.
• 5. Saldırı sonrası logları arşivleyin: Hangi IP aralıkları, hangi endpoint'ler, hangi saatlerde geldi — bu veri bir sonraki saldırıya karşı kural yazmanın en değerli kaynağıdır.

Saldırı geçtikten sonra en çok yapılan hata, "atlattık" deyip hiçbir şeyi kalıcı hale getirmemektir. O anda aldığınız geçici WAF kurallarının kalıcı hale getirilmesi, bir sonraki dalgayı çok daha kolay karşılamanızı sağlar.