DDoS Dayanıklılık Testi Nasıl Yapılır? Kapasite, Eşik Değer ve Darboğaz Analizi

Bir kurumun DDoS saldırılarına karşı güçlü olduğunu söylemek kolaydır.

Bunu ölçmek daha zordur.

Çünkü DDoS dayanıklılığı yalnızca internet hattının kapasitesinden ibaret değildir.

Bir sistemin gerçek sınırı;

firewall,

router,

load balancer,

WAF,

CDN,

Anti-DDoS servisi,

uygulama sunucusu,

API Gateway,

database,

DNS altyapısı

gibi birçok bileşenden herhangi birinde ortaya çıkabilir.

Bu nedenle kurumsal DDoS güvenliğinde doğru soru:

“Kaç Gbps saldırıya dayanıyoruz?”

değil,

“Hangi trafik profilinde, hangi bileşen, hangi eşikte darboğaza giriyor ve hizmet kalitesi ne zaman bozuluyor?”

olmalıdır.

İşte bu sorunun cevabı DDoS Dayanıklılık Testi, DDoS Resilience Testing, Capacity Planning, Threshold Analysis ve Bottleneck Analysis süreçleriyle ortaya çıkar.

Profesyonel bir DDoS dayanıklılık testi; yalnızca trafik üretmek değil, sistemin saldırı altındaki davranışını ölçmek, kritik eşikleri belirlemek, güvenlik kontrollerini doğrulamak ve hizmetin hangi seviyeye kadar sürdürülebilir olduğunu anlamaktır.

DDoS Dayanıklılık Testi Nedir?

DDoS Dayanıklılık Testi, kurumun internet servislerinin farklı DDoS trafik profilleri altında ne kadar erişilebilir kaldığını ve güvenlik kontrollerinin ne kadar etkili çalıştığını ölçen yetkilendirilmiş güvenlik testidir.

Bu test kapsamında;

• volumetric trafik,
• Layer 3/4 saldırı profilleri,
• Layer 7 istek yoğunluğu,
• DNS trafiği,
• API yükü,
• connection exhaustion,
• bot trafiği

gibi farklı senaryolar değerlendirilebilir.

Amaç sistemi kontrolsüz şekilde çökertmek değildir.

Amaç güvenli sınırlar içerisinde kapasite eğrisini çıkarmaktır.

DDoS Capacity Planning Nedir?

DDoS Capacity Planning, kurumun saldırı trafiğine karşı sahip olduğu teknik kapasitenin önceden analiz edilmesidir.

Örneğin şu sorular sorulur:

Internet bağlantısı kaç Gbps?

Firewall maksimum kaç PPS işleyebiliyor?

Load balancer kaç CPS kaldırabiliyor?

WAF saniyede kaç request'i analiz edebiliyor?

API Gateway kaç RPS altında SLA içinde kalıyor?

DNS servisi kaç QPS kaldırabiliyor?

Bu değerlerin tamamı birlikte değerlendirilmelidir.

Çünkü zincirin en zayıf halkası gerçek DDoS kapasitesini belirler.

Gbps DDoS Kapasitesini Tek Başına Gösterir mi?

Hayır.

Bu en önemli yanlış anlamalardan biridir.

Örneğin kurumun internet hattı:

20 Gbps

olsun.

İlk bakışta oldukça güçlü görünebilir.

Ancak firewall sadece:

3 milyon PPS

işleyebiliyorsa küçük paketlerden oluşan yoğun saldırı bu sınırı daha erken aşabilir.

Benzer şekilde network tamamen ayakta kalabilir fakat uygulama:

5.000 RPS

üzerinde SLA dışına çıkabilir.

Bu nedenle DDoS kapasitesi en az şu dört metrik üzerinden değerlendirilmelidir:

Gbps

PPS

CPS

RPS

PPS Neden Kritik?

Packets Per Second – PPS, saniyede işlenen paket sayısını gösterir.

