DDoS Atak Önleme İçin Uygulanabilir Koruma Planı

DDoS atak önleme, tek bir güvenlik duvarı kuralı eklemekten çok katmanlı bir hazırlık gerektirir. Önce trafiğin bant genişliğini mi, sunucu kaynaklarını mı yoksa belirli bir uygulama işlevini mi tükettiğini ayırın. Ardından sağlayıcının ağ seviyesindeki filtrelemesini, gerekiyorsa web uygulaması kurallarını ve ölçülebilir bir geri dönüş planını birlikte kullanın.

DDoS atak önleme planına başlamadan önce erişimi ve sınırları belirleyin

Paylaşımlı hosting kullanıyorsanız genellikle işletim sistemi güvenlik duvarına veya ağ yönlendiricisine erişemezsiniz; kontrol panelindeki trafik, güvenlik ve destek seçenekleriyle sınırlı kalırsınız. Yönetilen bir sunucuda ise sağlayıcı paneli, sunucu yöneticisi ve uygulama günlükleri ayrı katmanlar olabilir. Kendi yönettiğiniz sunucuda ağ istatistikleri, web sunucusu günlükleri ve kaynak izleme verilerine ek olarak sağlayıcının DDoS politikası da önem taşır.

Değişiklik yapmadan önce mevcut DNS kayıtlarını, kaynak sunucu adresini, aktif güvenlik kurallarını ve normal trafik dönemindeki temel değerleri kaydedin. Mümkünse ilgili yapılandırmayı yedekleyin. Kaynak sunucunun adresi daha önce doğrudan açığa çıktıysa, yalnızca bir proxy veya CDN katmanı eklemek mevcut adresi kendiliğinden gizlemeyebilir; eski adresin erişim durumunu ayrıca sağlayıcıyla doğrulamak gerekir.

Saldırı türünü gözlemlenebilir belirtilerle ayırın

İlk olarak olayın başladığı saati not edin ve aynı zaman aralığındaki ağ kullanımı, CPU, bellek, bağlantı sayısı, HTTP durum kodları ve istek yollarını karşılaştırın. Bant genişliği veya bağlantı kapasitesi dolarken uygulama günlükleri az sayıda isteği gösteriyorsa trafik büyük olasılıkla sunucuya ulaşmadan önceki ağ katmanında etkili oluyordur. Bu durumda uygulama içindeki oran sınırlamasını artırmak, doygun bağlantıyı rahatlatmaz; sağlayıcının upstream filtrelemesi gerekir.

Buna karşılık trafik belirli bir giriş, arama veya oturum açma adresinde yoğunlaşıyor ve CPU ile veritabanı kullanımı yükseliyorsa uygulama katmanına yönelik bir yük söz konusu olabilir. İsteklerin kimlik doğrulama, sorgu maliyeti veya yanıt boyutu bakımından neden pahalı olduğunu inceleyin. Aynı IP adresinden gelen istekleri körlemesine engellemek yerine, meşru kullanıcıların da kullandığı yolu koruyan oran sınırlaması veya önbellekleme gibi daha dar bir kontrol seçin.

Koruma ayarlarını güvenli sırayla uygulayın

