# DDoS Saldırı Simülasyonu Nedir? Kurumsal Sistemler Nasıl Test Edilir?

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/ddos-simulasyonu/ddos-saldiri-simulasyonu-nedir

![DDoS Saldırı Simülasyonu Nedir? Kurumsal Sistemler Nasıl Test Edilir?](/images/bilgi-merkezi/covers/cover-ddos-03.webp)

Bir kurumun Anti-DDoS hizmetine sahip olması, WAF kullanması, CDN üzerinden yayın yapması ve firewall üzerinde DoS korumalarının aktif olması önemli güvenlik katmanlarıdır.

Ancak bunların gerçekten çalışıp çalışmadığı çoğu zaman ancak gerçek trafik altında anlaşılır.

Çünkü kağıt üzerinde doğru görünen bir mimari, yük altında farklı davranabilir.

Bir firewall beklenen connection sayısına ulaşmadan kaynak tüketebilir.

Bir WAF Layer 7 saldırısını geç fark edebilir.

Bir CDN origin sunucuyu yeterince koruyamayabilir.

Bir Anti-DDoS hizmeti doğru eşikte devreye girmeyebilir.

SOC saldırıyı geç fark edebilir.

Uygulama ise network tamamen ayakta olmasına rağmen backend darboğazı nedeniyle kullanılamaz hale gelebilir.

Bu nedenle modern kurumsal siber güvenlikte sadece DDoS koruma ürünü satın almak yeterli değildir.

**DDoS dayanıklılığı test edilmelidir.**

Bu çalışma genel olarak **DDoS Saldırı Simülasyonu**, **DDoS Dayanıklılık Testi**, **DDoS Resilience Test** veya **DDoS Security Validation** olarak adlandırılabilir.

DDoS saldırı simülasyonu; kurumun internet servislerinin, network altyapısının, WAF, CDN, Anti-DDoS, firewall, DNS, uygulama ve SOC süreçlerinin kontrollü trafik senaryoları altında ne kadar dayanıklı olduğunu ölçmeyi amaçlayan yetkilendirilmiş güvenlik testidir.

Amaç gerçek saldırı oluşturmak değildir.

Amaç gerçek saldırı gerçekleşmeden önce kurumun savunma zincirinin ne kadar dayanıklı olduğunu güvenli şekilde ölçmektir.

#### DDoS Saldırı Simülasyonu Nedir?

**DDoS Saldırı Simülasyonu**, kontrollü ve yetkilendirilmiş trafik üretilerek bir kurumun Distributed Denial of Service saldırılarına karşı teknik ve operasyonel dayanıklılığının ölçülmesidir.

Bu test sırasında;

- internet bağlantısı,
- firewall,
- router,
- load balancer,
- CDN,
- WAF,
- Anti-DDoS,
- Scrubbing Center,
- DNS altyapısı,
- web uygulamaları,
- API servisleri,
- SOC,
- SIEM,
- Incident Response

birlikte değerlendirilebilir.

Buradaki en önemli nokta şudur:

**DDoS testi yalnızca trafik testi değildir.**

Gerçek bir DDoS dayanıklılık değerlendirmesi aynı zamanda bir **Security Control Validation** çalışmasıdır.

### DDoS Testinin Amacı Nedir?

Profesyonel DDoS testinin amacı sistemi çökertmek değildir.

Amaç sistemin sınırlarını anlamaktır.

Örneğin şu soruların cevapları aranabilir:

#### Kurum kaç Gbps saldırı trafiğini karşılayabiliyor?

#### PPS seviyesi ne kadar yükseldiğinde firewall etkileniyor?

#### CPS arttığında load balancer nasıl davranıyor?

#### WAF Layer 7 saldırıyı ne kadar sürede tespit ediyor?

#### Anti-DDoS otomatik olarak devreye giriyor mu?

#### Scrubbing Center'a trafik ne kadar sürede yönleniyor?

#### SOC alarmı kaç dakikada görüyor?

#### Gerçek kullanıcı deneyimi hangi noktada etkileniyor?

#### Saldırı sona erdiğinde sistem ne kadar sürede normale dönüyor?

Bu soruların cevapları kurumun gerçek DDoS readiness seviyesini gösterir.