Düşük boyutlu paketlerden oluşan saldırılar network cihazlarının packet processing kapasitesini zorlayabilir.

Örneğin:

5 Gbps trafik yüksek görünebilir.

Ama bu trafik büyük paketlerden oluşuyorsa PPS görece düşük olabilir.

Başka bir saldırı 2 Gbps olabilir.

Ancak çok küçük paketler nedeniyle PPS çok daha yüksek olabilir.

İkinci saldırı firewall açısından daha yıkıcı olabilir.

Bu nedenle üretici datasheet'lerinde yer alan throughput değerleri tek başına yeterli değildir.

CPS Neden Önemlidir?

Connections Per Second – CPS, saniyede oluşturulan yeni bağlantı sayısını gösterir.

Stateful firewall ve load balancer'lar için kritik bir metriktir.

Bir cihaz milyonlarca concurrent session destekleyebilir.

Ancak saniyede yeni bağlantı oluşturma kapasitesi daha düşük olabilir.

SYN Flood veya TCP Connection Flood gibi saldırılar bu nedenle CPS limitini hedefleyebilir.

RPS Nedir?

Requests Per Second – RPS, web uygulaması veya API'ye saniyede gelen request sayısını ifade eder.

Layer 7 DDoS testlerinde en kritik metriklerden biridir.

Ama RPS tek başına da yeterli değildir.

Çünkü:

1.000 RPS statik içerik

ile

1.000 RPS ağır database sorgusu

aynı etkiyi oluşturmaz.

Bu nedenle RPS ile birlikte request cost da değerlendirilmelidir.

QPS Nedir?

DNS ortamlarında sık kullanılan metriklerden biri:

Queries Per Second – QPS

değeridir.

DNS servisinin saniyede kaç sorguya cevap verebildiğini gösterir.

DDoS dayanıklılık testi sırasında;

normal QPS,

peak QPS,

attack QPS,

response latency,

timeout oranı

birlikte analiz edilmelidir.

Traffic Baseline Nedir?

DDoS testi başlamadan önce sistemin normal davranışı bilinmelidir.

Bu normal davranışa Traffic Baseline denir.

Örneğin kurumun normal çalışma saatlerinde;

ortalama trafik: 800 Mbps

peak trafik: 2 Gbps

ortalama PPS: 200.000

peak PPS: 600.000

normal RPS: 1.500

peak RPS: 4.000

olabilir.

Bu değerler bilinmeden doğru threshold belirlemek zordur.

Peak Traffic Neden Ayrı Değerlendirilmelidir?

Normal ortalama trafik çoğu zaman yeterli değildir.

Örneğin e-ticaret firmasında;

Black Friday,

kampanya,

ürün lansmanı

dönemlerinde trafik normalin birkaç katına çıkabilir.

Bu gerçek kullanıcı yoğunluğudur.

DDoS koruması yanlış eşik nedeniyle bu trafiği saldırı olarak algılarsa sistem kendi müşterilerini engelleyebilir.

Bu nedenle baseline oluştururken;

normal,

peak,

seasonal

trafik ayrı ayrı incelenmelidir.

Threshold Nedir?

Threshold – Eşik Değer, belirli bir metriğin hangi seviyeye ulaştığında güvenlik veya performans aksiyonunun tetikleneceğini ifade eder.

Örneğin;

SYN rate > 100.000/s

HTTP request > 20.000 RPS

CPU > %85

Latency > 1.500 ms

gibi değerler kullanılabilir.

Ancak statik threshold'lar her ortam için uygun olmayabilir.

En iyi threshold kurumun kendi trafik davranışına göre belirlenmelidir.

Static Threshold ile Dynamic Threshold Arasındaki Fark

Static Threshold

Önceden belirlenmiş sabit değerdir.

Örneğin:

10.000 RPS üzeri alarm.

Dynamic Threshold