1. Sağlayıcı korumasını kontrol edin: Hosting ya da sunucu panelinde DDoS filtreleme, trafik temizleme, ağ koruması veya proxy yönlendirmesiyle ilgili etkinlik durumunu inceleyin. Bir saldırı sırasında bant genişliği doluyorsa, sağlayıcıya olay saati, etkilenen kaynak adresi ve trafik türüyle başvurun; uygulama günlüklerini tek başına yeterli kanıt saymayın. Koruma sağlayıcı tarafında etkinleştirildiğinde, yeni zaman aralığında ağ kullanımının ve erişilebilirliğin normale dönüp dönmediğini ölçün.
2. DNS ve kaynak sunucu yolunu doğrulayın: Alan adının gerçekten koruma katmanına yönlendiğini ve kaynak sunucunun doğrudan internete açık olup olmadığını kontrol edin. Bazı hizmetlerde DNS değişikliği, bazı hizmetlerde ise sağlayıcı panelinden ayrıca bir profil etkinleştirmeyi gerektirir. Kaynak adresi hâlâ doğrudan saldırı alıyorsa, sağlayıcının önerdiği erişim kısıtını uygulayın; yönetim erişimini yanlışlıkla kesmemek için yalnızca web trafiğini hedefleyin.
3. Uygulama katmanını daraltın: Saldırı belirli bir URL veya işlemde yoğunlaşıyorsa yalnız o işlem için oran sınırı, istek gövdesi sınırı, önbellekleme veya sağlayıcının sunduğu doğrulama kuralını değerlendirin. Değiştirdiğiniz eski değeri kaydedin ve tek seferde yalnız bir kuralı değiştirin. Giriş veya ödeme gibi meşru trafiğin kritik olduğu yolları genel bir engelleme kuralına dahil etmeyin.
4. Aynı işlemi yeni kanıtla doğrulayın: Değişiklikten sonra daha önce hata veren aynı URL veya aynı sağlık kontrolünü yeniden çalıştırın. Başlangıç ve bitiş saatini not ederek yeni ağ grafiğini, uygulama günlüklerini ve durum kodlarını inceleyin. Örneğin yeni kayıtlarda zaman aşımı yerine 429 görülmesi, oran sınırının devreye girdiğini gösterir; ancak meşru kullanıcıların da reddedildiğini fark ederseniz sınırı gevşetmek veya kuralı belirli bir pahalı uç noktaya daraltmak gerekir.
5. Gerekirse güvenli geri dönüş yapın: Sorun son kuraldan sonra başladıysa yalnızca o kuralı önceki kaydedilmiş değerine döndürün ve aynı işlemi tekrar test edin. Saldırı sürüyorsa tüm korumayı kapatmak yerine uygulama değişikliğini geri alıp sağlayıcının ağ seviyesindeki incelemesini sürdürün. Elde edilen zaman damgalarını ve anonimleştirilmiş özetleri paylaşın; parolaları, erişim anahtarlarını veya oturum belirteçlerini göndermeyin.

Hipotetik bir senaryoda doğru katmanı seçmek

Diyelim ki bir ürün kataloğu sitesi, normalde düşük CPU kullanırken aniden bağlantı kapasitesini dolduruyor ve web günlüklerinde anlamlı bir istek artışı görünmüyor. Bu gözlem, uygulama sorgularını optimize etmeye başlamadan önce sağlayıcının ağ katmanındaki filtreleme ve trafik temizleme seçeneğinin incelenmesini gerektirir. Filtreleme sonrasında ağ kullanımı düşüyor ancak tek bir arama adresinde CPU yeniden yükseliyorsa, ikinci aşamada yalnız bu arama işlemi için oran sınırlaması veya önbellekleme değerlendirilir.

Başka bir sonuçta günlükler, aynı oturum açma yoluna yönelen çok sayıda isteği gösterirken bant genişliği normal kalabilir. Bu durumda ağ kapasitesi satın almak sorunu çözmeyebilir; kimlik doğrulama işleminin maliyetini, oran sınırlamasının kapsamını ve meşru kullanıcıların etkilenip etkilenmediğini incelemek gerekir. Trafik farklı kaynaklardan dağıtılmışsa yalnız IP adresine dayalı bir kuralın yetersiz kalabileceğini, sağlayıcı destekli uygulama korumasının daha uygun olabileceğini unutmayın.

Korumanın işe yaradığını nasıl değerlendirmelisiniz?

Başarılı bir değişiklik yalnızca sitenin yeniden açılması değildir. Aynı zaman aralığında kaynak sunucunun erişilebilir kalması, normal kullanıcı işlemlerinin beklenen durum kodlarını alması, saldırı hedefindeki yolun kaynak tüketiminin düşmesi ve yeni günlüklerde anormal örüntünün azalması birlikte değerlendirilmelidir. Sağlayıcıya göre ölçüm ekranları, günlük ayrıntısı ve otomatik filtreleme davranışı değişebilir; bu nedenle paneldeki koruma adını değil, gözlenebilir sonucu temel alın.

İlk uygulama için mevcut ayarları ve başlangıç saatini kaydedip tek bir katmanı değiştirin. Sonuçları aynı işlemle yeniden doğrulayın; belirti sürerse son değişikliği geri alarak sağlayıcıdan ağ trafiğine ait zaman damgalı inceleme isteyin. Hosting veya sunucu seçeneklerini değerlendirirken gerekli erişim düzeyini İyibirNet üzerinden inceleyebilirsiniz.