# DDoS Saldırısı Nasıl Tespit Edilir? SOC, SIEM, NDR ve Trafik Analizi

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/ddos-simulasyonu/ddos-saldirisi-nasil-tespit-edilir-soc-siem-ndr

![DDoS Saldırısı Nasıl Tespit Edilir? SOC, SIEM, NDR ve Trafik Analizi](/images/bilgi-merkezi/covers/cover-ddos-10.webp)

Bir DDoS saldırısında ilk birkaç dakika kritik olabilir.

Çünkü saldırı başladığında kurumun önünde iki temel soru vardır:

#### Bu gerçekten bir DDoS saldırısı mı?

#### Yoksa normal kullanıcı trafiğinde ani bir artış mı var?

Bir kampanya, ürün lansmanı, haber gündemi veya yoğun müşteri ilgisi de trafik hacmini bir anda artırabilir.

Bu nedenle yalnızca:

**“Trafik yükseldi.”**

demek DDoS tespiti için yeterli değildir.

Doğru DDoS detection yaklaşımı;

- trafik hacmini,
- paket oranını,
- bağlantı davranışını,
- HTTP isteklerini,
- DNS sorgularını,
- uygulama performansını,
- kaynak IP dağılımını,
- hata oranlarını

birlikte değerlendirmelidir.

Bu noktada **SOC, SIEM, NDR, WAF, Anti-DDoS, CDN ve Application Monitoring** sistemlerinin birlikte çalışması kritik hale gelir.

Modern DDoS tespiti tek bir alarm üzerinden değil, çok sayıda teknik sinyalin bağlam içerisinde analiz edilmesiyle gerçekleştirilir.

Bu nedenle en önemli kavramlardan biri:

#### Traffic Baseline – Normal Trafik Davranışı

kavramıdır.

Çünkü normalin ne olduğunu bilmiyorsanız anormal olanı doğru şekilde tespit etmek zordur.

#### DDoS Detection Nedir?

**DDoS Detection**, bir sistem veya servise yönelik Distributed Denial of Service saldırısının mümkün olduğunca erken aşamada tespit edilmesi sürecidir.

Amaç yalnızca saldırıyı fark etmek değildir.

Aynı zamanda şu sorulara hızlı cevap verebilmektir:

#### Saldırı hangi servisi hedefliyor?

#### Hangi katmanda gerçekleşiyor?

#### Volumetric mi?

#### Layer 3/4 mü?

#### Layer 7 mi?

#### DNS hedefleniyor mu?

#### Gerçek kullanıcılar etkileniyor mu?

#### Mitigation gerekli mi?

Bu sorular Incident Response ve DDoS Mitigation kararlarını doğrudan etkiler.

### DDoS Saldırısının İlk Belirtileri Nelerdir?

DDoS saldırısının belirtileri saldırının türüne göre değişebilir.

Ancak genel olarak şu sinyaller görülebilir:

#### Bandwidth artışı

Network trafiğinin normal seviyelerin üzerine çıkması.

#### Packets Per Second – PPS artışı

Saniyedeki paket miktarının anormal yükselmesi.

#### Connections Per Second – CPS artışı

Çok sayıda yeni bağlantı oluşması.

#### Requests Per Second – RPS artışı

Web veya API isteklerinin hızla yükselmesi.

#### DNS QPS artışı

DNS sorgularının anormal şekilde artması.

#### Latency yükselmesi

Sistem cevap sürelerinin uzaması.

#### Packet Loss

Network üzerinde paket kayıplarının başlaması.

#### HTTP 5xx hataları

Backend'in yoğunluk nedeniyle cevap verememesi.

Bu göstergelerin hiçbiri tek başına kesin saldırı kanıtı değildir.

Bağlam gerekir.

### Traffic Baseline Nedir?

**Traffic Baseline**, kurumun normal trafik davranışının istatistiksel ve operasyonel olarak tanımlanmasıdır.

Örneğin bir web uygulamasında normalde:

ortalama 2.000 RPS,

peak 5.000 RPS,

ortalama 1 Gbps trafik,

250.000 PPS

görülüyor olabilir.

Bu değerler bilinirse ani değişimler daha kolay fark edilir.

Örneğin sistem gece 03:00'te bir anda 25.000 RPS alıyorsa bu davranış anormal olabilir.

Ancak Black Friday sırasında aynı trafik tamamen normal olabilir.

Bu nedenle baseline sadece ortalama değer değildir.

Aynı zamanda:

**zaman**

**gün**

**sezon**

**kampanya**

**kullanıcı davranışı**

gibi faktörleri içermelidir.

### Static Threshold ile Behavioral Detection Arasındaki Fark

DDoS tespiti iki temel yaklaşımla yapılabilir.

#### Static Threshold