Normal trafik davranışına göre değişen eşiktir.

Örneğin:

son 30 günlük ortalamadan %300 sapma.

Dynamic threshold özellikle değişken trafikli sistemlerde daha anlamlı olabilir.

Adaptive Threshold Nedir?

Adaptive Threshold, sistemin trafik davranışını sürekli öğrenerek eşikleri dinamik biçimde değiştirmesidir.

Örneğin sistem hafta içi öğle saatlerinde yüksek trafik bekliyor olabilir.

Gece aynı trafik görülürse anomali olarak değerlendirebilir.

Bu yaklaşım DDoS detection açısından false positive oranını azaltabilir.

Bottleneck Analysis Nedir?

Bottleneck Analysis – Darboğaz Analizi, saldırı altında ilk kapasite sınırına ulaşan bileşeni belirleme sürecidir.

DDoS dayanıklılık testinin en değerli çıktılarından biridir.

Çünkü sorun her zaman beklendiği yerde olmayabilir.

Örneğin kurum firewall'un sınırda olduğunu düşünüyor olabilir.

Ama gerçek testte;

load balancer,

DNS,

database,

authentication service

daha önce darboğaza girebilir.

DDoS Zincirinde Nerelerde Darboğaz Oluşabilir?

Genel trafik yolu şu şekilde düşünülebilir:

Internet

↓

ISP

↓

Anti-DDoS / Scrubbing

↓

Router

↓

Firewall

↓

WAF

↓

Load Balancer

↓

Application

↓

Database

Bu zincirin herhangi bir bileşeni darboğaz olabilir.

Bu nedenle kapasite analizi uçtan uca yapılmalıdır.

Internet Hattı Darboğazı Nasıl Anlaşılır?

İnternet hattı saldırı trafiğiyle doygunluğa ulaştığında;

packet loss artabilir,

latency yükselebilir,

gerçek kullanıcı trafiği düşebilir,

servis kesintisi oluşabilir.

Bu durumda içerideki firewall'un hâlâ düşük CPU seviyesinde olması mümkündür.

Çünkü trafik zaten kurumun hattına ulaşamıyordur.

Bu nedenle yüksek hacimli saldırılarda upstream visibility önemlidir.

Firewall Darboğazı Nasıl Anlaşılır?

Firewall üzerindeki;

CPU,

memory,

session table,

PPS,

CPS,

NAT table

değerleri izlenmelidir.

Örneğin internet hattı %40 doluyken firewall CPU %100'e ulaşabilir.

Bu durumda gerçek sınır bandwidth değil firewall kapasitesidir.

Bu nedenle DDoS test raporunda yalnızca trafik grafiği sunmak yeterli değildir.

Load Balancer Darboğazı

Load balancer;

connection,

SSL termination,

health check,

traffic distribution

işlemlerini gerçekleştirir.

DDoS sırasında;

CPS,

concurrent connections,

TLS handshake rate

yükselebilir.

Backend sistemleri yeterli kapasitede olsa bile load balancer sınırına ulaşabilir.

Bu nedenle load balancer telemetry test sırasında ayrıca izlenmelidir.

TLS Handshake DDoS Riski

HTTPS bağlantısı kurulurken TLS handshake belirli miktarda CPU işlemi gerektirir.

Çok sayıda yeni TLS bağlantısı oluşturulması;

load balancer,

reverse proxy,

WAF

üzerinde ek işlem yükü oluşturabilir.

Bu nedenle DDoS kapasite testlerinde sadece HTTP request değil, TLS connection rate de önemli olabilir.

WAF Darboğazı Oluşturabilir mi?

Evet.

WAF trafiği analiz ederken;

signature,

behavioral rule,

bot analysis,

rate limiting

gibi işlemler gerçekleştirir.

Yoğun Layer 7 saldırılarında WAF'ın kendi işlem kapasitesi sınır olabilir.

Ayrıca yanlış rule veya kompleks regex işlemleri performansı etkileyebilir.