### DDoS Testi ile Gerçek DDoS Saldırısı Arasındaki Fark

Gerçek DDoS saldırısında saldırganın amacı hizmeti kesmektir.

Kontrollü DDoS testinde ise amaç hizmeti koruyarak dayanıklılık seviyesini ölçmektir.

Bu nedenle test sırasında;

trafik miktarı,

paket oranı,

test süresi,

hedef sistemler,

kullanılan protokoller,

durdurma koşulları

önceden belirlenmelidir.

Profesyonel testte saldırı trafiği kontrollü ve kademeli artırılır.

Sistem kritik eşiklere yaklaştığında test durdurulabilir.

Bu nedenle **Stop Condition – Durdurma Koşulları** DDoS testlerinin en önemli bileşenlerinden biridir.

### DDoS Testi Production Ortamında Yapılır mı?

Evet, yapılabilir.

Ancak çok kontrollü gerçekleştirilmelidir.

DDoS testinin en değerli sonuçları çoğu zaman gerçek production mimarisinde elde edilir.

Çünkü test ortamında;

gerçek firewall,

gerçek WAF,

gerçek CDN,

gerçek routing,

gerçek uygulama yükü

tam olarak temsil edilmeyebilir.

Ancak production testinin riskleri de daha yüksektir.

Bu nedenle test başlamadan önce açık bir **Rules of Engagement – RoE** oluşturulmalıdır.

### Rules of Engagement DDoS Testinde Neden Kritiktir?

RoE, DDoS testinin hangi sınırlar içerisinde gerçekleştirileceğini tanımlar.

Örneğin;

hangi IP'ler test edilecek,

hangi domain'ler kapsamda,

hangi protokoller kullanılacak,

maksimum trafik seviyesi ne olacak,

test kaç dakika sürecek,

hangi saatlerde yapılacak,

hangi durumlarda durdurulacak

önceden belirlenmelidir.

Ayrıca ISP, CDN ve Anti-DDoS sağlayıcılarıyla gerekli koordinasyon yapılmalıdır.

Yanlış planlanan test, meşru üçüncü taraf sistemlerini etkileyebilir.

### DDoS Test Scope Nasıl Belirlenir?

DDoS testinin kapsamı kurumun kritik servislerine göre belirlenmelidir.

Örneğin kapsam içerisinde;

#### Public Web Site

kurumsal web sitesi.

#### E-Commerce Platform

online satış sistemi.

#### API Gateway

mobil uygulama veya partner servisleri.

#### DNS Infrastructure

authoritative DNS servisleri.

#### VPN Gateway

uzaktan erişim altyapısı.

#### Authentication Service

login ve identity servisleri.

#### Public IP Blocks

internet-facing network varlıkları

bulunabilir.

Ancak bütün sistemlerin aynı anda test edilmesi gerekmez.

Risk ve iş kritikliği üzerinden önceliklendirme yapılabilir.

### Critical Asset Belirleme

DDoS testi başlamadan önce kurumun hangi internet servislerinin iş açısından kritik olduğu belirlenmelidir.

Örneğin bir bankada;

mobil bankacılık,

internet bankacılığı,

ödeme API'leri

kritik olabilir.

E-ticaret şirketinde;

web sitesi,

ödeme servisi,

login API

öncelikli olabilir.

SaaS şirketinde;

müşteri portalı,

API,

authentication service

kritik olabilir.

Bu yaklaşım testin iş riskiyle doğrudan ilişkilendirilmesini sağlar.

### Baseline Nedir?

DDoS testi öncesinde normal trafik davranışı ölçülmelidir.

Bu ölçüme **Traffic Baseline** denir.

Örneğin normal durumda;

bandwidth,

PPS,

CPS,

RPS,

latency,

CPU,

memory,

active connection,

HTTP error rate

değerleri kaydedilir.

Bu baseline olmadan saldırı sırasında oluşan değişikliklerin doğru yorumlanması zorlaşır.

Örneğin test sırasında latency 50 ms'den 200 ms'ye çıkmışsa bu anlamlı olabilir.

Ama sistem normalde 180 ms çalışıyorsa aynı sonuç farklı yorumlanmalıdır.

