Sunucunuz Başkasına DDoS Yapıyor mu? SYN-ACK Yansıtmayı Tespit Etmek ve Azaltmak

SYN-ACK yansıtma, saldırganın kurbanın adresini kaynak gibi yazdığı sahte SYN paketlerini internetteki sunuculara göndererek, o sunucuların cevaplarını kurbana yönlendirdiği bir DDoS tekniğidir. Linux varsayılan ayarda cevapsız her SYN’e altı SYN-ACK gönderir. tcp_synack_retries=2 bunu üçe indirir; SYN cookies ve hız sınırı ise bu saldırıda hiç devreye girmez.

20 Ekim 2026 akşamı yönettiğim honeypot ağı bu saldırının yansıtıcılarından biri oldu. 19 saat boyunca 163 Türkiye barındırma bloğunun adresleri taklit edildi ve sensör gelen her baytı yaklaşık 4,8 katına çıkarıp kurbanlara geri yolladı (Tellal bülteni). Sensörün kendisi hiçbir sorun yaşamadı; yansıtıcının saldırıyı fark etmemesi de bu tekniğin bir parçası. Bu yazıda aynı soruyu kendi sunucunuz için soruyoruz: yansıtıcı mısınız ve öyleyseniz katkınızı nasıl azaltırsınız? Ayarları iki test konteyneri arasında tek bir cevapsız bağlantıyla ölçtüm; saldırı trafiği üretmedim.

SYN-ACK yansıtma nasıl çalışır?

TCP el sıkışmasının ilk adımı kötüye kullanılır. İstemci SYN gönderir, sunucu SYN-ACK ile cevap verir ve son ACK’i bekler. Saldırgan SYN’in kaynak alanına kurbanın adresini yazar, sunucu da cevabı kurbana yollar. Kurbanın bu bağlantıdan haberi olmadığı için ACK hiç gelmez; sunucu bağlantının kaybolduğunu düşünür ve aynı SYN-ACK’i birkaç kez yeniden gönderir.

Saldırganın kazancı iki yönlü. Kendi adresini gizler, çünkü trafik kurbana binlerce meşru sunucudan gelir ve bunlar engellenemez. Bir de çarpan elde eder: gönderdiği her SYN, yansıtıcıdan altı paket çıkarır. “Carpet bombing” türünde saldırgan tek bir adresi değil, bir barındırıcının bütün adres bloklarını aynı anda hedef alır; tek adres için kurulmuş koruma eşikleri böylece aşılmaz.

Sensörün 20-21 Ekim kaydı bu deseni gösteriyor:

Ölçüm	Değer
Süre	20 Ekim 19:24 - 21 Ekim 14:14 UTC
Sahte kaynak adres	15.133 adres, 163 /24 blok
Sunucuya yalnız tek paket gönderen akış	458.897 akışın %95,0’ı
Gelen ve giden paket	520.845 / 2.688.400
Gelen ve giden bayt	41,1 MB / 198,6 MB
Akış başına süre	31 saniye (SYN’den son SYN-ACK’e)

Sunucum yansıtıcı olarak kullanılıyor mu?

En güvenilir işaret, el sıkışmayı hiç tamamlamayan yarım açık bağlantılardır (SYN_RECV) ve bunların çok sayıda bloğa ince ince dağılmasıdır. Normal bir sunucuda bu tablo boş ya da birkaç satırdır. Aşağıdaki betik yalnız okur; ayarları ve yarım açık bağlantıları /24 bloklara göre gruplar:

#!/usr/bin/env bash
# yansitici-mi.sh: sunucunun SYN-ACK yansıtmasında kullanılıp kullanılmadığını
# ve yansıtma katsayısını belirleyen ayarları gösterir. Yalnız okur.
set -u

k() { cat "/proc/sys/net/ipv4/$1"; }
retries=$(k tcp_synack_retries)

echo "== Ayarlar"
echo "tcp_synack_retries = $retries  (cevapsız SYN başına $((retries + 1)) SYN-ACK; önerilen 2)"
echo "tcp_syncookies     = $(k tcp_syncookies)  (1 varsayılan; yalnız kuyruk taşınca devreye girer)"
echo "tcp_max_syn_backlog= $(k tcp_max_syn_backlog)"

echo "== Yarım açık bağlantılar (SYN_RECV)"
half=$(ss -Htn state syn-recv | awk '{print $4}')
total=$(printf '%s\n' "$half" | grep -c .)
echo "toplam: $total"
[ "$total" -eq 0 ] && exit 0

# Kaynakları /24 bloklarına topla: yansıtmada çok sayıda blok, blok başına az adres görülür.
printf '%s\n' "$half" | sed -E 's/:[0-9]+$//; s/^\[?::ffff://; s/\]$//' |
  awk -F. 'NF==4 {print $1"."$2"."$3".0/24"}' | sort | uniq -c | sort -rn > /tmp/syn24.$$