Bu nedenle WAF güvenlik kontrolü olduğu kadar kapasite açısından da değerlendirilmelidir.

Application Server Darboğazı

Application server üzerinde;

CPU,

memory,

thread pool,

worker pool,

queue length

kritik metriklerdir.

DDoS saldırısı sırasında response time yükselmeden önce bu değerlerde bozulma görülebilir.

Bu nedenle application monitoring DDoS testinin ayrılmaz parçasıdır.

Database Darboğazı Neden Sık Görülür?

Layer 7 saldırılarda database sık sık gerçek darboğazdır.

Çünkü her kullanıcı isteği arka planda SQL sorgusu oluşturabilir.

Örneğin;

search,

report,

login,

filter

işlemleri database'i yoğun kullanabilir.

Bu nedenle DDoS testinde;

query time,

CPU,

IO,

connection pool,

lock

gibi database metrikleri izlenmelidir.

Connection Pool Darboğazı

Application ile database arasında sınırlı sayıda bağlantı bulunabilir.

Bu bağlantılar tamamen kullanıldığında yeni kullanıcı istekleri sırada bekleyebilir.

Sistem CPU açısından düşük kullanım gösterse bile application erişilemez hale gelebilir.

Bu nedenle sadece CPU izlemek yetersizdir.

Cache Darboğazı Olabilir mi?

Cache genellikle performansı artırır.

Ancak;

cache miss,

cache stampede,

cache eviction

gibi durumlar saldırı sırasında backend yükünü artırabilir.

Örneğin saldırgan sürekli farklı URL'ler isteyerek cache bypass oluşturabilir.

Bu durumda origin trafiği hızla artabilir.

Cache Hit Ratio Neden İzlenmelidir?

Cache Hit Ratio, isteklerin ne kadarının cache üzerinden cevaplandığını gösterir.

Normalde %90 cache hit olan sistem saldırı sırasında %20'ye düşüyorsa origin üzerindeki yük ciddi şekilde artabilir.

Bu davranış Layer 7 DDoS açısından önemli bir göstergedir.

Autoscaling Darboğazı Çözer mi?

Autoscaling belirli kaynaklar için çözüm olabilir.

Örneğin application instance sayısı trafik arttıkça büyüyebilir.

Ancak her bileşen otomatik scale olmayabilir.

Database,

legacy application,

third-party API

sınır oluşturabilir.

Dolayısıyla sistemin bir katmanını scale etmek tüm zinciri çözmeyebilir.

Horizontal Scaling ve Vertical Scaling Farkı

Vertical Scaling

Tek bir sunucuya daha fazla CPU veya RAM eklemektir.

Horizontal Scaling

Yeni sunucu veya instance eklemektir.

DDoS dayanıklılığında horizontal scaling genellikle daha esnek olabilir.

Ancak load balancer ve backend mimarisinin buna uygun olması gerekir.

SLA DDoS Testinde Neden Önemlidir?

Sistem tamamen kapanmadan önce de hizmet kalitesi bozulabilir.

Örneğin SLA şöyle olabilir:

Response time < 1 saniye

Availability > %99,9

DDoS testi sırasında sistem cevap vermeye devam ediyor olabilir.

Ancak response time 8 saniyeye çıkmışsa SLA ihlal edilmiştir.

Bu nedenle başarı kriteri sadece:

“Site açılıyor mu?”

olmamalıdır.

SLO ve SLI Kavramları

Service Level Indicator – SLI, ölçülen performans metriğidir.

Örneğin response time.

Service Level Objective – SLO, hedeflenen performans seviyesidir.

Örneğin:

%99 kullanıcı isteği 1 saniyenin altında cevaplanmalı.

DDoS resilience testleri SLI ve SLO ile birlikte değerlendirildiğinde iş açısından daha anlamlı hale gelir.

DDoS Testinde Stop Condition Nasıl Belirlenir?