### DDoS Testinde Hangi Metrikler İzlenir?

Profesyonel testte sadece trafik miktarı izlenmez.

En önemli metrikler arasında şunlar bulunur:

#### Bandwidth

Mbps / Gbps seviyesi.

#### Packets Per Second – PPS

Saniyedeki paket sayısı.

#### Connections Per Second – CPS

Yeni bağlantı oranı.

#### Requests Per Second – RPS

HTTP veya API istek sayısı.

#### Concurrent Connections

Aynı anda açık bağlantı sayısı.

#### Latency

Yanıt gecikmesi.

#### Packet Loss

Kaybolan paket oranı.

#### CPU / Memory

Sistem kaynak kullanımı.

#### HTTP Error Rate

4xx ve 5xx oranları.

#### Application Response Time

Uygulama yanıt süresi.

#### Mitigation Time

Anti-DDoS'ın devreye girme süresi.

### DDoS Test Trafiği Nasıl Artırılmalıdır?

Profesyonel testlerde trafik genellikle kademeli artırılır.

Örneğin;

%10 kapasite,

%25 kapasite,

%50 kapasite,

%75 kapasite,

%100 hedef eşik

gibi aşamalar kullanılabilir.

Ama sabit yüzdeler her kurum için uygun değildir.

Asıl önemli olan kontrollü ramp-up modelidir.

Bu yaklaşım sayesinde güvenlik ekipleri;

hangi seviyede alarm oluştuğunu,

hangi seviyede performans düştüğünü,

hangi seviyede mitigation başladığını

görebilir.

### Ramp-Up Test Nedir?

**Ramp-Up**, test trafiğinin bir anda değil kademeli olarak artırılmasıdır.

Bu yöntem özellikle production sistemlerinde önemlidir.

Örneğin test 100 Mbps ile başlayabilir.

Daha sonra kontrollü şekilde 500 Mbps, 1 Gbps gibi seviyelere çıkılabilir.

Her aşamada sistem davranışı izlenir.

Eğer kritik eşik görülürse trafik artırılmaz.

Bu yöntem gerçek kesinti riskini azaltır.

### Burst Test Nedir?

**Burst Test**, kısa süreli ani trafik artışlarının sistem üzerindeki etkisini ölçer.

Gerçek DDoS saldırıları her zaman yavaş artmayabilir.

Bazı saldırılar saniyeler içinde çok yüksek trafik oluşturabilir.

Bu nedenle kurumun;

autoscaling,

rate limiting,

Anti-DDoS detection,

firewall

gibi bileşenlerinin ani yük değişimine tepkisi test edilebilir.

Ancak burst testleri özellikle dikkatli planlanmalıdır.

### Sustained Load Test Nedir?

Bazı DDoS saldırıları kısa süreli değil uzun süreli olabilir.

Bu nedenle sistem yalnızca peak trafiğe değil, uzun süreli saldırıya da dayanıklı olmalıdır.

**Sustained Load Test**, belirli trafik seviyesinin daha uzun süre korunarak sistemin davranışının gözlemlenmesidir.

Amaç;

memory leak,

connection accumulation,

backend exhaustion,

autoscaling davranışı

gibi uzun süreli etkileri görmek olabilir.

### Volumetric DDoS Testi Nasıl Değerlendirilir?

Volumetric testlerde temel amaç network kapasitesini ve upstream korumayı değerlendirmektir.

Örneğin;

UDP traffic,

ICMP traffic,

yüksek bandwidth

kontrollü şekilde uygulanabilir.

Test sırasında;

ISP,

router,

Anti-DDoS,

firewall

davranışları izlenir.

En önemli soru şudur:

#### Saldırı trafiği kurumun internet hattını doldurmadan önce filtrelenebiliyor mu?

### L3/L4 DDoS Testi Nedir?

Layer 3 ve Layer 4 testlerinde network ve transport layer davranışları değerlendirilir.

Örneğin;

SYN Flood,

UDP Flood,

connection flood

gibi senaryolar kontrollü olarak uygulanabilir.

Amaç;

firewall,

load balancer,

network stack,

connection table

gibi bileşenlerin limitlerini ölçmektir.

Bu testlerde PPS ve CPS metrikleri özellikle önemlidir.