Önceden belirlenmiş sabit limitler kullanılır.

Örneğin:

Bandwidth > 5 Gbps → alarm.

#### Behavioral Detection

Normal trafik davranışındaki sapmalar analiz edilir.

Örneğin:

Normal gece trafiğinin %400 üzerine çıkılması → alarm.

Static threshold basittir.

Ancak değişken trafikli kurumlarda false positive üretebilir.

Behavioral detection ise daha dinamik ve bağlama duyarlı olabilir.

### Anomaly Detection Nedir?

**Anomaly Detection**, normal davranıştan sapmaları tespit etmeye yönelik analiz yaklaşımıdır.

DDoS açısından;

trafik hacmi,

protokol dağılımı,

source IP çeşitliliği,

request pattern,

session behavior

gibi değişkenler analiz edilebilir.

Örneğin normalde HTTP trafiğinin %85'i GET iken bir anda POST istekleri %70'e çıkarsa bu anomali olabilir.

Ancak yine bağlam kontrol edilmelidir.

### DDoS Detection için Gbps Nasıl Kullanılır?

**Gbps – Gigabits Per Second**, toplam trafik hacmini ölçmek için kullanılır.

Özellikle volumetric saldırılarda önemlidir.

Örneğin kurumun normal peak trafiği:

3 Gbps

iken bir anda:

35 Gbps

trafik görülüyorsa ciddi bir anomali vardır.

Ancak Gbps tek başına yeterli değildir.

Çünkü düşük bandwidth fakat yüksek PPS saldırısı da sistemi etkileyebilir.

### PPS Neden İzlenmelidir?

**Packets Per Second – PPS**, network cihazlarının packet processing yükünü gösterir.

Örneğin iki saldırı düşünelim:

**A:** 8 Gbps / 500.000 PPS

**B:** 3 Gbps / 9 milyon PPS

İkinci saldırı daha düşük bandwidth oluşturmasına rağmen firewall veya router açısından daha ağır olabilir.

Bu nedenle SOC ve network monitoring sistemlerinde PPS mutlaka izlenmelidir.

### CPS Neden DDoS Tespitinde Önemlidir?

**Connections Per Second – CPS**, saniyede açılan yeni bağlantı miktarını gösterir.

SYN Flood veya TCP Connection Flood gibi saldırılarda CPS ciddi şekilde artabilir.

Örneğin normal:

10.000 CPS

iken saldırı sırasında:

500.000 CPS

görülebilir.

Bu durum firewall veya load balancer üzerindeki connection kaynaklarını tüketebilir.

### Concurrent Connections Ne Söyler?

Aynı anda açık bağlantı sayısı da kritik bir göstergedir.

Sistem normalde 100.000 aktif bağlantıyla çalışıyorsa ve kısa sürede milyonlarca bağlantıya çıkıyorsa kaynak tüketimi oluşabilir.

Ancak yüksek concurrent connection her zaman saldırı değildir.

Uzun yaşayan WebSocket veya streaming servisleri doğal olarak yüksek connection sayısına sahip olabilir.

### HTTP RPS DDoS Tespitinde Nasıl Kullanılır?

Layer 7 saldırılarında **Requests Per Second – RPS** en kritik metriklerden biridir.

Örneğin uygulama normalde:

2.500 RPS

alıyorsa bir anda:

40.000 RPS

görülebilir.

Ancak burada sadece toplam request sayısına değil, endpoint bazlı dağılıma bakılmalıdır.

Örneğin bütün trafik:

/login

endpoint'ine gidiyorsa bu çok daha anlamlıdır.

### Endpoint-Level Monitoring Neden Gereklidir?

Application Layer DDoS saldırıları genellikle belirli yüksek maliyetli endpoint'leri hedefleyebilir.

Bu nedenle monitoring;

/login

/search

/api/payment

/report

gibi kritik servisler için ayrı yapılabilir.

Örneğin uygulamanın toplam RPS'i normal olabilir.

Ama login servisi normalin 20 katı trafik alıyor olabilir.

Toplam trafik metriği bu saldırıyı gizleyebilir.

### HTTP Method Distribution Neden Önemlidir?

Normal uygulama davranışında GET, POST, PUT ve diğer HTTP methodlarının belli dağılımı olabilir.

Bir saldırı sırasında bu dağılım değişebilir.

Örneğin:

Normal durumda POST %10.

Saldırı sırasında POST %65.

Bu davranış özellikle login veya transaction endpoint'lerinde önemli sinyal olabilir.

### HTTP Status Codes DDoS Tespitinde Nasıl Kullanılır?

HTTP status code dağılımı uygulama sağlığı hakkında önemli bilgi verir.

Özellikle:

#### 429 Too Many Requests

Rate limiting devreye girmiş olabilir.

