DDoS saldırıları: katmanları tanımak ve hazırlıklı olmak

DDoS, tek bir tehdit değil bir saldırı ailesidir. Hattı doldurmayı hedefleyen saldırı ile sunucunun işlemcisini tüketmeyi hedefleyen saldırı bambaşka savunmalar gerektirir. Doğru savunmayı seçmek için önce hangi katmanın hedef alındığını anlamak gerekir.

Üç saldırı ailesi

• Hacim tabanlı (volümetrik): UDP taşması, DNS ve NTP yansıma saldırıları. Amaç bant genişliğini doldurmaktır; onlarca hatta yüzlerce Gbit seviyesine çıkabilir. Sunucuda yapılacak hiçbir ayar bunu durduramaz, çünkü hat zaten sunucuya varmadan tıkanır. Savunma veri merkezi ve operatör seviyesindedir.
• Protokol tabanlı: SYN taşması, parçalanmış paket saldırıları. Amaç bağlantı tablolarını ve durum tutan cihazları tüketmektir. SYN çerezleri ve bağlantı hız sınırlarıyla önemli ölçüde savuşturulur.
• Uygulama katmanı (L7): Saniyede binlerce HTTP isteği; özellikle arama, filtreleme ve sepet gibi pahalı sayfalara yönelir. Trafik hacmi düşük olabilir; yine de sunucuyu tüketir. En zoru budur, çünkü istekler meşru trafikten ayırt edilmesi zordur.

Hangi kaynağın tükendiğini ölçün

Savunma seçimi tahmine değil ölçüme dayanır. Saldırı sürerken üç soruyu cevaplayın:

• Hat mı doldu? sar -n DEV 1 çıktısı ya da sunucu panelindeki ağ grafiği. Gelen trafik hat kapasitesine dayanmışsa savunma sunucuda değil, ağdadır.
• Bağlantı tablosu mu doldu? ss -tn state syn-recv | wc -l — binlerce yarım açık bağlantı SYN taşmasına işaret eder.
• İşlemci mi tükendi? Ağ trafiği olağan seviyedeyken PHP-FPM veya web sunucusu süreçleri işlemciyi doldurmuşsa saldırı uygulama katmanındadır.

Uygulama katmanı saldırısında hedefi bulmak için erişim günlüğünü sayın:

awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -20

Aynı komutu istemci IP alanı için de çalıştırın. İki listeyi yan yana koyduğunuzda hangi sayfanın ve hangi ağların hedef olduğunu görürsünüz. Kural yazmadan önce bu iki liste elinizde olmalı; yoksa yazdığınız kural tahmindir.

Saldırı mı, yoksa başarı mı?

Ani trafik artışının kaynağını doğrulamadan savunma açmayın; meşru kampanya trafiğini engelleyen bir kural, saldırının yapacağından fazla zarar verir. Ayırt etmek için bakın:

• İstekler tek bir yola mı yığılıyor, yoksa sitede doğal bir gezinti deseni var mı?
• User-Agent alanları tekdüze mi? Meşru trafikte yüzlerce farklı değer olur.
• Coğrafi dağılım normal mi? Türkiye'ye satış yapan bir sitede aniden başka kıtalardan gelen yığın şüphelidir.
• Oturum davranışı var mı? Gerçek ziyaretçi CSS ve görsel de indirir; saldırı botu genellikle yalnız HTML ister.

Uygulama katmanında pratik savunma

1. Hız sınırı. IP başına saniyedeki istek sayısını sınırlayın; giriş ve arama uçlarında daha sıkı olsun. nginx'te limit_req_zone bunun için vardır.
2. Önbellek. Anonim ziyaretçiye giden sayfalar önbellekten veriliyorsa, saldırı isteklerinin büyük bölümü PHP'ye hiç ulaşmaz. Önbellek en ucuz DDoS savunmasıdır.
3. Doğrulama sınaması. Şüpheli desende gelen isteklere JavaScript sınaması veya CAPTCHA uygulayın; basit botların çoğu bunu geçemez.
4. Pahalı uçları koruyun. Arama ve filtre sayfalarına önbelleklenebilir sonuç döndürün ya da oturum zorunluluğu koyun.