### Layer 7 DDoS Testi Nedir?

**Layer 7 DDoS Testi**, web uygulamalarının veya API'lerin Application Layer saldırılarına karşı dayanıklılığını ölçer.

Örneğin;

HTTP GET flood,

HTTP POST flood,

login yoğunluğu,

API request flood

gibi kontrollü senaryolar kullanılabilir.

Burada asıl amaç bandwidth tüketmek değil, uygulamanın kaynak tüketimini ölçmektir.

### Layer 7 Testinde Endpoint Seçimi Neden Önemlidir?

Her endpoint aynı miktarda kaynak tüketmez.

Örneğin;

/static/logo.png

çok az kaynak tüketebilir.

Ancak;

/login

/search

/report

/api/query

backend üzerinde çok daha fazla işlem yaratabilir.

Bu nedenle Layer 7 testi yapılırken yüksek maliyetli endpoint'ler belirlenmelidir.

Bu yaklaşım **Application Bottleneck Analysis** açısından önemlidir.

### API DDoS Testi Nasıl Yapılır?

API tabanlı servislerde sadece request sayısı değil, backend iş yükü de önemlidir.

Örneğin bir API isteği;

database query,

authentication,

external API çağrısı,

microservice chain

tetikleyebilir.

Bu nedenle API DDoS testi sırasında;

RPS,

response time,

backend CPU,

database load,

error rate

birlikte izlenmelidir.

### DNS DDoS Testi Nedir?

DNS altyapısı kurumun internet erişilebilirliği açısından kritik öneme sahiptir.

Bu nedenle DDoS dayanıklılık testlerinde DNS ayrıca değerlendirilmelidir.

Test sırasında;

DNS QPS,

authoritative server response,

latency,

DNS failover,

Anycast davranışı

izlenebilir.

DNS servisi çalışmadığında web sunucusu ayakta olsa bile kullanıcılar servise ulaşamayabilir.

### CDN DDoS Testinde Ne Ölçülür?

CDN kullanılması DDoS riskini azaltabilir.

Ancak CDN'in gerçekten doğru yapılandırıldığının doğrulanması gerekir.

Test sırasında;

cache hit ratio,

edge response,

origin traffic,

origin protection,

rate limiting

gibi metrikler değerlendirilebilir.

Özellikle origin IP doğrudan erişilebiliyorsa saldırgan CDN'i bypass etmeye çalışabilir.

Bu nedenle **Origin Protection Testi** önemlidir.

### WAF DDoS Testinde Ne Ölçülür?

WAF özellikle Layer 7 saldırılarına karşı kritik bir güvenlik bileşenidir.

Test sırasında;

request filtering,

rate limiting,

bot detection,

HTTP anomaly detection,

challenge mechanism

gibi kontroller değerlendirilebilir.

Amaç sadece WAF'ın alarm üretip üretmediğini görmek değildir.

Asıl soru:

#### Meşru kullanıcıları engellemeden kötü amaçlı trafiği filtreleyebiliyor mu?

### False Positive Neden Önemlidir?

Agresif DDoS koruması gerçek kullanıcıları da engelleyebilir.

Bu durum **False Positive** olarak değerlendirilir.

Örneğin;

mobil operatör NAT'ı,

kurumsal proxy,

ortak IP,

yüksek hacimli gerçek müşteri

yanlışlıkla bot olarak algılanabilir.

Bu nedenle DDoS testinde yalnızca saldırı trafiğinin engellenmesi değil, **legitimate user availability** de ölçülmelidir.

### Anti-DDoS Mitigation Time Nasıl Ölçülür?

En önemli metriklerden biri **Time to Mitigate – TTM** olabilir.

Saldırı başladığında Anti-DDoS çözümünün;

anomaly'yi tespit etmesi,

mitigation başlatması,

trafik temizlemesi

ne kadar sürüyor?

Örneğin;

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

alarm oluştu → 00:20

mitigation başladı → 00:45

trafik normale döndü → 01:10

Bu zaman çizelgesi gerçek saldırı performansını gösterir.

### SOC DDoS Testinde Nasıl Ölçülür?

DDoS simülasyonu sadece network ekiplerinin testi olmamalıdır.

