DDoS Saldırısı Değil: Connection Exhaustion Gerçeği

Modern web sistemlerinde yaşanan birçok “çökme” vakası ilk bakışta DDoS saldırısı gibi görünür. Trafik artmıştır, sistem yavaşlamıştır ve erişim sorunları başlamıştır.

Ama production ortamında her zaman durum bu değildir.

Bazı durumlarda sistem çökmemiştir. Sadece connection kapasitesi tükenmiştir.

---

Connection Exhaustion Nedir?

Connection exhaustion, bir sunucunun aynı anda yönetebileceği aktif bağlantı sayısının dolması durumudur.

Yani problem CPU ya da RAM değil, socket kapasitesidir.

Linux sistemlerde her TCP bağlantısı bir kaynak tüketir:

• file descriptor
• socket buffer
• kernel connection tracking
• worker thread

Bu kaynaklar dolduğunda sistem yeni bağlantı kabul edemez.

---

DDoS ile Karıştırılma Sebebi

Connection exhaustion en çok DDoS ile karıştırılır çünkü belirtiler benzerdir:

• Site açılmaz
• Timeout hataları oluşur
• Response süreleri artar
• Cloudflare 5xx hataları görünür

Ama arka planda CPU ve RAM normaldir.

Bu yüzden yanlış teşhis çok sık yapılır.

---

Gerçek Incident Senaryosu

Bir production ortamında yaşadığım bir olayda:

• CPU %20
• RAM %40
• Disk normal
• Ama site erişilemez durumda

İlk düşünce DDoS idi.

Ama sistemde şu komut çalıştırıldığında gerçek ortaya çıktı:

ss -s

Connection sayısı limitin çok üzerindeydi.

---

TIME_WAIT Patlaması

En kritik göstergelerden biri TIME_WAIT durumudur.

ss -ant | grep TIME_WAIT | wc -l

Eğer bu değer çok yükselirse:

• kısa ömürlü connection patlaması vardır
• sistem socket temizleyemez
• yeni bağlantılar kabul edilemez

Bu durum DDoS gibi görünür ama aslında kernel seviyesinde bir tıkanmadır.

---

Keepalive Yanlış Kullanımı

Connection exhaustion’un en sık sebeplerinden biri yanlış keepalive ayarlarıdır.

Örnek:

keepalive_timeout 65;

Bu değer yüksek trafik altında:

• açık connection sayısını artırır
• socket tüketimini hızlandırır
• worker saturation yaratır

---

Nginx Worker Limitleri

Bir diğer kritik nokta worker kapasitesidir:

worker_connections 1024;

Bu değer düşük olduğunda:

Sistem “çalışıyor gibi” görünür ama yeni connection alamaz.

---

Cloudflare Arkasında Daha Karmaşık Görünür

Cloudflare kullanıldığında problem daha da kafa karıştırıcı hale gelir.

Çünkü:

• Trafik edge’den gelir
• Gerçek client görünmez
• Retry pattern oluşur
• Connection sayısı katlanır

Bu durum debugging’i zorlaştırır.

---

Rate Limiting Tek Başına Çözüm Değildir

Birçok sistemde rate limiting çözüm sanılır:

limit_req zone=global rate=5r/s;

Ama connection exhaustion durumunda:

• request sayısı düşük olabilir
• ama connection süresi uzun olabilir

Bu yüzden rate limiting tek başına yeterli değildir.

---

Asıl Sorun: Request Süresi

Modern saldırılar artık hızlı request değil, uzun connection kullanır.

Örnek:

• slow HTTP attack
• keep-alive abuse
• partial request flood

Amaç trafik üretmek değil, socket kilitlemektir.

---

Debug İçin Bakılması Gerekenler

Production’da doğru analiz için şunlar incelenmelidir:

• active connections
• TIME_WAIT sayısı
• SYN backlog
• upstream latency
• file descriptor usage
• conntrack table

CPU burada ikinci plandadır.

---

Gerçek Çözüm Yaklaşımı

Connection exhaustion çözümü tek bir ayarla olmaz.

Doğru yaklaşım:

• kernel tuning
• Nginx worker optimizasyonu
• keepalive dengesi
• firewall connection limit
• rate + behavior kombinasyonu

---

Sonuç

Connection exhaustion, modern web sistemlerinde en yanlış teşhis edilen problemlerden biridir.

Dışarıdan DDoS gibi görünür ama aslında:

Sistem ölmemiştir, sadece bağlantı kapasitesini doldurmuştur.

Bu yüzden production’da en kritik metrik CPU değil, connection davranışıdır.

Gerçek sistem yönetimi burada başlar.