#### 500 Internal Server Error

Application hatası oluşabilir.

#### 502 Bad Gateway

Backend erişim problemi olabilir.

#### 503 Service Unavailable

Kaynak tüketimi veya servis kapasite problemi olabilir.

#### 504 Gateway Timeout

Backend cevap süresi yükselmiş olabilir.

DDoS sırasında 5xx oranlarının hızlı artması service exhaustion göstergesi olabilir.

### 429 Hataları Saldırı Göstergesi midir?

Her zaman değil.

429 hata kodu rate limiting mekanizmasının çalıştığını gösterir.

Bu olumlu bir güvenlik davranışı olabilir.

Ancak oran çok yüksekse kullanıcıların da limitlere takıldığı anlamına gelebilir.

Bu nedenle:

#### 429 Rate + Legitimate User Success Rate

birlikte değerlendirilmelidir.

### Latency DDoS Tespitinde Neden Önemlidir?

Bir sistem tamamen erişilemez hale gelmeden önce genellikle yavaşlar.

Normal response time:

200 ms

iken:

1.500 ms

seviyesine çıkabilir.

Bu durum özellikle Layer 7 saldırılarında erken sinyal olabilir.

Bu nedenle sadece uptime monitoring yeterli değildir.

Performance telemetry de gereklidir.

### P95 ve P99 Latency Neden Daha Değerlidir?

Average latency bazı problemleri gizleyebilir.

Örneğin kullanıcıların büyük bölümü hızlı cevap alırken belirli bir grup çok kötü deneyim yaşayabilir.

Bu nedenle:

#### P95

ve

#### P99

response time metrikleri izlenebilir.

Örneğin P99 değeri 8 saniyeye çıktıysa kullanıcıların belirli bölümü ciddi performans problemi yaşıyor olabilir.

### Packet Loss DDoS Belirtisi midir?

Yoğun network saldırısı sırasında network cihazları veya bağlantılar paketleri düşürmeye başlayabilir.

Packet loss;

internet hattı doygunluğu,

router saturation,

firewall overload

göstergesi olabilir.

Ancak network arızaları da packet loss oluşturabilir.

Bu nedenle saldırı telemetry'siyle birlikte analiz edilmelidir.

### Source IP Diversity Nedir?

**Source IP Diversity**, trafiğin kaç farklı kaynak IP'den geldiğini ifade eder.

Dağıtık botnet saldırılarında kaynak çeşitliliği çok yüksek olabilir.

Örneğin saniyeler içerisinde binlerce farklı IP görülebilir.

Ancak CDN, proxy ve mobile network kullanımı nedeniyle yüksek IP çeşitliliği normal trafik sırasında da görülebilir.

Bu nedenle source diversity tek başına saldırı kanıtı değildir.

### Source ASN Analizi Nedir?

IP adreslerinin ait olduğu **Autonomous System Number – ASN** bilgileri saldırı analizinde kullanılabilir.

Örneğin saldırı trafiğinin büyük bölümü;

hosting provider,

residential ISP,

cloud provider

kaynaklı olabilir.

ASN dağılımı botnet veya proxy altyapısı hakkında fikir verebilir.

### Geo-Location Analizi DDoS Tespitinde Kullanılır mı?

Evet, ancak dikkatli kullanılmalıdır.

Örneğin sadece Türkiye'de faaliyet gösteren bir kuruma bir anda dünyanın 120 ülkesinden trafik gelmesi anomali olabilir.

Ancak global hizmet veren bir kuruluş için aynı davranış normal olabilir.

Bu nedenle geography her zaman kurum bağlamıyla değerlendirilmelidir.

### User-Agent Analizi

Layer 7 saldırılarında User-Agent header'ları analiz edilebilir.

Örneğin bütün trafik aynı:

User-Agent

kullanıyorsa bot davranışı olabilir.

Ancak modern botlar gerçek browser User-Agent değerlerini taklit edebilir.

Bu nedenle tek başına User-Agent filtering yeterli değildir.

### Browser Fingerprinting DDoS Tespitinde Nasıl Kullanılır?

Browser fingerprinting;

TLS özellikleri,

browser davranışı,

JavaScript capabilities,

header kombinasyonları

gibi sinyaller üzerinden istemci profili oluşturabilir.

Çok sayıda IP farklı olsa bile aynı otomasyon framework'ünün fingerprint'i benzer olabilir.

Bu durum botnet trafiğinin korelasyonuna yardımcı olabilir.

### TLS Fingerprinting Neden Önemlidir?

HTTPS kullanımı nedeniyle HTTP içeriği bazı network noktalarında şifreli olabilir.

Ancak TLS handshake sırasında bazı metadata sinyalleri görülebilir.