SOC da değerlendirilmelidir.

Örneğin;

alarm geldi mi?

SIEM event oluşturdu mu?

SOC alarmı ne kadar sürede gördü?

olay doğru sınıflandırıldı mı?

network ekibine eskale edildi mi?

Anti-DDoS sağlayıcısıyla iletişim kuruldu mu?

Incident Response süreci başladı mı?

Bu sorular DDoS testini operasyonel tatbikata dönüştürür.

### SIEM DDoS Saldırısını Nasıl Görür?

SIEM farklı kaynaklardan gelen logları ilişkilendirebilir.

Örneğin;

firewall,

WAF,

Anti-DDoS,

CDN,

DNS,

NDR,

application logs

aynı saldırının farklı izlerini gösterebilir.

SIEM'in değeri tek alarm üretmek değil, saldırıyı bir bütün olarak göstermektir.

### NDR DDoS Testinde Ne İşe Yarar?

**Network Detection and Response – NDR**, trafik davranışlarını analiz ederek anomalileri tespit edebilir.

Örneğin;

PPS artışı,

protokol dağılımı,

source diversity,

flow anomaly

gibi sinyaller izlenebilir.

DDoS simülasyonu NDR'ın davranış analizi kabiliyetini doğrulamak için de kullanılabilir.

### DDoS Incident Response Testi Nedir?

Teknik DDoS simülasyonuyla birlikte Incident Response süreci de test edilebilir.

Örneğin olay sırasında;

SOC,

Network,

Application,

Management,

ISP,

DDoS Provider

arasındaki iletişim ölçülebilir.

Bu yaklaşım teknik testten daha geniştir.

Bir **DDoS Tabletop Exercise** ile birlikte de yürütülebilir.

### DDoS Playbook Nedir?

**DDoS Incident Response Playbook**, saldırı başladığında kimlerin ne yapacağını tanımlar.

Örneğin;

SOC alarmı doğrular.

Network ekipleri trafik analizi yapar.

ISP veya Anti-DDoS sağlayıcısı bilgilendirilir.

Application ekibi servis performansını kontrol eder.

Yönetim bilgilendirme sürecini yürütür.

Böylece saldırı anında sorumluluklar belirsiz kalmaz.

### Stop Condition Nasıl Belirlenir?

DDoS testinde en kritik güvenlik mekanizmalarından biri Stop Condition'dır.

Örneğin;

latency 2 saniyenin üzerine çıkarsa,

packet loss %5'i aşarsa,

CPU %90'a ulaşırsa,

gerçek kullanıcı hataları belirli seviyeyi geçerse,

kritik servis alarm üretirse

test durdurulabilir.

Bu değerler test öncesinde kurumla birlikte belirlenmelidir.

### Kill Switch Nedir?

Bazı testlerde **Kill Switch**, test trafiğinin acil durumda anında durdurulmasını sağlayan kontrol mekanizmasıdır.

Örneğin production sisteminde beklenmeyen hata görülürse trafik saniyeler içerisinde kesilebilir.

Bu mekanizma özellikle yüksek kapasiteli testlerde önemlidir.

### DDoS Testinde Third-Party Koordinasyonu

Kurumsal servisler çoğu zaman sadece şirketin kendi altyapısından oluşmaz.

Örneğin;

ISP,

cloud provider,

CDN,

DNS provider,

Anti-DDoS vendor

bulunabilir.

Bu nedenle test öncesinde üçüncü taraflarla koordinasyon yapılmalıdır.

Bazı servis sağlayıcıların test trafiklerine ilişkin özel prosedürleri olabilir.

### Cloud Ortamında DDoS Testi

AWS, Azure veya diğer cloud platformlarında DDoS testleri ayrıca planlanmalıdır.

Cloud sağlayıcıların;

yük testi,

DDoS simulation,

traffic generation

konusunda kendi kullanım politikaları olabilir.

Bu nedenle cloud ortamında test gerçekleştirilmeden önce ilgili platform kuralları dikkate alınmalıdır.

Teknik olarak kapasitenin yüksek olması DDoS riskinin olmadığı anlamına gelmez.

Application Layer ve maliyet tabanlı saldırılar yine önemli olabilir.

