Web Sitenize Yönelik DDoS Saldırılarını Önleme Yolları

DDoS saldırısı nedir

Dağıtık hizmet reddi (DDoS) saldırısı, bir web sitesini veya hizmeti aynı anda birçok kaynaktan gelen trafik ya da isteklerle boğarak erişilemez hale getirmeye çalışır. Bir sızma girişiminden farklı olarak amaç genellikle veri çalmak değil, meşru kullanıcıların size ulaşmasını engellemektir. Kaynaklar çoğu zaman ele geçirilmiş cihazlar veya kiralanmış altyapıdır; bu yüzden tek bir IP adresini engellemek nadiren işe yarar.

Bu rehber savunmayla ilgilidir: makul korumalar seçebilmeniz, altyapınızı yapılandırabilmeniz ve bir saldırı yaşanırsa sakin bir şekilde müdahale edebilmeniz için ana saldırı kategorilerini anlamak. Hiçbir web sitesi tamamen bağışık hale getirilemez, ancak iyi bir hazırlık bir saldırının uzun bir kesintiye dönüşme olasılığını büyük ölçüde azaltır.

DDoS saldırılarının ana kategorileri

Saldırılar genellikle tüketmeye çalıştıkları kaynağa göre gruplandırılır. Kategoriyi anlamak, savunmanın nerede konumlanması gerektiğini söyler.

Kilit nokta şudur: hacimsel saldırılar genellikle tek bir sunucunun veya küçük bir hosting bağlantısının karşılayabileceğinin çok ötesindedir; bu nedenle sunucunun kendisinde filtreleme yapmak çok geç kalır. Uygulama katmanı saldırıları ise bant genişliği açısından küçük ama CPU açısından pahalı olabilir; burada kendi uygulamanızı iyileştirmek büyük fark yaratır.

Sitenizin önüne bir koruma katmanı koyun

Çoğu web sitesi için en etkili tek adım, trafiği geniş ve dağıtık kapasiteye sahip bir sağlayıcı üzerinden geçirmektir: DDoS korumalı bir CDN, özel bir saldırı azaltma hizmeti veya yerleşik filtrelemeye sahip bir bulut yük dengeleyici. Bu ağlar hacimsel selleri birçok konuma dağıtarak emer ve kötü amaçlı trafiği size ulaşmadan filtreler.

Seçenekleri karşılaştırırken pazarlama iddialarına güvenmek yerine pratik sorular sorun:

• Hangi katmanlar kapsanıyor (ağ, protokol, uygulama) ve bunlardan herhangi biri ücretli bir ek mi?
• Koruma her zaman açık mı, yoksa yalnızca tespitten sonra mı devreye giriyor?
• Bant genişliği veya istek sınırları var mı ve saldırı trafiği için ücretlendiriliyor musunuz?
• Aktif bir olay sırasında destek süreci nasıl işliyor?
• Belirli yollar için özel kurallar, hız sınırları ve doğrulama (challenge) adımları tanımlayabiliyor musunuz?

Fiyatlar ve sınırlar sık değişir ve paketler arasında farklılık gösterir; kapsamı varsaymak yerine sağlayıcınızın güncel belgelerini kontrol edin. Mümkünse korumayı sakin bir dönemde etkinleştirin ve sitenizin, formlarınızın ve API’lerinizin bu katmanın arkasında sorunsuz çalıştığını saldırı gelmeden önce test edin.

Ana sunucunuzu gizleyin ve kilitleyin

Bir koruma katmanı ancak saldırganlar onu dolaşamıyorsa işe yarar. Ana (origin) sunucunuzun IP adresi biliniyorsa, saldırgan trafiği doğrudan ona gönderip CDN’i tamamen atlayabilir.

1. Ana sunucu IP’sini sızdırmayın. Eski DNS kayıtları, mail veya FTP gibi korunmayan alt alan adları, e-posta başlıkları ve geçmiş DNS verileri IP’yi ortaya çıkarabilir. Korumayı etkinleştirdikten sonra yeni bir IP’ye geçmeyi düşünün.
2. Web trafiğine yalnızca sağlayıcıdan izin verin. Güvenlik duvarını 80 ve 443 numaralı portları yalnızca CDN’inizin yayımladığı IP aralıklarından kabul edecek şekilde yapılandırın veya sağlayıcınız destekliyorsa kimliği doğrulanmış bir tünel ya da origin sertifikası kullanın.
3. Yönetim erişimini kısıtlayın. SSH, kontrol panelleri ve veritabanı portları tüm internete açık olmamalıdır; bunları VPN’lerle veya bilinen adreslerle sınırlayın.