Bu sinyaller belirli istemci davranışlarının sınıflandırılmasına yardımcı olabilir.

Özellikle bot ve automation detection açısından değerlidir.

### Session Behavior Nasıl Analiz Edilir?

Gerçek kullanıcılar genellikle belirli bir navigasyon akışı izler.

Örneğin:

Ana sayfa

↓

Ürün sayfası

↓

Sepet

↓

Ödeme

Bot ise sadece:

/search

endpoint'ine sürekli istek gönderebilir.

Bu nedenle session path analizi Layer 7 DDoS tespitinde oldukça değerlidir.

### Human Behavior ile Bot Behavior Nasıl Ayrılır?

Gerçek kullanıcı;

bekler,

scroll eder,

farklı sayfalara geçer,

session oluşturur.

Bot trafiği ise çoğu zaman;

çok düzenli,

çok hızlı,

tekrarlayan,

dar endpoint dağılımlı

olabilir.

Ancak gelişmiş botlar insan davranışını taklit etmeye çalışabilir.

Bu nedenle birden fazla telemetry kullanılması gerekir.

### Flash Crowd Nedir?

**Flash Crowd**, gerçek kullanıcı ilgisi nedeniyle trafik hacminin ani şekilde artmasıdır.

Örneğin;

Black Friday,

bilet satışı,

kritik haber,

ürün lansmanı

sırasında oluşabilir.

Teknik olarak Flash Crowd ile DDoS ilk bakışta birbirine benzeyebilir.

Her ikisinde de trafik artar.

Ancak trafik davranışı farklıdır.

### Flash Crowd ile DDoS Nasıl Ayrılır?

Bu ayrım DDoS detection'ın en zor alanlarından biridir.

Şu sinyaller yardımcı olabilir:

#### User Journey

Gerçek kullanıcı farklı sayfalara gider.

#### Session Duration

Gerçek session süreleri daha doğal olabilir.

#### Conversion

Gerçek kullanıcı alışveriş veya işlem gerçekleştirebilir.

#### Source Reputation

Botnet kaynakları riskli olabilir.

#### Request Repetition

Saldırı daha tekrarlı davranabilir.

#### Cookie/JavaScript Behavior

Gerçek browser özellikleri görülebilir.

Tek bir sinyal kesin sonuç vermez.

### Normal Kampanya Trafiği Yanlışlıkla Engellenebilir mi?

Evet.

Bu durum DDoS savunmasının ciddi risklerinden biridir.

Örneğin ürün lansmanı sırasında gerçek kullanıcı sayısı 10 kat artabilir.

Static rate limit saldırı zannederek kullanıcıları bloklayabilir.

Bu nedenle DDoS protection sistemlerinin business calendar ile de ilişkilendirilmesi faydalı olabilir.

### Business Context SOC için Neden Önemlidir?

SOC sadece paket ve log görmemelidir.

Örneğin pazarlama ekibi:

**“Saat 20:00'de ulusal kampanya başlıyor.”**

bilgisini SOC ile paylaşırsa beklenen trafik artışı daha doğru yorumlanabilir.

Bu nedenle siber güvenlik operasyonlarında business context önemlidir.

### NDR DDoS Saldırısını Nasıl Tespit Eder?

**Network Detection and Response – NDR**, network üzerindeki trafik davranışlarını analiz eder.

DDoS açısından;

bandwidth anomaly,

PPS spike,

source diversity,

protocol anomaly,

flow pattern

tespit edebilir.

NDR özellikle network seviyesindeki saldırılarda önemli görünürlük sağlar.

### NetFlow DDoS Analizinde Nasıl Kullanılır?

**NetFlow** network trafiğinin flow seviyesindeki özetini sağlar.

Örneğin;

source,

destination,

port,

protocol,

packet count,

byte count

bilgileri analiz edilebilir.

DDoS sırasında hangi hedef IP'nin, hangi portun ve hangi protokolün yoğunlaştığını anlamak için değerlidir.

**sFlow Nedir?**

**sFlow**, network trafiğini örnekleme yöntemiyle izlemeye yardımcı olan teknolojilerden biridir.

Büyük networklerde yüksek hacimli trafiğin analizinde kullanılabilir.

DDoS sırasında ani trafik değişimlerinin tespit edilmesine katkı sağlar.

### SIEM DDoS Saldırısını Nasıl Tespit Eder?

SIEM farklı güvenlik sistemlerinden gelen olayları merkezi olarak toplar ve korele eder.

Örneğin:

Firewall → yüksek SYN rate

WAF → HTTP Flood

NDR → bandwidth anomaly

Application → 503 error

Anti-DDoS → attack alert

SIEM bunları tek incident altında ilişkilendirebilir.

Bu yaklaşım SOC analistinin saldırıyı daha hızlı anlamasını sağlar.