Stop Condition, kontrollü testin güvenlik sınırıdır.

Örneğin;

packet loss > %5

response time > 3 saniye

CPU > %90

error rate > %10

olduğunda trafik artırımı durdurulabilir.

Bu değerler her kurumun kendi iş kritikliği ve risk toleransına göre belirlenmelidir.

Soft Limit ve Hard Limit Nedir?

Test sırasında iki farklı sınır kullanılabilir.

Soft Limit

Sistem uyarı seviyesine yaklaşmıştır.

Trafik artırımı durdurulur.

Hard Limit

Kritik sistem riski oluşmuştur.

Test tamamen sonlandırılır.

Bu yaklaşım production ortamında güvenliği artırır.

Graceful Degradation Nedir?

İdeal bir sistem saldırı altında tamamen çökmeden bazı özellikleri sınırlandırabilir.

Bu yaklaşıma Graceful Degradation denir.

Örneğin;

raporlama servisi kapatılır,

arama fonksiyonu sınırlandırılır,

statik içerik sunulmaya devam edilir,

kritik ödeme işlemleri korunur.

Bu yöntem kritik iş fonksiyonlarının availability seviyesini koruyabilir.

Load Shedding Nedir?

Load Shedding, sistem aşırı yük altındayken bazı düşük öncelikli request'lerin reddedilerek kritik servislerin korunmasıdır.

Örneğin;

anonim search request'leri sınırlandırılabilir,

yüksek maliyetli rapor işlemleri geçici devre dışı bırakılabilir,

kritik authenticated işlemler korunabilir.

Bu yaklaşım Layer 7 DDoS dayanıklılığında son derece değerlidir.

Priority-Based Traffic Management

Bütün trafik aynı iş değerine sahip değildir.

Örneğin banka açısından;

para transferi

ile

kampanya banner'ı

aynı önemde değildir.

Bu nedenle uygulama mimarisi kritik işlemlere daha yüksek öncelik verebilir.

DDoS sırasında bu yaklaşım iş sürekliliğini korumaya yardımcı olur.

Failover DDoS Testinde Nasıl Ölçülür?

Kurumun ikinci data center veya cloud region'ı bulunabilir.

Ancak failover'ın teorik olarak var olması yeterli değildir.

DDoS testi sırasında;

traffic switch,

DNS failover,

secondary region,

backup connectivity

gibi mekanizmalar doğrulanabilir.

Buradaki temel soru:

Birinci ortam kullanılamaz hale geldiğinde ikinci ortam gerçekten devreye giriyor mu?

Active-Active Mimari

Active-Active, birden fazla sistem veya lokasyonun aynı anda aktif çalıştığı mimaridir.

DDoS açısından trafik farklı bölgelere dağıtılabilir.

Bu yapı availability seviyesini artırabilir.

Ancak global load balancing ve data consistency doğru tasarlanmalıdır.

Active-Passive Mimari

Active-Passive modelde ana sistem aktif çalışırken yedek sistem standby durumda olabilir.

Ana sistemde problem oluştuğunda failover gerçekleştirilir.

Buradaki kritik metrik:

Failover Time

süresidir.

DDoS saldırısı sırasında bu sürenin ölçülmesi önemlidir.

RTO DDoS İçin Neden Önemlidir?

Recovery Time Objective – RTO, bir hizmet kesintisinden sonra sistemin ne kadar sürede geri dönmesi gerektiğini ifade eder.

DDoS saldırısı tamamen önlenemese bile servis kısa sürede restore edilebiliyorsa iş etkisi azalabilir.

Bu nedenle DDoS resilience yalnızca prevention değil, recovery kapasitesini de içerir.

RPO DDoS Açısından Önemli midir?

Recovery Point Objective – RPO daha çok veri kaybı toleransını ifade eder.

DDoS saldırısı genellikle veri kaybı oluşturmaz.