nginx'te hız sınırı iki satırla tanımlanır. Bölge tanımı http bloğunda durur, uygulama ise korumak istediğiniz konumda:

limit_req_zone $binary_remote_addr zone=genel:10m rate=10r/s;
limit_req zone=genel burst=20 nodelay;

burst değeri, ani ama meşru yığılmalara nefes payı bırakır; onsuz sayfayı hızlı yenileyen gerçek ziyaretçi de 503 alır. Giriş ve arama uçları için ayrı bir bölge tanımlayıp oranı 1–2 r/s seviyesine çekin. Kuralı önce limit_req_status 429 ile işaretleyip günlüğe bakın: engellenenler gerçekten bot mu?

Protokol tabanlı saldırıda çekirdek ayarları belirleyicidir. net.ipv4.tcp_syncookies = 1 açıkken sunucu, bağlantı tablosunu doldurmadan yarım açık isteklere cevap verebilir; tcp_max_syn_backlog değerini yükseltmek kuyruğa alan açar. Bunlar saldırı anında aranacak değil, kurulum gününde yapılacak ayarlardır.

Altyapı tarafındaki savunma

Hacim tabanlı saldırıda tek etkili savunma, trafiğin sunucuya ulaşmadan temizlenmesidir. Veri merkezi seviyesinde çalışan filtreleme sistemleri, anormal desenleri tanıyıp zararlı paketleri düşürür; meşru trafik geçmeye devam eder. Altyapımızda ağ genelinde DDoS filtreleme uygulanır, hedefli saldırılarda ek donanımsal koruma devreye alınır.

Kaynak sunucunun IP adresini gizli tutmak da yardımcı olur. Bir CDN veya ters vekil arkasındasınız ama kaynak IP eski DNS kayıtlarından, e-posta başlıklarından veya SSL sertifika şeffaflık kayıtlarından sızıyorsa saldırgan doğrudan sunucuyu hedefler. Kaynak sunucunun güvenlik duvarında yalnız vekil ağının IP bloklarına 80/443 açmak bu boşluğu kapatır. Statik içeriği dağıtan bir katman zaten varsa yük de dağılır; CDN'in ne zaman gerektiğini ayrı bir yazıda ele aldık.

Olay anında ne yapılır?

1. Doğrulayın. Sunucu yükü mü arttı, hat mı doldu? İkisi farklı cevaplar gerektirir.
2. Kaydedin. Saldırı sürerken erişim kaydının bir kopyasını alın; sonrasında kural yazmak için gereken tek kaynak budur.
3. Daraltın. Ülke, ağ bloğu, User-Agent veya istenen yol bazında en dar kuralı yazın. Geniş engelleme meşru müşteriyi de keser.
4. Haber verin. Hacim saldırısında veri merkezi ekibiyle temasa geçin; operatör seviyesinde filtreleme uygulanabilir.
5. Sonrasında gözden geçirin. Hangi uç noktalar pahalıydı, hangi eşikler yetersiz kaldı? Kuralları kalıcı hale getirin.

Bu savunmalar ne zaman yanlış olur?

Her savunmanın bir maliyeti vardır. Yanlış yerde açılan koruma, saldırının yapacağı zararı sizin elinizle yapar.

• Herkese doğrulama sınaması. Dönüşüm oranını düşürür ve arama motoru tarayıcılarını engelleyebilir. Yalnız şüpheli desende ve geçici olarak açın.
• Ülke bazlı toptan engelleme. Yurt dışındaki müşterilerinizi, ödeme sağlayıcısının geri bildirim isteklerini ve dış izleme servislerini de keser.
• Kalıcılaşan acil kural. Olay günü aceleyle yazılan geniş kural, aylar sonra kimsenin sebebini hatırlamadığı bir erişim sorununa dönüşür. Her acil kurala bitiş tarihi ve gerekçe notu iliştirin.
• Yalnız IP engellemeye güvenmek. Dağıtık saldırıda binlerce kaynak vardır; liste kovalamakla bitmez. Desen bazlı kural yazın.