### SIEM Correlation Rule Örneği Nasıl Düşünülmelidir?

İyi bir correlation yalnızca:

#### Traffic > X

şeklinde olmamalıdır.

Örneğin mantıksal olarak:

Traffic spike

connection failure

application latency

çok sayıda source IP

birlikte daha güçlü sinyal oluşturabilir.

Bu yaklaşım false positive oranını azaltabilir.

### SOC DDoS Olayını Nasıl Sınıflandırır?

İlk aşamada şu ayrım yapılabilir:

#### Volumetric

Bandwidth odaklı saldırı.

#### L3/L4

PPS, TCP, UDP veya connection odaklı saldırı.

#### Layer 7

HTTP/API odaklı saldırı.

#### DNS

DNS altyapısını hedefleyen saldırı.

#### Multi-Vector

Birden fazla saldırı tipi.

Bu sınıflandırma mitigation kararını belirler.

### Anti-DDoS Sistemleri Saldırıyı Nasıl Tespit Eder?

Anti-DDoS platformları;

traffic baseline,

protocol analysis,

packet rate,

signature,

behavior anomaly

gibi teknikleri kullanabilir.

Sistem normal trafik davranışını öğrenerek sapmaları tespit edebilir.

Bazı saldırılar otomatik olarak mitigate edilirken bazı durumlarda manuel doğrulama gerekebilir.

### WAF Layer 7 DDoS'u Nasıl Tespit Eder?

WAF uygulama trafiği üzerinde;

request rate,

URL,

HTTP method,

client fingerprint,

cookie,

session,

bot score

gibi bilgileri analiz edebilir.

Bu nedenle WAF, network seviyesinde görünmeyen Layer 7 saldırıları açısından kritik telemetry üretir.

### CDN Telemetry Neden Önemlidir?

CDN edge üzerinde çok geniş trafik görünürlüğüne sahip olabilir.

Örneğin;

requests per second,

cache hit,

edge location,

client distribution,

origin traffic

analiz edilebilir.

DDoS sırasında CDN'in gördüğü trafik ile origin'e geçen trafik karşılaştırılabilir.

Bu da mitigation başarısını gösterir.

### Origin Traffic Neden İzlenmelidir?

CDN çok yüksek saldırı trafiğini absorbe ediyor olabilir.

Ama eğer origin'e geçen trafik hâlâ kapasitenin üzerindeyse servis etkilenebilir.

Bu nedenle:

#### Edge Traffic

ve

#### Origin Traffic

ayrı ayrı izlenmelidir.

### Application Performance Monitoring DDoS Detection'da Nasıl Kullanılır?

**APM – Application Performance Monitoring**;

response time,

transaction latency,

database query time,

backend dependency

gibi verileri sağlar.

Layer 7 DDoS sırasında network tamamen normal görünebilir.

Ancak APM uygulama darboğazını gösterebilir.

Bu nedenle SOC ile application team arasında entegrasyon önemlidir.

### Database Monitoring DDoS Detection İçin Neden Önemlidir?

Bir HTTP Flood saldırısında gerçek hedef database olabilir.

Örneğin search endpoint'i yoğun çağrılır.

Web server ayaktadır.

Ama database CPU %100 olur.

Bu nedenle;

query latency,

connection pool,

CPU,

IO

değerleri izlenmelidir.

### Cache Hit Ratio DDoS Tespitinde Kullanılır mı?

Evet.

Normalde yüksek cache hit oranına sahip sistemde saldırı sırasında oran ciddi şekilde düşüyorsa saldırgan cache busting davranışı kullanıyor olabilir.

Bu durumda origin üzerindeki yük artar.

Özellikle CDN ve application telemetry birlikte analiz edilmelidir.

### DNS QPS DDoS Detection'da Nasıl Kullanılır?

DNS için;

QPS,

NXDOMAIN rate,

unique subdomain count,

response latency

izlenebilir.

Örneğin QPS artışı ile birlikte unique random subdomain oranı yükseliyorsa DNS Water Torture benzeri davranış araştırılabilir.

### Alert Fatigue DDoS Sırasında Neden Problem Olur?

DDoS saldırısı binlerce alarm üretebilir.

Firewall,

WAF,

NDR,

SIEM,

Application Monitoring

aynı anda alarm oluşturabilir.

Analistler her alarmı ayrı olay olarak görürse gerçek incident'ı anlamak zorlaşır.

Bu nedenle alert correlation ve incident grouping önemlidir.

### Event ile Incident Arasındaki Fark

Bir firewall alarmı **event** olabilir.

Binlerce event'in aynı saldırıyla ilişkili olduğu anlaşılırsa bu bir **incident** haline gelir.