### DDoS ve Autoscaling

Cloud ortamlarında **Autoscaling**, yüksek trafik durumunda yeni kaynaklar ekleyebilir.

Bu yaklaşım availability açısından faydalıdır.

Ancak sınırsız scaling başka bir risk oluşturabilir:

**Economic Denial of Sustainability – EDoS.**

Saldırı servisi tamamen çökertmese bile cloud maliyetlerini ciddi şekilde artırabilir.

Bu nedenle DDoS dayanıklılığı yalnızca teknik kapasite değil, maliyet kontrolü açısından da değerlendirilmelidir.

### DDoS Testinde Business Impact Nasıl Ölçülür?

Teknik metrikler tek başına yeterli değildir.

Örneğin sistem tamamen erişilebilir kalmış olabilir.

Ancak response time;

300 ms'den

4 saniyeye

çıkmış olabilir.

E-ticaret kullanıcısı açısından bu ciddi problem olabilir.

Bu nedenle testte;

transaction success,

login success,

checkout completion,

API SLA,

customer experience

gibi iş metrikleri de izlenebilir.

### DDoS Test Raporunda Neler Olmalıdır?

Profesyonel DDoS test raporu yalnızca trafik grafiği olmamalıdır.

En azından şu alanlar bulunabilir:

#### Executive Summary

Yönetim için genel dayanıklılık sonucu.

#### Test Scope

Test edilen sistemler.

#### Traffic Profile

Gbps, PPS, CPS ve RPS değerleri.

#### Attack Scenarios

Uygulanan kontrollü test senaryoları.

#### System Behavior

Firewall, CDN, WAF ve uygulama davranışı.

#### Mitigation Timeline

Saldırının algılanması ve engellenme süresi.

#### SOC Response

Alarm ve müdahale süreçleri.

#### Bottleneck Analysis

Sistemin zayıf noktaları.

#### Business Impact

Kullanıcı ve servis etkisi.

#### Remediation Recommendations

İyileştirme önerileri.

#### Retest Plan

Düzeltmeler sonrası yeniden doğrulama.

### DDoS Testinde Başarı Nasıl Tanımlanmalıdır?

Testin başarılı olması:

**“Sistem hiç yavaşlamadı.”**

demek değildir.

Daha doğru başarı kriterleri şunlar olabilir:

Saldırı doğru tespit edildi.

Mitigation otomatik başladı.

Gerçek kullanıcılar hizmet almaya devam etti.

SOC olayı doğru eskale etti.

Network saturation oluşmadı.

Uygulama SLA içerisinde kaldı.

Failover mekanizması çalıştı.

Bu ölçümler daha anlamlıdır.

### DDoS Testi Ne Sıklıkla Yapılmalıdır?

Tek bir test yeterli değildir.

Çünkü altyapı sürekli değişir.

Yeni firewall alınabilir.

WAF politikaları değişebilir.

CDN sağlayıcısı değişebilir.

Yeni API yayınlanabilir.

Bandwidth yükseltilebilir.

Yeni cloud ortamı devreye alınabilir.

Bu nedenle risk seviyesine göre periyodik DDoS resilience testleri yapılabilir.

Ayrıca büyük altyapı değişikliklerinden sonra yeniden doğrulama yapılması faydalıdır.

### DDoS Testi ile Penetrasyon Testi Arasındaki Fark

Pentest ve DDoS testi farklı güvenlik risklerini ölçer.

#### Pentest

Confidentiality ve Integrity risklerini de yoğun şekilde değerlendirebilir.

#### DDoS Testi

Availability ve resilience üzerinde daha fazla odaklanır.

Pentest:

**“Yetkisiz erişim mümkün mü?”**

DDoS testi:

**“Hizmet erişilebilir kalabiliyor mu?”**

sorusunu sorar.

İki çalışma birbirini tamamlar.

### DDoS Testi ile Load Test Arasındaki Fark

Bu iki çalışma da trafik üretebilir ancak amaçları farklıdır.

#### Load Test

Uygulamanın beklenen kullanıcı yükünü taşıyıp taşıyamadığını ölçer.

#### DDoS Test

Kötü amaçlı veya anormal trafik davranışlarına karşı güvenlik ve dayanıklılığı ölçer.

