DDoS Atak Önleme İçin Uygulanabilir Koruma Rehberi

DDoS atak önleme, tek bir ayarı açmaktan çok trafiğin kaynağını ve hedeflediği katmanı doğru belirleyerek korumayı uygun noktaya yerleştirmektir. Önce normal trafik davranışınızı ve sunucunun gerçek IP adresini belgeleyin; ardından CDN veya WAF ile web isteklerini, hosting sağlayıcının ağ korumasıyla da bağlantı taşmasını ele alın. Saldırı sürerken rastgele limit artırmak yerine, kanıta göre tek değişiklik yapıp aynı isteği yeni zaman damgalı kayıtlarla doğrulayın.

DDoS atak önleme hangi saldırıyı durdurmaya çalışır?

DDoS, dağıtık hizmet engelleme saldırısıdır. Çok sayıda kaynaktan gelen istek veya bağlantı, sitenin bant genişliğini, bağlantı tablosunu, işlemcisini ya da uygulamanın pahalı bir işlemini tüketebilir. Bu nedenle “DDoS koruması var” ifadesi tek başına yeterli değildir; korumanın ağ katmanında mı, HTTP isteklerinde mi, yoksa uygulama davranışında mı çalıştığını öğrenmek gerekir.

Bağlantı sayısı ve ağ trafiği sunucuya ulaşmadan önce kapasiteyi dolduruyorsa upstream filtreleme veya trafik temizleme hizmeti gerekir. İstekler HTTP seviyesinde siteye geliyor ancak belirli bir URL, ülke, istemci davranışı ya da oturum açma noktası aşırı yükleniyorsa CDN ve WAF daha uygun bir ilk katmandır. Trafik normal görünmesine rağmen tek bir arama veya giriş işlemi veritabanını yoruyorsa sorun DDoS ile birlikte uygulama kaynak tüketimi de olabilir; burada sorgu optimizasyonu ve uygulama oran sınırlaması incelenmelidir.

Koruma katmanını seçerken izlenecek yol

Önce olay sırasında görülen belirtiyi sınıflandırın. Sunucuya hiç ulaşılamıyor, ağ arayüzünde kapasite doluyor veya sağlayıcı bağlantı taşmasını bildiriyorsa yalnızca WordPress eklentisi ya da sunucu içi kural eklemek geç kalmış olabilir; sağlayıcıdan ağ seviyesinde filtreleme ve saldırı türünün raporlanmasını isteyin. Site açılıyor fakat belirli HTTP yollarında gecikme ve çok sayıda benzer istek görülüyorsa CDN/WAF üzerinde oran sınırlama, bot doğrulama veya kural tabanlı filtreleme değerlendirilir.

İkinci seçim, trafiği hangi uç noktanın karşılayacağıyla ilgilidir. CDN kullanacaksanız DNS kaydının CDN üzerinden geçtiğini, korunan alan adlarının ve HTTPS sertifika akışının doğru yapılandırıldığını kontrol edin. Ancak origin sunucunun gerçek IP adresi geçmiş DNS kayıtlarında, e-posta başlıklarında veya başka bir serviste görünüyorsa saldırgan CDN’yi atlayabilir. Bu bulguya karşı origin erişimini yalnızca güvenilir CDN çıkış aralıkları veya gerekli yönetim kaynaklarıyla sınırlandırmak gerekebilir; sağlayıcının güvenlik duvarı sözdizimi ve adres listeleri değişebileceği için paneldeki güncel yönergeler kullanılmalıdır.

Hipotetik bir seçim örneği

Diyelim ki küçük bir ürün kataloğu CDN arkasında çalışıyor ve saldırı sırasında ana sayfa açılırken arama URL’si sürekli zaman aşımına uğruyor. CDN panelinde istek sayısı özellikle arama yolunda yükseliyor, origin sunucunun ağ trafiği ise kapasitesine ulaşmıyorsa önce tüm siteyi kapatmak yerine yalnızca arama uç noktasına düşük riskli bir oran kuralı ve önbellekleme politikası uygulanır. Arama sonuçları kişiye özel olduğu için agresif önbellekleme uygun değilse, geçici oran sınırlaması ve uygulama sorgularının hafifletilmesi seçilir. Buna karşılık sağlayıcı origin’e yönelen bağlantı taşması bildirirse aynı kural yeterli değildir; ağ seviyesinde filtreleme gerekir.

Uygulama öncesi ve olay anı kontrol akışı