SOC'un amacı event saymak değil, saldırı hikâyesini anlamaktır.

DDoS sırasında bu ayrım özellikle önemlidir.

### DDoS Detection Timeline Nasıl Oluşturulur?

Profesyonel olay analizi sırasında zaman çizelgesi oluşturulabilir.

Örneğin:

**14:02:00** – Trafik anormal yükseldi.

**14:02:18** – NDR anomaly oluşturdu.

**14:02:25** – Anti-DDoS alarm verdi.

**14:02:40** – WAF HTTP Flood tespit etti.

**14:03:10** – SOC incident açtı.

**14:03:35** – Mitigation başladı.

**14:04:05** – Kullanıcı deneyimi normale döndü.

Bu timeline DDoS operasyonunun etkinliğini ölçmek için çok değerlidir.

### Time to Detect Nedir?

**Time to Detect – TTD**, saldırının başladığı an ile ilk doğru tespit arasındaki süredir.

TTD ne kadar kısa olursa saldırıya o kadar hızlı müdahale edilebilir.

Ancak aşırı hassas detection false positive oluşturabilir.

Bu nedenle hız ile doğruluk arasında denge kurulmalıdır.

### Mean Time to Detect – MTTD Nedir?

**MTTD**, farklı olayların ortalama tespit süresini ölçmek için kullanılabilir.

DDoS operasyonunda farklı saldırı vektörleri için ayrı MTTD değerleri tutulabilir.

Örneğin;

Volumetric MTTD

Layer 7 MTTD

DNS DDoS MTTD

gibi.

Bu yaklaşım SOC olgunluğunu ölçmeye yardımcı olur.

### Time to Mitigate Neden Ayrı Ölçülmelidir?

Saldırıyı görmek ile durdurmak aynı şey değildir.

SOC 20 saniyede saldırıyı fark edebilir.

Ama mitigation 10 dakika sonra başlayabilir.

Bu nedenle:

#### Detection Time

ve

#### Mitigation Time

ayrı KPI'lar olmalıdır.

### DDoS Detection için Machine Learning Kullanılır mı?

Anomali tespitinde machine learning modelleri kullanılabilir.

Örneğin;

normal traffic pattern,

seasonality,

client behavior

öğrenilerek sapmalar belirlenebilir.

Ancak ML'nin varlığı otomatik olarak doğru detection anlamına gelmez.

Model kalitesi;

veri kalitesine,

baseline süresine,

trafik yapısına

bağlıdır.

### AI DDoS Detection'da Kullanılabilir mi?

AI tabanlı sistemler;

trafik sınıflandırması,

anomaly detection,

bot behavior,

event correlation

gibi alanlarda yardımcı olabilir.

Ancak özellikle kritik mitigation kararlarında insan doğrulaması veya güçlü güvenlik guardrail'leri önemlidir.

Yanlış model kararı gerçek müşterilerin bloklanmasına neden olabilir.

### DDoS Detection Engineering Nedir?

**Detection Engineering**, DDoS saldırılarını tespit etmek için gerekli telemetry, threshold, correlation ve alarm mantığının sistematik geliştirilmesidir.

Örneğin ekip şu soruyu sorabilir:

**“SYN Flood başladığında hangi sistemlerden hangi sinyalleri görmeliyiz?”**

Ardından;

NetFlow,

Firewall,

NDR,

Anti-DDoS

üzerinde detection senaryoları oluşturulur.

### Use Case Nedir?

SOC dünyasında **Use Case**, belirli saldırı davranışını tespit etmeye yönelik senaryodur.

Örneğin:

#### DDoS – High SYN Rate

veya

#### Layer 7 – Login Endpoint Flood

birer detection use case olabilir.

Her use case için;

data source,

threshold,

severity,

response action

tanımlanmalıdır.

### DDoS Detection Use Case Örneği

Örneğin bir Layer 7 senaryosu şu mantığı kullanabilir:

RPS > baseline'ın %300'ü

aynı endpoint'te yoğunlaşma

backend latency artışı

bot score yükselmesi

→ High Severity DDoS Alert

Bu tür çoklu sinyal korelasyonu false positive oranını azaltabilir.

### SOC Runbook Nedir?

**SOC Runbook**, alarm geldiğinde analistin hangi kontrolleri yapacağını açıklar.

DDoS alarmında örneğin:

- Trafik artışı doğrulanır.
- Etkilenen servis belirlenir.
- Layer sınıflandırması yapılır.
- Application impact kontrol edilir.
- Anti-DDoS durumu incelenir.
- Network ekibi bilgilendirilir.
- Gerekirse mitigation escalation yapılır.

Bu yapı müdahale hızını artırır.

### DDoS Detection Playbook ile Runbook Arasındaki Fark

Runbook daha spesifik analist adımlarını içerebilir.