echo "farklı /24 blok: $(wc -l < /tmp/syn24.$$)"
echo "en kalabalık bloklar:"
head -5 /tmp/syn24.$$ | awk '{printf "  %5d  %s\n", $1, $2}'
rm -f /tmp/syn24.$$

Test konteynerinde, cevabı istemci tarafında güvenlik duvarına takılan tek bir bağlantı denemesinden hemen sonra çıktı şöyle:

== Ayarlar
tcp_synack_retries = 5  (cevapsız SYN başına 6 SYN-ACK; önerilen 2)
tcp_syncookies     = 1  (1 varsayılan; yalnız kuyruk taşınca devreye girer)
tcp_max_syn_backlog= 1024
== Yarım açık bağlantılar (SYN_RECV)
toplam: 1
farklı /24 blok: 1
en kalabalık bloklar:
      1  172.24.0.0/24

Tek satır bir şey anlatmaz; önemli olan ölçektir. Sensöre ortalama saniyede 7,7 sahte SYN geliyordu ve her biri 31 saniye yarım açık kaldı. Bu, herhangi bir anda yaklaşık 240 yarım açık bağlantı ve blok başına bir iki adres demektir. Betik birkaç dakika arayla yüzlerce farklı /24 bloğu, her birinde birkaç adres ve tamamlanan hiçbir bağlantı gösteriyorsa sunucunuz büyük ihtimalle yansıtıcıdır. Tek bir bloktan gelen yüzlerce yarım açık bağlantı ise farklı bir şeydir: o, size yönelik bir SYN selidir.

Yansıtma katsayısını ne belirler?

tcp_synack_retries belirler. Çekirdek belgesine göre bu değer, pasif bir bağlantı denemesi için SYN-ACK’in kaç kez yeniden gönderileceğidir ve varsayılanı 5’tir (kernel.org). İki konteyner arasında, istemcinin cevabı güvenlik duvarında düşürdüğü tek bir bağlantı denemesiyle sunucunun gönderdiği SYN-ACK’leri saydım:

## tcp_synack_retries=5: 6 SYN-ACK
  +  0.0 sn
  +  1.0 sn
  +  3.1 sn
  +  7.1 sn
  + 15.2 sn
  + 31.6 sn
## tcp_synack_retries=2: 3 SYN-ACK
  +  0.0 sn
  +  1.0 sn
  +  3.1 sn

Aralıklar her seferinde ikiye katlanıyor ve son yeniden gönderim varsayılanda 31,6. saniyeye düşüyor. Honeypot’taki akışların 31 saniye sürmesi, sensörün tam olarak bu varsayılanla çalıştığını gösteriyor. Değeri 2’ye indirmek, sunucunun bu saldırıdaki katkısını yarıya indirir ve yarım açık bağlantının bellekte kalma süresini 31 saniyeden 3 saniyeye kısaltır.

SYN cookies bu saldırıda neden yardım etmiyor?

Çünkü hiç devreye girmiyor. Linux’ta tcp_syncookies=1 zaten varsayılandır ve çekirdek belgesine göre cookie’ler yalnız bir soketin SYN kuyruğu taştığında gönderilir. Yansıtma saldırısında yük binlerce yansıtıcıya dağılır; sensörümüze saniyede 7,7 SYN geldi ve en fazla birkaç yüz yarım açık bağlantı oluştu, varsayılan kuyruk ise 1.024. Kuyruk hiç taşmadığı için çekirdek her SYN’i normal yoldan karşıladı ve altı SYN-ACK’in hepsini gönderdi.

Değeri 2 yapmak cookie’yi koşulsuz hale getirir, ama çekirdek belgesi bu modu yalnız test amacıyla anlatır ve cookie’lerin TCP uzantılarını devre dışı bıraktığını yazar. Yani “SYN cookies açık mı?” sorusu bu saldırı için yanlış sorudur; doğru soru “kaç kez yeniden gönderiyoruz?” sorusudur.

Hız sınırı neden işe yaramıyor?

Yansıtıcıya gelen trafik, hiçbir hız sınırının göremeyeceği kadar seyrektir. 520.845 gelen paket 163 bloğa ve 18 saat 50 dakikaya yayılınca, blok başına ortalama saniyede 0,05 paket çıkıyor; yani her bloktan yaklaşık 20 saniyede bir SYN. Bir saldırgan için bu verimli bir tasarımdır: yüzlerce yansıtıcının her biri düşük tempoda çalışır, toplamı kurbanın hattını doldurur.

Bu yüzden yansıtıcıda /24 başına hız sınırı ya da otomatik engelleme işe yaramaz. Eşiği bu tempoyu yakalayacak kadar düşürürseniz, kurban barındırıcının meşru müşterilerini de engellersiniz. Hız sınırı, tek bir kaynaktan gelen SYN seline karşı doğru araçtır; bu senaryo için değil. Genel güvenlik duvarı mimarisi için ufw, firewalld ve nftables karşılaştırması daha uygun başlangıç noktası.

Ayar kalıcı olarak nasıl yapılır, konteynerde neden ayrıca gerekir?