İlk olarak normal durumu kaydedin: alan adının DNS kayıtları, CDN etkinliği, origin IP’si, ortalama istek yolları, yanıt kodları ve saldırı olmayan bir zaman aralığındaki trafik görünümü. Bu bilgiler, “çok ziyaretçi” ile “anormal bağlantı modeli” arasındaki farkı anlamaya yardım eder. Yönetilen bir hosting panelinde yalnızca erişebildiğiniz trafik ve hata raporlarını inceleyebilirsiniz; yönetici kontrollü sunucuda ise ağ cihazı, güvenlik duvarı ve web sunucusu günlükleri sağlayıcı politikalarına göre ayrıca görülebilir.

1. Olayın saatini ve belirtisini not edin. Yavaşlama tüm alan adında mı, tek bir URL’de mi, yoksa sunucu bağlantısında mı oluşuyor bakın. Aynı dakikaya ait CDN, hosting ve uygulama kayıtlarını karşılaştırın; yalnız uygulama günlüğünde yoğunluk varsa ağ saldırısı sonucuna hemen varmayın.
2. Origin’e doğrudan erişimi kontrol edin. DNS geçmişi ve sağlayıcı panelindeki sunucu adresi, CDN dışından ulaşılabilir bir IP gösteriyorsa koruma katmanı atlanıyor olabilir. Sağlayıcının güvenlik duvarında yalnız gerekli kaynaklara izin verin, mevcut kuralı kaydedin ve başka kuralları topluca değiştirmeyin.
3. Tek bir hedefli kural uygulayın. Kayıtlarda belirli bir URL’ye olağan dışı tekrarlar görünüyorsa yalnız o yolu ve gerekli koşulları kapsayan oran sınırlamasını CDN/WAF katmanında etkinleştirin. Kural, normal kullanıcıların işlemini de engelliyorsa eşiği körlemesine yükseltmek yerine oturum açmış kullanıcılar, API istemcileri ve güvenilir otomasyon için ayrı davranış tanımlayın.
4. Aynı başarısız işlemi yeniden deneyin ve yeni kanıt arayın. Kural etkinleştiği zamanı yazın; aynı URL’yi benzer koşulda açıp yeni CDN kaydında engellenen veya sınırlanan isteklerin görünüp görünmediğini kontrol edin. Origin üzerindeki yeni bağlantı ve hata kayıtları azaldıysa müdahale doğru katmanı etkiliyor olabilir. Yeni kayıtlar farklı bir URL’de yoğunlaşıyorsa ilk kuralı genişletmeden o hedefi ayrı değerlendirin.

Değişiklikten önce eski değeri ve kural kapsamını saklayın; her denemede yalnızca bir faktörü değiştirin. Trafik normale dönerse geçici oran kuralını hemen silmek yerine, normal kullanıcıların yanıt kodlarını ve gecikmesini izleyerek kademeli olarak eski politikaya dönün. Sorun sürüyorsa kuralı daha geniş ve belirsiz hâle getirmek yerine sağlayıcıdan saldırı hacmini, protokolünü, hedef IP’sini ve temizleme noktasını içeren olay raporu isteyin. Ağ kapasitesi doluyorsa uygulama ayarıyla oynanmaz; sağlayıcının upstream koruması veya farklı bir ağ mimarisi gerekir.

Korumanın gerçekten çalıştığını nasıl anlarsınız?

İlk kullanımda yalnızca “saldırı engellendi” etiketine güvenmeyin. Korunan alan adının CDN üzerinden yanıt verdiğini, origin’in beklenmeyen doğrudan bağlantı kabul etmediğini, normal bir sayfanın doğru içerik ve HTTPS ile açıldığını, sınırlanan uç noktanın ise tanımlı eşiği aşan isteklerde kontrollü bir yanıt verdiğini gözlemleyin. Bu sonuçlar, korumanın etkin olduğunu gösterir; fakat gerçek kullanıcı trafiğinin tamamını veya yeni bir saldırı türünü garanti etmez.

Site trafiğinin niteliğini ve sunucu altyapısını birlikte değerlendirmek için İyibirNet üzerindeki ilgili hosting seçeneklerini inceleyebilirsiniz. Seçim yaparken özellikle DDoS korumasının hangi katmanda sağlandığını, origin izolasyonunun nasıl uygulandığını, olay sırasında hangi kayıtların paylaşılabildiğini ve geçici kuralların nasıl geri alınacağını yazılı olarak doğrulayın.

Sonraki adım: Siteniz için normal trafik aralıklarını, origin adresini ve CDN/WAF sağlayıcısının acil müdahale kanalını tek bir kayıt altında toplayın; sonraki olayda çözüm aramaya gözlem verisiyle başlayın.