Ancak saldırı sırasında diğer sistemler veya operasyonlar etkileniyorsa business continuity planları içerisinde RPO yine değerlendirilebilir.

Time to Detect Nedir?

Time to Detect – TTD, saldırının başlaması ile güvenlik ekibinin bunu tespit etmesi arasındaki süredir.

Örneğin:

00:00 saldırı başladı.

00:45 Anti-DDoS alarm verdi.

01:20 SOC olayı doğruladı.

Burada farklı detection süreleri ölçülebilir.

TTD ne kadar düşükse saldırıya müdahale o kadar hızlı başlayabilir.

Time to Mitigate Nedir?

Time to Mitigate – TTM, saldırının başlamasından etkili mitigation'ın devreye girmesine kadar geçen süredir.

DDoS dayanıklılığının en kritik metriklerinden biridir.

Çünkü sistem saldırıya dayanabiliyor olsa bile mitigation çok geç başlıyorsa kullanıcı deneyimi uzun süre bozulabilir.

Time to Recover Nedir?

Time to Recover, saldırı sona erdikten veya mitigation tamamlandıktan sonra sistemin normal performansa dönme süresidir.

Bazı sistemlerde saldırı bittikten sonra;

connection backlog,

cache problemi,

database yükü,

autoscaling cleanup

nedeniyle performans hemen normale dönmeyebilir.

Bu nedenle recovery süresi ayrıca ölçülmelidir.

DDoS Resilience Score Nasıl Oluşturulabilir?

Kurum kendi DDoS olgunluk skorunu oluşturabilir.

Örneğin şu alanlar puanlanabilir:

Network Capacity

Detection

Mitigation

Application Resilience

DNS Resilience

SOC Response

Incident Response

Business Continuity

Böylece yıllar içerisindeki gelişim ölçülebilir.

Ama skorun tek başına pazarlama metriğine dönüşmemesi gerekir.

Altındaki gerçek teknik ölçümler korunmalıdır.

DDoS Dayanıklılığı için Teknik KPI'lar

Örnek KPI'lar şunlar olabilir:

Maximum Sustainable Gbps

Maximum Sustainable PPS

Maximum CPS

Maximum Layer 7 RPS

Maximum DNS QPS

Detection Time

Mitigation Time

Recovery Time

Legitimate Traffic Success Rate

False Positive Rate

Bu metrikler kurumsal DDoS kapasitesini ölçülebilir hale getirir.

Legitimate Traffic Success Rate Nedir?

DDoS mitigation sırasında asıl amaç sadece saldırıyı durdurmak değildir.

Gerçek kullanıcıların hizmet almaya devam etmesi gerekir.

Örneğin saldırı sırasında:

%99 saldırı trafiği engellendi.

Ancak %30 gerçek kullanıcı da engellendi.

Bu başarılı bir mitigation değildir.

Bu nedenle Legitimate Traffic Success Rate kritik bir ölçümdür.

False Positive Rate DDoS Testinde Nasıl Ölçülür?

Test sırasında gerçek kullanıcı trafiği veya simüle edilmiş legitimate traffic de gönderilebilir.

Ardından;

kaç gerçek request'in engellendiği,

kaç oturumun challenge aldığı,

kaç kullanıcının timeout yaşadığı

ölçülür.

Bu sayede Anti-DDoS veya WAF politikasının fazla agresif olup olmadığı anlaşılabilir.

DDoS Testi Sırasında Real User Monitoring

Real User Monitoring – RUM, gerçek kullanıcıların web uygulamasında yaşadığı deneyimi ölçer.

Örneğin;

page load time,

transaction time,

JavaScript error,

session failure

gibi metrikler toplanabilir.

DDoS testi sırasında RUM verileri son derece değerlidir.

Çünkü altyapı metrikleri iyi görünürken gerçek kullanıcı kötü deneyim yaşayabilir.

Synthetic Monitoring Nedir?