Load testing normal kullanıcı davranışını simüle eder.

DDoS simulation ise kötüye kullanım pattern'lerini değerlendirebilir.

Bu nedenle aynı şey değildir.

### DDoS Testi ile Stress Test Arasındaki Fark

**Stress Test**, sistemi kapasite sınırlarının üzerine çıkararak hangi noktada bozulduğunu anlamaya çalışabilir.

DDoS testinde ise yalnızca kapasite değil, savunma sistemlerinin saldırı trafiğini ayırt edip engelleyebilmesi de ölçülür.

Bu nedenle DDoS simulation aynı zamanda bir güvenlik testidir.

### DDoS Testinde En Büyük Hata Nedir?

En büyük hatalardan biri testi sadece “yük gönderme” olarak görmektir.

Örneğin:

“10 Gbps trafik gönderdik, sistem çalıştı.”

tek başına yeterli değildir.

Şunlar da bilinmelidir:

Hangi layer test edildi?

PPS neydi?

CPS neydi?

HTTP RPS neydi?

Anti-DDoS ne zaman devreye girdi?

Firewall ne kadar kaynak kullandı?

Gerçek kullanıcılar etkilendi mi?

SOC alarm aldı mı?

Aksi halde test teknik açıdan anlamlı olmayabilir.

### DDoS Dayanıklılık Testi Neden Yönetim İçin Değerlidir?

Yönetim için en önemli soru saldırının teknik detayından çok iş etkisidir.

Örneğin rapor şu şekilde özetlenebilir:

**“Kritik müşteri portalı 8 Gbps volumetric saldırı altında erişilebilir kaldı ancak Layer 7 senaryosunda login endpoint'i 3.500 RPS üzerinde SLA dışına çıktı.”**

Bu çıktı yönetim açısından nettir.

Artık yatırım kararı alınabilir.

Örneğin;

WAF tuning,

backend scaling,

rate limiting,

Anti-DDoS capacity

gibi alanlar önceliklendirilebilir.

### DDoS Simülasyonu ve Cyber Resilience

**Cyber Resilience – Siber Dayanıklılık**, saldırı meydana geldiğinde kurumun hizmetlerini sürdürebilme ve hızlı şekilde normale dönebilme kapasitesidir.

DDoS testi bu kavramın doğrudan bir parçasıdır.

Çünkü DDoS saldırısı başarısız olsa bile kurumu zorlayabilir.

Asıl hedef:

#### Hizmeti mümkün olduğunca devam ettirmek ve saldırının etkisini sınırlamak

olmalıdır.

Bu nedenle DDoS simulation sadece prevention değil;

Detection,

Response,

Recovery

kabiliyetlerini de ölçmelidir.

### Sonuç: DDoS Korumasına Sahip Olmak ile DDoS'a Hazır Olmak Aynı Şey Değildir

Bir kurum;

Anti-DDoS,

WAF,

CDN,

Firewall,

NDR,

SIEM

kullanıyor olabilir.

Ancak gerçek soru şudur:

#### Bunların tamamı aynı saldırı sırasında gerçekten birlikte çalışıyor mu?

Bu cevap ürün kataloglarından öğrenilemez.

Gerçek trafik altında ölçülmelidir.

Profesyonel DDoS saldırı simülasyonu;

hangi saldırı seviyesinde alarm oluştuğunu,

hangi noktada mitigation başladığını,

hangi bileşenin darboğaz oluşturduğunu,

gerçek kullanıcı deneyiminin nasıl etkilendiğini,

SOC ve Incident Response ekiplerinin ne kadar hızlı tepki verdiğini

gösterir.

Bu nedenle DDoS testi sadece teknik bir kapasite ölçümü değildir.

**Kurumsal siber dayanıklılığın kontrollü olarak doğrulanmasıdır.**

Ama DDoS testlerinin önemli bir kısmı ağ seviyesinde gerçekleşir.

Özellikle Layer 3 ve Layer 4 saldırıları;

firewall,

router,

load balancer,

internet bağlantısı

gibi kritik bileşenleri doğrudan zorlayabilir.

Bu nedenle bir sonraki adım network katmanındaki saldırıları daha detaylı anlamaktır.