Uygulama katmanında ilk set: nginx ile istek sınırı

Ağ katmanındaki büyük hacimli saldırılar sunucuya ulaşmadan altyapıda süzülmelidir; sunucunun kendisi bunlara karşı bir şey yapamaz. Ama düşük hacimli, sayfa isteğiyle yapılan saldırılarda ve hatalı botlarda ilk set web sunucusudur. nginx bunu iki modülle yapar: limit_req saniyedeki istek sayısını, limit_conn eşzamanlı bağlantı sayısını IP başına sınırlar.

# /etc/nginx/conf.d/sinir.conf  (http bağlamı)
limit_req_zone  $binary_remote_addr zone=istek:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=baglanti:10m;
limit_req_status  429;
limit_conn_status 429;

# server ya da location içinde
location / {
    limit_req  zone=istek burst=20 nodelay;
    limit_conn baglanti 20;
}

Bu yapılandırmayı bir deneme sunucusunda kurup ölçtük. Saniyenin altında art arda gönderilen 40 isteğin 25'i geçti, 15'i 429 aldı: ilk istek, burst=20 ile tanınan yirmi isteklik pay ve döngü sürerken saniyede 10 hızla yenilenen birkaç istek. Aynı istemci saniyede 8 istekle, yani sınırın altında üç saniye boyunca istek gönderdiğinde 24 isteğin hepsi geçti. Reddedilen her istek hata günlüğüne şu biçimde düştü:

limiting requests, excess: 20.640 by zone "istek", client: 127.0.0.1, ...

Üç ayarın neden böyle seçildiğini bilmek, sınırı kendi sitenize uyarlarken işe yarar:

• burst ve nodelay: Bir sayfa açılışı onlarca isteği aynı anda gönderir. burst olmadan gerçek ziyaretçiler de reddedilir; nodelay olmadan pay içindeki istekler sıraya alınıp yavaşlatılır.
• limit_req_status 429: nginx varsayılan olarak 503 döndürür; bu, izleme sisteminizde "sunucu çöktü" gibi görünür. 429 "çok fazla istek" demektir ve nedenini doğru anlatır.
• $binary_remote_addr: Sunucunuz bir CDN ya da ters vekil arkasındaysa bu değişken ziyaretçinin değil vekilin adresidir ve tüm ziyaretçiler aynı kovaya düşer. Önce gerçek istemci adresini real_ip modülüyle doğru alın.

Sınırı tüm siteye tek değerle uygulamak yerine pahalı adreslere daha sıkı uygulayın: giriş sayfası, arama, sepet ve API uçları saniyede birkaç istekle sınırlanabilirken statik dosyalar hiç sınırlanmayabilir. Hangi IP adreslerinin günlüğe en çok düştüğünü inceledikten sonra bir adresin kim olduğunu görmek için IP sorgulama aracını kullanabilirsiniz.

Hazırlık, saldırı gününden önce yapılır

Saldırı anında sakin kalmanın tek yolu, önceden hazırlanmış olmaktır. Şunlar hazır olsun: sunucunuzun normal trafik profilinin bilinmesi (böylece anormali tanırsınız), izleme ve uyarı düzeneği, veri merkezi acil iletişim kanalı, hız sınırı kurallarının hazır ama pasif bekletilmesi. Yüksek riskli hizmetlerde DDoS korumalı fiziksel sunucu veya oyun sunucusu tarafında koruma zaten varsayılan olarak gelir; oyun sunucuları saldırıların en sık hedefidir.

Sık sorulan sorular