Synthetic Monitoring, gerçek kullanıcı yerine otomatik test kullanıcılarının kritik işlemleri sürekli gerçekleştirmesidir.

Örneğin her 30 saniyede;

ana sayfa açılır,

login yapılır,

ürün aranır,

checkout kontrol edilir.

DDoS testi sırasında bu synthetic işlemlerin başarısı izlenebilir.

Bu sayede gerçek kullanıcı deneyimi güvenli şekilde ölçülebilir.

DDoS Testinde Senaryo Bazlı Yaklaşım

Tek bir trafik testi yerine farklı senaryolar uygulanmalıdır.

Örneğin:

Senaryo 1 – Volumetric

Bandwidth kapasitesi ölçülür.

Senaryo 2 – High PPS

Network cihazlarının packet processing limiti ölçülür.

Senaryo 3 – SYN Flood

Connection management test edilir.

Senaryo 4 – HTTP Flood

Web application dayanıklılığı ölçülür.

Senaryo 5 – API DDoS

Backend ve API Gateway değerlendirilir.

Senaryo 6 – DNS Flood

DNS resilience ölçülür.

Bu yaklaşım DDoS testinin kapsamını güçlendirir.

Multi-Vector DDoS Testi Neden Önemlidir?

Gerçek saldırgan aynı anda farklı teknikler kullanabilir.

Örneğin;

UDP Flood

SYN Flood

HTTP Flood

aynı anda uygulanabilir.

Bu durumda güvenlik ekiplerinin farklı alarmlarla aynı anda uğraşması gerekir.

Multi-Vector testler teknik dayanıklılığın yanında SOC ve Incident Response kapasitesini de ölçer.

DDoS Testinde Change Management

Production ortamında test yapılıyorsa değişiklik yönetimi süreci önemlidir.

Test öncesinde;

CAB,

Network,

SOC,

Application,

Business

ekipleri bilgilendirilebilir.

Test sırasında yapılacak konfigürasyon değişiklikleri kayıt altına alınmalıdır.

Aksi halde test sonrası ortaya çıkan davranışların nedeni net olarak belirlenemeyebilir.

DDoS Testi Öncesi Checklist

Profesyonel test öncesinde en azından şu konular doğrulanmalıdır:

• Scope belli mi?
• Yetkilendirme tamam mı?
• ISP haberdar mı?
• CDN veya cloud provider kuralları kontrol edildi mi?
• Baseline alındı mı?
• Stop Condition tanımlı mı?
• Kill Switch hazır mı?
• SOC iletişim noktası belli mi?
• Uygulama ekibi hazır mı?
• Test sırasında monitoring aktif mi?
• Business owner bilgilendirildi mi?

Bu hazırlık test riskini önemli ölçüde azaltır.

DDoS Dayanıklılık Raporu Nasıl Olmalıdır?

Profesyonel raporda sadece “başarılı/başarısız” sonucu verilmemelidir.

Rapor şu bölümleri içerebilir:

Executive Summary

Yönetim için genel sonuç.

Architecture Overview

Test edilen mimari.

Baseline

Normal sistem davranışı.

Attack Profiles

Uygulanan senaryolar.

Capacity Results

Gbps, PPS, CPS, RPS ve QPS sonuçları.

Threshold Analysis

Kritik eşikler.

Bottleneck Analysis

İlk kapasite sınırına ulaşan bileşenler.

Detection Timeline

SOC ve güvenlik kontrollerinin tespit süreleri.

Mitigation Timeline

Savunmanın devreye girme süresi.

Business Impact

Kullanıcı ve servis etkisi.

Remediation Roadmap

İyileştirme adımları.

Yönetim İçin DDoS Raporu Nasıl Anlatılmalıdır?

Üst yönetime şu şekilde bir sonuç daha anlamlıdır:

