Teknik derinlik
Linux Sunucu DDoS Sıkılaştırma: sysctl, conntrack ve nftables Ayarları
Son güncelleme: Ağustos 2026 · Her sysctl ve nftables ayarı, değeri ve doğrulaması · Okuma süresi ~24 dk

Linux sunucuda DDoS sıkılaştırması üç sonlu kaynağı korur: SYN ve accept kuyrukları, conntrack tablosu ve dosya tanıtıcıları. Her parametrenin bir varsayılanı, bir işlevi ve bir doğrulama sayacı vardır ve sıkılaştırma bu üçünü bilmekle başlar. Değerler temel ölçülerinize göre seçilir; kopyalanan değer ya etkisizdir ya kendi kullanıcınızı keser.
Bu rehber tek bir soruya odaklanır: Linux sunucunun kendisi, önünde herhangi bir cihaz olmadan, bir DDoS saldırısının durum tüketen kısmına karşı nasıl sertleştirilir. Aradaki koruma katmanlarını konu almıyoruz. Konumuz sunucunun kendi çekirdek ayarları.
Konuyu anlatan çoğu yazı bir sysctl listesidir: yirmi satır, açıklama yok. Liste çalışır gibi görünür çünkü değerler zararsızdır. Saldırı günü ise hangi satırın ne yaptığını bilmeyen ekip hangi sayaca bakacağını da bilmez. Aşağıda her parametrenin değeri, işlevi ve doğrulama komutu birlikte verilir. Bir saldırının host üzerinde tüketebileceği kaynak sonludur ve sayılıdır. Her birini kendi bölümünde ele alıyoruz.
| Cihaz | Kaynak | Belirti | Doğrulama komutu |
|---|---|---|---|
| SYN / accept kuyruğu | Yeni bağlantılar sessizce zaman aşımına düşer | nstat -az | grep -i listen | |
| conntrack tablosu | dmesg: 'nf_conntrack: table full, dropping packet' | conntrack -C; conntrack -S | |
| Dosya tanıtıcıları | accept() EMFILE; port dinliyor ama kabul yok | cat /proc/<pid>/limits; cat /proc/net/sockstat | |
| TIME_WAIT / orphan soket | Efemer port veya bellek tükenir; log'da 'Out of socket memory' | ss -tan state time-wait | wc -l; cat /proc/net/sockstat | |
| Soket tamponları | Meşru trafik yoğunlukta paket kaybeder | netstat -s | grep -i prune; cat /proc/net/softnet_stat |
Beş satırın hepsi bu makalenin konusudur ve hepsi host üzerinde ölçülür. Paket hızının işlemciyi doyurması (softirq) ayrı bir katmandır ve ağ yığını rehberinde ele alınır.
0. Önce temel ölçüler, sonra ayar
Sıkılaştırmadan önce normal bir haftanın rakamlarını kaydedin. Aşağıdaki her eşik bu rakamlara göre seçilir.
# Anlık oturum özeti (established, syn-recv, time-wait dağılımı)
ss -s
# Soket sayaçları: tcp inuse / orphan / tw, tcp mem
cat /proc/net/sockstat
# conntrack doluluğu ve tavanı
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max
# Kümülatif TCP olayları — el sıkışması, kuyruk düşürmeleri
nstat -az | grep -Ei 'syn|listen|drop|overflow'
# Zaman içinde izlemek için
watch -n1 'cat /proc/net/sockstat; echo; nstat | grep -Ei "listen|syncookie"'
Bu beş komutun çıktısı sizin temel ölçülerinizdir. Bir hafta sonra aynı komutları çalıştırıp neyin değiştiğini böyle görürsünüz. Kopyalanan eşiğin sorunu, bu adımı atlamasıdır.
1. SYN tarafı: iki ayrı kuyruk vardır
Çekirdek her dinleyen soket için iki kuyruk tutar. Yarım açık kuyruk el sıkışması
tamamlanmamış (SYN_RECV) bağlantıları tutar; boyutu tcp_max_syn_backlog. Accept kuyruğu
el sıkışması bitmiş, accept() bekleyen bağlantıları tutar; tavanı somaxconn ile uygulamanın
listen() backlog’unun küçüğüdür.
Bu ayrım yüzünden yalnız sysctl’i büyütmek çoğu zaman hiçbir şey değiştirmez: uygulama 128 ile dinliyorsa çekirdeğe ne yazdığınızın önemi yoktur.
# /etc/sysctl.d/90-ddos.conf — SYN katmanı
net.ipv4.tcp_syncookies = 1 # kuyruk taşınca cookie; modern varsayılan
net.ipv4.tcp_max_syn_backlog = 8192 # yarım açık kuyruk boyutu
net.core.somaxconn = 8192 # accept kuyruğu tavanı
net.ipv4.tcp_synack_retries = 2 # cevapsız SYN_RECV ömrünü kısaltır
net.ipv4.tcp_syn_retries = 3 # giden bağlantılar için; istemci tarafı
Uygulama backlog’unu da aynı anda yükseltin, yoksa somaxconn tek başına işe yaramaz:
# nginx: dinleme backlog'u somaxconn'a hizalanır
listen 443 ssl backlog=8192;
Doğrulama. SYN_RECV durumundaki soketleri ve kuyruk düşürmelerini okuyun:
# O anda kaç bağlantı yarı açık?
ss -tan state syn-recv | wc -l
# Accept kuyruğu doluluğu: Recv-Q anlık birikme, Send-Q tavan
ss -ltn
# Kuyruk taşması sayaçları — sıfırdan ayrılırsa accept zinciri dar
nstat -az | grep -E 'TcpExtListenDrops|TcpExtListenOverflows'
# SYN cookie fiilen devreye girdi mi?
nstat -az | grep -i syncookie
SyncookiesSent sıfırdan büyükse kuyruğunuz en az bir kez taşmış demektir; bu, backlog’u
yükseltme ya da bir üst katmanı devreye alma sinyalidir. SYN cookie devredeyken TCP zaman
damgaları kapalıysa pencere ölçekleme ve SACK o bağlantılar için kaybolur; bu yüzden cookie’ye
güvenmek yerine kuyruğun hiç taşmamasını hedefleyin.
tcp_abort_on_overflow accept kuyruğu taştığında sessiz düşürme yerine RST gönderir. Varsayılan
(0) sessiz düşürmedir ve genelde doğrudur, çünkü istemciye tekrar deneme şansı bırakır. Arkanızda kendi
yeniden deneme mantığı olan bir yük dengeleyici varsa 1 daha dürüst bir sinyaldir:
sysctl -w net.ipv4.tcp_abort_on_overflow=1 # yalnız gerekçe varsa
2. conntrack: tablo dolunca yeni akış giremez
Netfilter bağlantı izlemesi her akış için bir girdi tutar. Tablo dolduğunda çekirdek yeni akışın paketini düşürür. Belirti sinsidir: mevcut oturumlar yaşar, yeni gelen herkes dışarıda kalır, grafik “trafik normal” der.
# Mevcut doluluk ve tavan
conntrack -C
cat /proc/sys/net/netfilter/nf_conntrack_max
# Hangi durumda kaç akış var? (SYN_SENT seli burada patlar)
conntrack -L 2>/dev/null | awk '{print $4}' | sort | uniq -c | sort -rn
# Düşürme başladı mı?
dmesg | grep -i 'nf_conntrack: table full'
conntrack -S | grep -Eo 'drop=[0-9]+'
Üç kol vardır. Boyut, ömür ve hiç izlememe.
# /etc/sysctl.d/90-ddos.conf — conntrack
net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_tcp_timeout_established = 3600 # varsayılan 432000 (5 gün)
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 30 # yarım açığı hızlı temizle
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 30
net.netfilter.nf_conntrack_tcp_loose = 0 # tek yönlü akışı izleme
Hash tablosu boyutu (buckets) sysctl’den değil, modül parametresinden ayarlanır; boyutun
tavanın en az sekizde biri olması çarpışmayı azaltır:
echo 262144 > /sys/module/nf_conntrack/parameters/hashsize
# kalıcı: /etc/modprobe.d/nf_conntrack.conf içine
# options nf_conntrack hashsize=262144
Üçüncü kol, durumsuz yüksek hacimli trafiği tablonun tamamen dışında tutmaktır. nftables raw zinciri:
table inet raw {
chain prerouting {
type filter hook prerouting priority raw; policy accept;
udp dport 53 notrack
tcp dport 53 notrack
}
}
Yetkili DNS gibi durumsuz bir servis bu kuralla conntrack selinden bağışıklaşır. Bedeli açık: o
trafik üzerinde ct state isteyen kural çalışmaz.
Alarm eşiği: doluluğu tavanın yüzde yetmişinde izleme sisteminize bağlayın.
awk -v max="$(cat /proc/sys/net/netfilter/nf_conntrack_max)" \
-v cur="$(cat /proc/sys/net/netfilter/nf_conntrack_count)" \
'BEGIN{ printf "conntrack %d/%d = %.0f%%\n", cur, max, 100*cur/max }'
3. Dosya tanıtıcıları: en kısa halka geçerli
Her açık bağlantı bir dosya tanıtıcısıdır. Tükenince accept() EMFILE ile döner; servis ayakta,
port dinlemede, ama kimseyi almıyor. Yavaş bağlantı saldırılarının hedefi tam budur.
Sınır bir zincirdir ve en düşük halka geçerlidir:
# Sistem geneli tavan
cat /proc/sys/fs/file-max
# Süreç başına mutlak tavan
cat /proc/sys/fs/nr_open
# O anda kaç tanıtıcı açık / tavan ne?
cat /proc/sys/fs/file-nr
# /etc/sysctl.d/90-ddos.conf — sistem geneli
fs.file-max = 2097152
fs.nr_open = 1048576
Asıl darboğaz neredeyse her zaman servis birimi sınırıdır, çünkü çoğu dağıtımda düşük kalır.
Kalıcı çözüm systemd drop-in’idir; ulimit ile uğraşmayın, o kabuğunuzu anlatır, servisi değil:
# /etc/systemd/system/nginx.service.d/limits.conf
[Service]
LimitNOFILE=262144
systemctl daemon-reload
systemctl restart nginx
# Servisin GERÇEK sınırı (kabuğunki değil):
systemctl show nginx -p LimitNOFILE
cat /proc/$(pgrep -o nginx)/limits | grep 'open files'
# Genel soket kullanımı:
cat /proc/net/sockstat # sockets: used ...; TCP: inuse ...
4. TIME_WAIT ve orphan soketler: sessiz tükenme
Kısa ömürlü bağlantı seli TIME_WAIT birikimi ve orphan (sahipsiz) soketlerle iki kaynağı tüketir:
efemer port aralığı ve TCP soket belleği. Belirti dmesg’de TCP: out of memory ya da
Out of socket memory satırıdır.
# Durum dağılımı
ss -tan state time-wait | wc -l
ss -tan state fin-wait-1 | wc -l
# Orphan / tw sayısı ve tcp mem baskısı
cat /proc/net/sockstat
# tcp_mem: low pressure high (üçüncü sayı sayfa cinsinden sert tavan)
cat /proc/sys/net/ipv4/tcp_mem
# /etc/sysctl.d/90-ddos.conf — TIME_WAIT / orphan
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_max_tw_buckets = 1440000
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_tw_reuse = 1 # giden bağlantılar için güvenli
net.ipv4.ip_local_port_range = 1024 65535
tcp_tw_reuse yalnız giden bağlantılarda ve zaman damgaları açıkken güvenlidir; eski
tcp_tw_recycle parametresini kullanmayın, NAT arkasındaki istemcileri kırar ve modern
çekirdeklerde zaten kaldırılmıştır. tcp_max_orphans aşıldığında çekirdek fazla soketi RST ile
kapatır ve dmesg’e too many orphaned sockets yazar; bu bir savunma davranışıdır, sınırı meşru
yükünüzün üzerinde tutun.
5. Soket tamponları ve alım kuyruğu
Bu katman saldırıyı durdurmaz. Yaptığı şey, saldırı sırasında meşru trafiğin ezilmesini azaltmaktır. Alım yolundaki kuyruk taşarsa iyi paket de kötü paketle birlikte düşer.
# /etc/sysctl.d/90-ddos.conf — tamponlar ve alım kuyruğu
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.netdev_max_backlog = 16384 # NIC → çekirdek arası kuyruk
net.core.netdev_budget = 600 # softirq başına işlenecek paket
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
Doğrulama. Alım yolunda paket düştü mü, softirq bütçesi doldu mu:
# softnet_stat: 1. sütun işlenen, 2. sütun DÜŞEN, 3. sütun budget/time-limit ile bırakılan
cat /proc/net/softnet_stat
# TCP tarafında prune / collapse (tampon baskısı işareti)
netstat -s | grep -Ei 'prune|collapse|out of'
nstat -az | grep -Ei 'TcpExtTCPRcvQDrop|PruneCalled'
softnet_stat ikinci sütunu artıyorsa netdev_max_backlog’u; üçüncü sütunu artıyorsa
netdev_budget’i yükseltin. Üçüncü sütunun kronik artışı aynı zamanda paket hızının işlemciyi
doyurmaya başladığının erken işaretidir. O çizgi bu makalenin sınırıdır ve
ağ yığını tuning rehberine geçer.
6. Sahte kaynak, ICMP ve yönlendirme yüzeyi
Küçük ama gerekli bir grup. Sahte kaynak adresli paketlere ve reflection yüzeyine karşı:
# /etc/sysctl.d/90-ddos.conf — anti-spoof ve ICMP
net.ipv4.conf.all.rp_filter = 1 # ters yol doğrulaması (sıkı)
net.ipv4.conf.default.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1 # smurf yüzeyini kapat
net.ipv4.icmp_ratelimit = 1000
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.tcp_timestamps = 1 # tw_reuse ve PAWS için gerekli
rp_filter=1 (sıkı mod) yalnız tek çıkışlı sunucuda doğrudur. Asimetrik yönlendirmeli,
birden çok yoldan trafik alan bir makinede sıkı mod meşru paketleri düşürür; orada 2 (gevşek
mod) seçilir. Yanlış modu saldırı olmadan kesinti üretebilir; hangi modda olmanız gerektiğini
bilmeden 1 yazmayın:
# Arayüz bazında etkin rp_filter değeri (all ve arayüz maksimumu geçerlidir)
for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo "$i = $(cat $i)"; done
# rp_filter kaç paket düşürdü?
nstat -az | grep -i 'IPReversePathFilter'
7. nftables ile kaynak başına oran sınırı
Kuyrukları büyütmek pasif yarıdır. Aktif yarı, tek kaynağın payını çekirdek içinde sınırlamaktır. nftables dinamik kümesi bunu kaynak adres başına yapar:
table inet filter {
set flood4 { type ipv4_addr; flags dynamic; timeout 60s; }
set flood6 { type ipv6_addr; flags dynamic; timeout 60s; }
chain input {
type filter hook input priority filter; policy accept;
ct state established,related accept
ct state invalid drop # yarım/bozuk akışı at
# Kaynak başına yeni bağlantı hızı — IPv4 ve IPv6 ayrı
tcp dport { 80, 443 } ct state new \
add @flood4 { ip saddr limit rate over 30/second } drop
tcp dport { 80, 443 } ct state new \
add @flood6 { ip6 saddr limit rate over 30/second } drop
}
}
Doğrulama. Hangi kaynaklar sınıra takıldı, kural kaç paket düşürdü:
# Sınıra takılıp kümeye giren kaynaklar
nft list set inet filter flood4
# Kural sayaçları (kurala 'counter' eklerseniz)
nft list ruleset | grep -A2 flood
# ct state invalid ne kadar düşürdü — sayaçlı kural örneği
nft add rule inet filter input ct state invalid counter drop
IPv6 kümesini atlarsanız savunmanın yarısı eksik kalır. Eşik değeri ölçümünüzden gelir: NAT
arkasından gelen yoğun ama meşru kullanıcıda 30 düşük bile olabilir, kurumsal API’de yüksek
kalabilir. İlk hafta kuralı drop yerine counter ile çalıştırıp kimlerin takıldığına bakın,
meşru trafiği kesmediğinden emin olunca drop’a çevirin.
synproxy de vardır; el sıkışmasını çekirdek üstlenir ve arkadaki servise yalnız tamamlanmış
bağlantı gider. Ama asimetrik yönlendirme ve conntrack ayarlarıyla etkileşimi hassastır, test
ortamında doğrulamadan üretime koymayın.
Kaynak başına sınırın dürüst sınırı: az sayıda adresten gelen yoğun saldırıya karşı etkilidir. Binlerce adrese yayılmış, adres başına eşiğin altında kalan bir sel toplamda hattınızı doldurabilir ve bu kural onu görmez. Aynı mantığın prefix ölçeğindeki karşılığını halı bombardımanı rehberinde ele almıştık.
8. Uygulama katmanı bağlantı davranışı
Çekirdek kuyruğu geçen bağlantı uygulamaya gelir; orada da bekleyen bir bağlantı kaynak tutar. Bu makale çekirdeğe odaklanıyor, ama iki sysctl doğrudan uygulama davranışını etkiler:
net.ipv4.tcp_keepalive_time = 300 # ölü bağlantıyı erken sez
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3
Yavaş bağlantı saldırıları (bağlantıyı açıp veriyi damla damla gönderme) çekirdek düzeyinde tam çözülmez; asıl savunma web sunucusunun kendi timeout’larıdır. Onu sunucu bazında ayrı ele alıyoruz: nginx sıkılaştırma ve Apache sıkılaştırma rehberleri bu timeout’ları direktif direktif veriyor.
Tam dosya ve tek seferde yükleme
Bölümlerin birleştirilmiş hâli:
sudo tee /etc/sysctl.d/90-ddos.conf >/dev/null <<'EOF'
# --- SYN ---
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192
net.ipv4.tcp_synack_retries = 2
# --- conntrack ---
net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_tcp_timeout_established = 3600
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 30
# --- dosya tanıtıcıları ---
fs.file-max = 2097152
fs.nr_open = 1048576
# --- TIME_WAIT / orphan ---
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_max_tw_buckets = 1440000
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_tw_reuse = 1
# --- tamponlar ---
net.core.netdev_max_backlog = 16384
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# --- anti-spoof / ICMP ---
net.ipv4.conf.all.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.tcp_timestamps = 1
EOF
sudo sysctl --system
# uygulandığını doğrula
sudo sysctl -a 2>/dev/null | grep -E 'somaxconn|syncookies|conntrack_max|file-max|rp_filter'
Değerlerin hiçbiri yeniden başlatma istemez ve hepsi geri alınabilir. Ama hepsi başlangıç noktasıdır; kendi temel ölçülerinize göre yukarı ya da aşağı çekilir. Bir rehberin size kesin sayı vermesi yanıltıcı olur, çünkü doğru sayı sizin oturum sayınıza, kaynak dağılımınıza ve donanımınıza bağlıdır.
İzlemeye bağlanacak sayaçlar
Sıkılaştırma hissedilmez, okunur. Bu altı sinyali alarm sistemine bağlayın:
# 1. SYN kuyruğu düşürmeleri
nstat -az | grep -E 'ListenDrops|ListenOverflows'
# 2. SYN cookie kullanımı (taşma göstergesi)
nstat -az | grep -i syncookiessent
# 3. conntrack doluluk oranı (>%70 uyarı)
cat /proc/sys/net/netfilter/nf_conntrack_count
# 4. dosya tanıtıcısı kullanımı
cat /proc/sys/fs/file-nr
# 5. alım yolu düşürmeleri
awk '{s+=$2} END{print "softnet drops:", s}' /proc/net/softnet_stat
# 6. soket bellek baskısı
grep -E 'TCP:' /proc/net/sockstat
Bu altı satır, bir saldırı sırasında “host mu daralıyor, hat mı doluyor” sorusunu dakikada cevaplar.
Bu katmanın dürüst sınırı
Buraya kadar yapılan her şey tek cümleye iner: sunucu, kendi durumunu tüketen saldırılara karşı savunulabilir. Bunun dışında iki durum var ve ikisi de host’ta çözülmez.
Birincisi hat doluluğu. Erişim hattınızı aşan hacim çekirdeğe hiç ulaşmaz; sysctl görmediği paketi düşüremez. Bu eşiğin üstünde konu artık sunucu değil, şebeke mimarisidir.
İkincisi paket hızı. Hat dolmadan önce, saniyedeki paket sayısı çekirdeğin kesme işleme
kapasitesini doyurabilir; belirtisi softnet_stat üçüncü sütunu ve softirq’e giden CPU
yüzdesidir. O katmanın ayarları başka bir dünyadır: kesme dağıtımı, sürücü kuyrukları, RSS/RPS ve
alım yolu. Linux ağ yığını tuning rehberinde komut komut ele
alınır.
Bu iki eşiğin üstünde host sıkılaştırması gereksiz olmaz. Tersine, tabanı yükselttiği için üst katman devreye girene kadar ve girdikten sonra sunucunun ayakta kalmasını sağlayan şey odur. Ama tek başına yeterli değildir ve öyleymiş gibi davranmak yanlış güven üretir.
Uygulama sırası
- Temel ölçüleri kaydedin (Bölüm 0). Bir hafta sabır ister; en pahalı adım budur.
90-ddos.confdosyasını yazın,sysctl --systemile yükleyin,grepile doğrulayın.- Uygulama backlog’unu (
listen ... backlog=)somaxconnile hizalayın. - Servis birimlerine
LimitNOFILEdrop-in’i ekleyin,systemctl showile doğrulayın. - conntrack boyut/ömrünü ayarlayın; durumsuz servisleri
notrackile tablo dışına alın. - nftables oran sınırını önce
countermodunda bir hafta çalıştırın, sonradrop’a çevirin. - Altı sayacı izleme sistemine alarm olarak bağlayın.
Yedi adımın hiçbiri yeniden başlatma gerektirmez ve hepsi geri alınabilir.
Sık sorulan sorular
- Tüm ayarları tek dosyada mı toplamalıyım?
- Evet, ve /etc/sysctl.d/ altında ayrı bir dosyada. Dağıtımın kendi dosyalarını değiştirmek yerine 90-ddos.conf gibi yüksek numaralı bir dosya oluşturun; numara yüksek olduğu için çakışan bir parametrede sizinki kazanır. Yükleme: sysctl --system tüm dizini yeniden okur, sysctl -p /etc/sysctl.d/90-ddos.conf yalnız o dosyayı. Kalıcı olması için dosya şart; sysctl -w ile yazdığınız değer yeniden başlatmada kaybolur.
- Bu değerleri değiştirmek yeniden başlatma ister mi?
- Neredeyse hiçbiri istemez; sysctl parametreleri anında geçerli olur. İstisna, çok erken okunan birkaç değerdir ve conntrack hash tablosu boyutudur: nf_conntrack_buckets çalışırken /sys/module/nf_conntrack/parameters/hashsize üzerinden değiştirilir, sysctl'den değil. Dosya tanıtıcısı için systemd drop-in'i systemctl daemon-reload ve servisin yeniden başlatılmasını ister; sysctl gibi anında geçmez.
- conntrack'i tamamen kapatabilir miyim?
- NAT ve durum bilgisi kullanmayan bir sunucuda seçici olarak, evet. nftables'ın raw zincirindeki notrack hedefi belirli trafiği tablonun tamamen dışında tutar; yetkili DNS'in 53 numaralı portu klasik örnektir. Böylece o trafik conntrack tablosunu dolduramaz, çünkü onun için tablo tutulmaz. Bedeli, o trafik üzerinde durum isteyen (ct state) kuralların çalışmamasıdır; bunu bilerek seçmiş olursunuz.
- Bu ayarlar hacimsel bir saldırıyı durdurur mu?
- Hayır. Erişim hattınızı dolduran trafik çekirdeğe hiç ulaşmaz; görmediği paketi yönetemez. Bu makaledeki her ayar durum tükenmesine karşıdır: kuyruklar, tablolar, tanıtıcılar ve tamponlar. Hat kapasitesinin üzerindeki hacim host'un sorunu değildir ve host'ta çözülmez; o eşiğin üstünde tek yer şebeke tarafıdır.
- Değerleri konteyner içinde mi host'ta mı ayarlamalıyım?
- Ağ yığını parametrelerinin çoğu ağ ad alanına özgüdür ve konteynerin kendi ad alanında ayrıca ayarlanmalıdır; host'taki değer içeriye geçmez. Kubernetes'te bunun için güvenli sayılan bir alt küme sysctl'e izinlidir, gerisi ayrıcalıklı bağlam ister. fs.file-max gibi sistem geneli değerler ise host'ta kalır ve tüm konteynerleri kapsar. Hangi parametrenin ad alanına özgü olduğunu kritik bir ayar için doğrulamadan varsaymayın; sysctl -a çıktısı ad alanı içinde host'takinden farklı olabilir.
- Saldırı olmadan bu ayarların çalıştığını nasıl test ederim?
- Test ortamında kendi trafiğinizle. hping3 ile SYN hızını, ab veya wrk ile yeni bağlantı hızını kademeli artırın; her kademede nstat -az, conntrack -C ve ss -s çıktısını okuyun. Aradığınız şey, hangi hızda hangi sayacın kımıldadığıdır; o hız sizin gerçek eşiğinizdir, datasheet değeri değil. Üretimde ise aynı sayaçların taban değerinden ayrılması izleme sisteminize bağlanacak ilk alarmdır.
Yayım: Ağustos 2026
Bu rehber, üreticiler yeni modeller ve fiyatlandırma açıkladıkça güncellenir. Üreticileri nasıl karşılaştırıyoruz