TLDix hosting sorgulama aracı, bir ana bilgisayar adının nereye çözümlendiği hakkında kamunun neler öğrenebileceğini hızlıca görmenizi sağlar; bu da alt alan adlarını sızıntılar açısından denetlerken işe yarar.

Uygulama katmanını sıkılaştırın

Uygulama katmanı selleri gerçek ziyaretçileri taklit eder; bu yüzden savunma, her isteği ucuz hale getirmeye ve kötüye kullanım desenlerini sınırlamaya odaklanır.

Önbelleği agresif kullanın

CDN önbelleğinden sunulan sayfalar ana sunucunuza hiç dokunmaz. Statik dosyaları uzun süre önbelleğe alın ve dinamik ama kişiye özel olmayan sayfalar için bile kısa süreli önbelleği düşünün. Önbellekten dönen her yanıt, sunucunuzun hesaplamak zorunda olmadığı bir yanıttır.

Makul hız sınırları belirleyin

Giriş, arama, ödeme ve API’ler gibi pahalı uç noktalarda istemci başına istekleri sınırlayın. Nginx için bir örnek:

http {
    limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
    limit_conn_zone $binary_remote_addr zone=connperip:10m;

    server {
        location /search {
            limit_req zone=perip burst=20 nodelay;
            limit_conn connperip 20;
        }

        client_body_timeout 10s;
        client_header_timeout 10s;
    }
}

Buradaki rakamlar yer tutucudur. Gerçek sınırları kendi trafik günlüklerinize dayandırın ve kurumsal veya mobil ağların arkasında birçok kullanıcının tek bir IP’yi paylaşabileceğini unutmayın. Trafik bir CDN üzerinden geliyorsa, CDN’in kendisini sınırlamamak için gerçek istemci IP başlığını doğru yapılandırın.

Pahalı işleri azaltın

• Yavaş veritabanı sorgularını optimize edin ve sık yapılan aramalar için indeksler ekleyin.
• Rapor oluşturma veya görsel işleme gibi ağır görevleri arka plan kuyruklarına taşıyın.
• Doğrulama adımlarını veya CAPTCHA’ları her yerde değil, hassas formlarda seçici olarak kullanın.
• Yavaş bağlantıların kaynakları süresiz açık tutamaması için zaman aşımları ayarlayın.

Kapasite ve kontrollü performans düşüşünü planlayın

Dayanıklılık yalnızca filtrelemeden ibaret değildir. Siteniz baskı altındayken ne yapması gerektiğini düşünün. Uygulama çökerse ana sayfa ve önemli açılış sayfaları CDN’den statik dosya olarak sunulabilir mi? Öneriler, canlı arama veya ağır bileşenler gibi zorunlu olmayan özellikler, kaynak tasarrufu için bir özellik bayrağıyla (feature flag) kapatılabilir mi? Bulut ortamlarında otomatik ölçekleme, orta düzeydeki uygulama katmanı artışlarını karşılayabilir; ancak saldırı trafiğini karşılamak için ölçeklemek hızla pahalıya patlayabileceğinden harcama sınırları ve uyarılar tanımlayın.

Bileşenleri ayırmak da yardımcı olur. API’yi, yönetim alanını ve genel siteyi farklı ana bilgisayar adlarında veya hizmetlerde barındırmak, birine yönelik bir selin diğerlerini otomatik olarak çökertmemesini sağlar ve en önemli yerlerde daha sıkı kurallar uygulamanıza olanak tanır.

DNS’i ve alan adının kendisini unutmayın

Yetkili DNS’iniz çökerse, web sunucuları sorunsuz olsa bile sitenize ulaşılamaz. Anycast altyapısına ve yedekliliğe sahip bir DNS sağlayıcısı kullanın; arka plan bilgisi için anycast DNS’in nasıl çalıştığı yazımıza bakın. Bazı kuruluşlar ek dayanıklılık için iki bağımsız DNS sağlayıcısı kullanır; bu da bölgelerin senkronize tutulmasını gerektirir.