“Web platformu 12 Gbps volumetric saldırıda erişilebilirliğini korudu. Ancak 2,8 milyon PPS seviyesinde firewall packet processing kapasitesi kritik seviyeye ulaştı. Layer 7 senaryosunda login servisi 6.500 RPS üzerinde SLA dışına çıktı. Anti-DDoS mitigation süresi 48 saniye, SOC doğrulama süresi ise 3 dakika 20 saniye olarak ölçüldü.”

Bu çıktı;

yatırım,

kapasite,

risk

kararlarını kolaylaştırır.

DDoS Kapasitesi Ne Kadar Olmalı?

Bunun tek bir cevabı yoktur.

Gerekli kapasite;

kurumun normal trafiğine,

sektörüne,

tehdit profiline,

business impact seviyesine,

cloud veya data center mimarisine

bağlıdır.

Önemli olan rakip şirketin kapasitesi değil, kurumun kendi risk profilidir.

Bu nedenle DDoS capacity planning risk bazlı yapılmalıdır.

Threat Intelligence DDoS Kapasite Planlamasında Kullanılabilir mi?

Evet.

Cyber Threat Intelligence sayesinde;

sektörde görülen saldırı büyüklükleri,

kullanılan DDoS vektörleri,

botnet trendleri,

hedeflenen servis türleri

takip edilebilir.

Bu bilgiler test senaryolarını daha gerçekçi hale getirebilir.

Örneğin kurumun sektöründe Layer 7 API saldırıları artıyorsa sadece volumetric kapasiteye yatırım yapmak yeterli olmayabilir.

Sürekli DDoS Validation Neden Önemlidir?

DDoS dayanıklılığı sabit değildir.

Altyapı değişir.

Yeni uygulama açılır.

Firewall değişir.

CDN politikası güncellenir.

API sayısı artar.

Cloud mimarisi değişir.

Bu nedenle bir yıl önceki DDoS testinin sonucu bugün geçerli olmayabilir.

Kritik sistemlerde periyodik DDoS Security Validation gerçekleştirmek faydalıdır.

Sonuç: DDoS Dayanıklılığı Tek Bir Rakam Değildir

Bir kurumun DDoS kapasitesini tek bir:

“100 Gbps korumamız var.”

cümlesiyle anlatmak çoğu zaman yanıltıcıdır.

Gerçek dayanıklılık çok boyutludur.

Gbps

bant genişliği kapasitesini,

PPS

paket işleme kapasitesini,

CPS

bağlantı oluşturma kapasitesini,

RPS

uygulama kapasitesini,

QPS

DNS kapasitesini

gösterir.

Ancak bunlara ek olarak;

Detection Time,

Mitigation Time,

Recovery Time,

False Positive Rate,

Legitimate Traffic Success Rate

gibi operasyonel metrikler de önemlidir.

En önemli soru ise şudur:

Saldırı sırasında ilk olarak hangi bileşen tükeniyor?

Çünkü DDoS savunması her zaman en zayıf darboğaz kadar güçlüdür.

İnternet hattı.

Firewall.

WAF.

Load balancer.

Application.

Database.

DNS.

Bu bileşenlerden herhangi biri kritik eşikte hizmet veremez hale gelirse kullanıcı açısından sistem erişilemezdir.

Bu nedenle profesyonel DDoS dayanıklılık testi yalnızca saldırı trafiğini üretmez.

Sistemin kırılma noktasını kontrollü biçimde bulur.

Ardından bu kırılma noktasını güçlendirmek için teknik ve operasyonel iyileştirmeler önerir.

Fakat kapasiteyi bilmek tek başına yeterli değildir.

Saldırı başladığında trafiğin nasıl temizleneceği, hangi katmanda durdurulacağı ve gerçek kullanıcıların nasıl korunacağı da doğru tasarlanmalıdır.

Bu noktada DDoS güvenliğinin en önemli savunma bileşenleri devreye girer:

Firewall, WAF, CDN, Anti-DDoS ve Scrubbing Center.