Playbook ise daha geniş incident response akışını kapsayabilir.

Örneğin;

SOC,

Network,

Application,

ISP,

Management

arasındaki koordinasyon playbook içerisinde tanımlanabilir.

### DDoS Saldırısı Sırasında Başka Tehditler Nasıl İzlenir?

DDoS sırasında güvenlik ekipleri bütün dikkatini availability problemine verebilir.

Ancak saldırganlar bu yoğunluğu başka aktiviteleri gizlemek için kullanabilir.

Bu nedenle SOC aynı anda;

suspicious login,

data transfer,

privileged account activity,

malware alert

gibi diğer olayları da izlemeye devam etmelidir.

### DDoS ve Data Exfiltration Aynı Anda Olabilir mi?

Evet.

DDoS saldırısının kendisi veri çalmak zorunda değildir.

Ancak aynı kampanyanın başka aşamasında data exfiltration gerçekleşebilir.

Bu nedenle DDoS olayında:

**“Sadece erişilebilirlik saldırısı.”**

varsayımıyla olay kapsamı erken kapatılmamalıdır.

### DDoS Attack Attribution Yapılabilir mi?

Saldırının hangi aktör tarafından gerçekleştirildiğini kesin olarak belirlemek zor olabilir.

Botnet,

spoofed traffic,

proxy,

compromised devices

kaynak kimliğini gizleyebilir.

Threat Intelligence;

altyapı,

kampanya,

zamanlama,

tehdit mesajları

üzerinden değerlendirme yapabilir.

Ancak attribution konusunda yüksek güven seviyesi olmadan kesin iddialardan kaçınılmalıdır.

### Threat Intelligence DDoS Detection'a Nasıl Yardımcı Olur?

Threat Intelligence;

aktif botnet'ler,

DDoS grupları,

RDoS kampanyaları,

kullanılan altyapılar

hakkında bilgi sağlayabilir.

Bu bilgiler SOC monitoring'e eklenebilir.

Ancak DDoS tespitinde davranış analizi genellikle IOC tabanlı detection'dan daha önemlidir.

Çünkü botnet IP'leri sürekli değişebilir.

### DDoS Testleri Detection Kalitesini Nasıl Artırır?

Kontrollü DDoS saldırı simülasyonları mevcut detection'ların gerçekten çalışıp çalışmadığını ölçer.

Örneğin test sırasında;

NDR alarm verdi mi?

SIEM correlation oluştu mu?

SOC doğru severity atadı mı?

Application ekibi haberdar edildi mi?

Bu sonuçlar Detection Engineering'e girdi sağlar.

### Purple Team Yaklaşımı DDoS'ta Kullanılabilir mi?

Evet.

DDoS test ekibi kontrollü saldırı senaryosu gerçekleştirir.

SOC ve network ekipleri bunu tespit etmeye çalışır.

Sonrasında birlikte telemetry analiz edilir.

Eksik detection geliştirilir.

Tekrar test yapılır.

Bu, DDoS odaklı bir **Purple Team / Security Validation** yaklaşımıdır.

### DDoS Monitoring Dashboard Nasıl Olmalıdır?

Tek bir dashboard içerisinde şu metriklerin görünmesi faydalı olabilir:

#### Gbps

#### PPS

#### CPS

#### RPS

#### QPS

#### Latency

#### Packet Loss

#### HTTP Error Rate

#### Anti-DDoS Status

#### WAF Block Rate

#### Application Health

Bu yapı saldırı sırasında ekiplerin ortak görünüm kazanmasını sağlar.

### War Room Görünümü Neden Önemlidir?

Büyük DDoS olaylarında farklı ekipler aynı incident üzerinde çalışır.

SOC başka dashboard'a,

Network başka ekrana,

Application başka monitoring sistemine

bakıyorsa koordinasyon zorlaşabilir.

Ortak War Room dashboard'u saldırının teknik ve iş etkisini tek yerde göstermeye yardımcı olur.

### DDoS Detection'da Business Metrics Kullanılabilir mi?

Evet.

Örneğin e-ticaret platformunda;

successful checkout,

login success,

payment success,

active user

değerleri izlenebilir.

Teknik sistemler sağlıklı görünürken business transaction oranı düşüyorsa gerçek kullanıcı problemi olabilir.

Bu nedenle modern observability sadece altyapı metriği değildir.

### DDoS Alarm Seviyesi Nasıl Belirlenmelidir?

Severity şu faktörlere göre belirlenebilir:

#### Traffic Volume

#### Service Criticality

#### User Impact

#### Mitigation Status

#### Attack Duration

Örneğin düşük hacimli ancak ödeme API'sini tamamen durduran saldırı Critical olabilir.