Kaydın kendisini de koruyun. Bir olay sırasında ad sunucularını hızla değiştirmeniz gerekebilir; bu yüzden kayıt firması erişiminin güvenli olduğundan ve alan adının süresinin dolmak üzere olmadığından emin olun. Süresi geçmiş bir kaydın bir saldırıyı daha da kötüleştirmemesi için yenileme tarihlerini TLDix alan adı takibinde izleyin.

İzleme ve erken uyarı

Bir saldırıyı ne kadar erken fark ederseniz o kadar hızlı müdahale edebilirsiniz. Faydalı sinyaller şunlardır:

• Birden fazla harici konumdan yapılan uptime kontrolleri.
• Saniyedeki istek sayısında, bant genişliğinde veya hata oranlarında (özellikle 5xx yanıtlarda) ani artışlar.
• Trafiğin alışılmadık biçimde tek bir URL’de, kullanıcı aracısında veya bölgede yoğunlaşması.
• Bunu açıklayan bir iş nedeni olmadan artan sunucu CPU’su, bellek, bağlantı sayısı veya veritabanı yükü.

İzlemeyi, izlediği altyapıdan bağımsız tutun; aynı sunucuda barındırılan bir uyarı hizmeti tam da ihtiyaç duyduğunuz anda susar.

Anormalliklerin belirgin olması için normal trafiğin bir referansını oluşturun. Uyarılar yalnızca kimsenin bakmadığı bir gelen kutusuna değil, harekete geçebilecek bir kişiye ulaşmalıdır.

Günlükleri saldırıya hazır tutun

Bir saldırı sırasında doğru kuralları yazabilmek için hangi URL’lerin, IP aralıklarının ve kullanıcı aracılarının trafiği oluşturduğunu hızla görebilmeniz gerekir. Web sunucusu ve CDN günlüklerinin yeterince uzun süre saklandığından, gerçek istemci IP’sini kaydettiğinden ve gerektiğinde kolayca filtrelenebildiğinden emin olun. Yoğun trafikte günlük dosyalarının diski doldurmaması için döndürme (rotation) ayarlarını da kontrol edin; dolu bir disk, saldırının etkisini kendi başına büyütebilir.

Olay müdahale kontrol listesi

Planınızı ihtiyaç duymadan önce yazın. Basit bir sürüm:

1. Bunun meşru bir trafik artışı, hatalı bir dağıtım veya bir üst sağlayıcı kesintisi değil, gerçekten bir saldırı olduğunu doğrulayın.
2. Önceden hazırladığınız yükseltme (eskalasyon) yolunu kullanarak hosting ve koruma sağlayıcınızla iletişime geçin.
3. Daha sıkı modları etkinleştirin: daha yüksek güvenlik seviyeleri, hedeflenen yollarda doğrulama adımları, gerekçeli olduğunda geçici coğrafi kurallar veya hız kuralları.
4. Uygulama zorlanıyorsa önemli sayfaların önbellekteki veya statik bir sürümünü sunun.
5. Kullanıcılarla, ana siteden ayrı barındırılan bir durum sayfası veya sosyal medya kanalı üzerinden iletişim kurun.
6. Sonrasında günlükleri inceleyin, kuralları ayarlayın ve planı güncelleyin.

Yalnızca sistemleri değil, insanları da hazırlayın

Bir olay sırasında giriş bilgilerini ve telefon numaralarını aramakla zaman kaybedilir. Sağlayıcı destek kanallarını, hesap numaralarını ve DNS ya da koruma ayarlarını değiştirmeye kimin yetkili olduğunu içeren güncel bir iletişim listesi tutun. Bunu, ana siteniz ve e-postanız etkilense bile erişilebilecek bir yerde saklayın. Yılda bir iki kez yukarıdaki kontrol listesini adım adım gözden geçiren kısa bir masa başı tatbikatı yapmak, süresi dolmuş kimlik bilgileri veya belirsiz sorumluluklar gibi açıkları gerçek bir saldırıdan çok önce ortaya çıkarır.

Bir saldırıya fidye talebi eşlik ediyorsa sağlayıcınızı sürece dahil edin ve durumu ilgili makamlara bildirin. Bu hukuki tavsiye değildir; yerel gereklilikleri kontrol edin.