Sunucunun kendisinde bir sysctl dosyası yeterli:

echo 'net.ipv4.tcp_synack_retries = 2' | sudo tee /etc/sysctl.d/60-synack.conf
sudo sysctl --system
cat /proc/sys/net/ipv4/tcp_synack_retries

Docker’da bu yetmez. tcp_synack_retries ağ ad alanına (network namespace) bağlı bir ayardır ve bridge ağındaki her konteyner kendi değeriyle başlar. Host’ta değeri 2’ye çekip konteynerlerden okudum:

host önce:        5
host sonra:       2
bridge konteyner: 5
--network host:   2

Yayımlanmış bir porta dışarıdan gelen SYN, konteynerin ad alanında karşılanır; SYN-ACK’i konteyner gönderir ve konteyner hâlâ 5 kullanır. Coolify, Traefik ya da Nginx Proxy Manager gibi bir ters vekilin arkasındaki bütün sitelerde 80 ve 443’ü dinleyen tek konteyner vekilin kendisidir; ayarın verilmesi gereken yer orasıdır. docker run için --sysctl net.ipv4.tcp_synack_retries=2, Compose için:

services:
  proxy:
    sysctls:
      - net.ipv4.tcp_synack_retries=2

Coolify’da vekil (coolify-proxy) yapılandırması panelden düzenlenir; değişiklikten sonra vekili yeniden başlatıp değeri docker exec coolify-proxy cat /proc/sys/net/ipv4/tcp_synack_retries ile okuyun. Değeri 2’nin altına indirmeyin; her eksilen yeniden deneme, paket kaybı yaşayan meşru istemciler için bağlantı kurulamama ihtimalini artırır.

Ağ işletmecisiyseniz sahte kaynaklı paketleri nasıl durdurursunuz?

Kaynak adres doğrulamasıyla. Yansıtma saldırısı ancak bir ağ, kendisine ait olmayan kaynak adresli paketleri dışarı çıkarabildiğinde mümkündür. BCP 38 (RFC 2827), her ağın müşteri tarafından gelen ve müşteriye ait olmayan kaynak adresli paketleri düşürmesini öneriyor (RFC 2827). Linux yönlendiricide bu net.ipv4.conf.all.rp_filter=1 (katı) ya da 2 (gevşek) ayarıdır; MikroTik RouterOS’ta /ip settings set rp-filter=strict. Asimetrik yönlendirme olan ağlarda katı mod meşru trafiği düşürür; orada gevşek modu ya da müşteri arayüzlerinde prefiks listesine dayalı açık kuralları seçin. MikroTik güvenlik duvarının geri kalanı için brute force ve kural seti yazısına bakabilirsiniz.

Bu önlem kendi sunucunuzu korumaz, interneti korur; ama yansıtma saldırısını kaynağında durduran tek önlem budur.

Kurban sizseniz ne yapılır?

Yerel güvenlik duvarı kurtarmaz, çünkü sorun hattın kendisinin dolmasıdır. Trafik, binlerce meşru sunucudan gelen geçerli SYN-ACK paketleridir ve sunucunuza ulaştığında zarar zaten verilmiştir. Etkili önlem üst akıştadır: üst bağlantı sağlayıcının temizleme (scrubbing) hizmeti ya da hiç bağlantı başlatmadığınız SYN-ACK’leri ağınızın kenarında düşüren bir kural. Durum takipli bir güvenlik duvarı, eşleşen bir bağlantısı olmayan SYN-ACK’i “geçersiz” sayar ve düşürür; hat dolmadan önce kenar yönlendiricide uygulanırsa sunuculara gelen yükü keser. Saldırı sırasında üst sağlayıcıya hedef blokları, zaman aralığını ve “kaynak port 80/443’ten gelen SYN-ACK” imzasını iletmek temizlemenin ilk adımıdır.

Bugün yapılacakların kısa listesi nedir?

1. yansitici-mi.sh ile her internete açık sunucuda ayarları ve yarım açık bağlantıları okuyun.
2. Sunucuda /etc/sysctl.d/60-synack.conf ile net.ipv4.tcp_synack_retries = 2 yapın.
3. Docker kullanıyorsanız 80 ve 443’ü dinleyen ters vekil konteynerine aynı değeri sysctls ile verin ve konteyner içinden okuyarak doğrulayın.
4. tcp_syncookies değerini 1’de bırakın.
5. Bu saldırı için hız sınırı ya da otomatik engelleme kuralı kurmayın; kurban barındırıcının meşru trafiğini kesersiniz.
6. Cloudflare arkasındaysanız kaynak sunucuyu yalnız Cloudflare adreslerine açın.
7. Ağ işletiyorsanız müşteri tarafında kaynak adres doğrulamasını (BCP 38) açın.

Altyapınızdaki internete açık sunucuların ve konteyner vekillerinin bu açıdan denetimi için siber güvenlik ve sistem yönetimi sayfalarından bana ulaşabilirsiniz.