Büyük hacimli fakat tamamen edge üzerinde filtrelenen saldırı ise teknik olarak daha düşük operasyonel etkiye sahip olabilir.

### DDoS Detection'da En Büyük Hata Nedir?

En büyük hatalardan biri sadece bandwidth threshold'a güvenmektir.

Bir kurum:

**“5 Gbps üzerinde alarm üret.”**

diyebilir.

Ancak 200 Mbps Layer 7 saldırısı login servisini tamamen durdurabilir.

Bu nedenle detection:

**Network + Application + Identity + Business**

bağlamını içermelidir.

### DDoS Saldırısı Nasıl Doğrulanır?

Bir alarm geldiğinde SOC aşağıdaki sorulara bakabilir:

#### Normal traffic baseline aşıldı mı?

#### Birden fazla telemetry aynı anomaliyi gösteriyor mu?

#### Gerçek kullanıcı deneyimi etkileniyor mu?

#### Trafik belirli endpoint'e yoğunlaşıyor mu?

#### Bot davranışı var mı?

#### Anti-DDoS saldırı olarak sınıflandırdı mı?

Bu değerlendirme yanlış pozitifleri azaltır.

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

Profesyonel bir DDoS tespit değerlendirmesi şu alanları içerebilir:

#### Traffic Baseline

Normal trafik davranışı.

#### Detection Sources

SOC, SIEM, NDR, WAF, CDN ve Anti-DDoS kaynakları.

#### Attack Timeline

Olayların kronolojik akışı.

#### Detection Gaps

Görülmeyen saldırı davranışları.

#### MTTD

Tespit süresi.

#### Mitigation Time

Savunmanın devreye girme süresi.

#### False Positive Analysis

Yanlış alarmlar.

#### Business Impact

Gerçek kullanıcı etkisi.

#### Improvement Plan

Detection Engineering önerileri.

### DDoS Detection KPI'ları Nelerdir?

Ölçülebilecek başlıca KPI'lar:

#### Mean Time to Detect – MTTD

#### Mean Time to Acknowledge – MTTA

#### Time to Mitigate – TTM

#### False Positive Rate

#### Legitimate Traffic Success Rate

#### Detection Coverage

#### Incident Escalation Time

Bu metrikler SOC ve DDoS operasyonlarının zaman içerisindeki gelişimini ölçmeyi sağlar.

### DDoS Detection ile DDoS Prevention Aynı Şey Değildir

Bu ayrım önemlidir.

Detection saldırıyı görür.

Prevention veya mitigation saldırının etkisini azaltır.

Bir kurum saldırıyı çok iyi tespit ediyor olabilir.

Ama mitigation kapasitesi yetersiz olabilir.

Başka kurum saldırıyı otomatik engelliyor olabilir ancak SOC hiçbir şey görmüyor olabilir.

İdeal modelde ikisi birlikte çalışır:

**Detect → Understand → Mitigate → Monitor → Recover**

### Sonuç: DDoS Saldırısını Görmeden Yönetemezsiniz

DDoS saldırısına karşı güçlü olmak yalnızca yüksek kapasiteli bir Anti-DDoS platformuna sahip olmak değildir.

Saldırının;

ne zaman başladığını,

hangi katmanı hedeflediğini,

hangi servisi etkilediğini,

gerçek kullanıcı davranışından nasıl ayrıldığını

anlayabilmek gerekir.

Bunun için tek bir metriğe bakmak yeterli değildir.

**Gbps** volumetric davranışı gösterebilir.

**PPS** packet processing yükünü gösterebilir.

**CPS** connection pressure seviyesini gösterebilir.

**RPS** application request yoğunluğunu gösterebilir.

**QPS** DNS saldırısını gösterebilir.

**Latency ve Error Rate** ise gerçek hizmet etkisini gösterir.

Modern DDoS detection bu sinyalleri;

**SOC + SIEM + NDR + WAF + Anti-DDoS + CDN + APM**

üzerinden birleştirir.

Ancak saldırıyı doğru şekilde görmek yalnızca ilk adımdır.

Asıl operasyon saldırı doğrulandıktan sonra başlar.

Kim aranacak?

Anti-DDoS ne zaman devreye alınacak?

ISP ne zaman bilgilendirilecek?

WAF kuralları değiştirilecek mi?

Rate limiting uygulanacak mı?

Gerçek kullanıcı trafiğinin etkilenip etkilenmediği nasıl kontrol edilecek?

Üst yönetime kim bilgi verecek?

Saldırı sona erdiğinde hangi kontroller yapılacak?

Bu soruların cevapları saldırı sırasında düşünülmemelidir.

Önceden hazırlanmış olmalıdır.

Bu nedenle DDoS güvenliğinin bir sonraki kritik konusu **Incident Response** sürecidir.