İçeriğe geç

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

Üç iç içe duvarla çevrili bir yapı: dışarıdan gelen amber püskürtünün çoğu ilk duvarda, kalanı ikincide sönüyor; en içteki avlu sakin ve yeşil ışıkla aydınlık.

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.

Tükenebilir kaynaklar ve doğrulama komutları
CihazKaynakBelirtiDoğrulama komutu
SYN / accept kuyruğuYeni bağlantılar sessizce zaman aşımına düşernstat -az | grep -i listen
conntrack tablosudmesg: 'nf_conntrack: table full, dropping packet'conntrack -C; conntrack -S
Dosya tanıtıcılarıaccept() EMFILE; port dinliyor ama kabul yokcat /proc/<pid>/limits; cat /proc/net/sockstat
TIME_WAIT / orphan soketEfemer 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 kaybedernetstat -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.

Yerinde katmanın yardımcı olamadığı sınır 10 Gbps erişim hattınız Hat zaten doymuş — yalnızca yukarı akış Yerinde cihaz azaltır 2 Gbps 8 Gbps 25 Gbps 120 Gbps 1 Tbps+ Saldırı hacmi (logaritmik ölçek)
Hat kapasitesinin altında host katmanının payı vardır; üstünde hiçbir sysctl ayarının anlamı kalmaz.

İ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ı

  1. Temel ölçüleri kaydedin (Bölüm 0). Bir hafta sabır ister; en pahalı adım budur.
  2. 90-ddos.conf dosyasını yazın, sysctl --system ile yükleyin, grep ile doğrulayın.
  3. Uygulama backlog’unu (listen ... backlog=) somaxconn ile hizalayın.
  4. Servis birimlerine LimitNOFILE drop-in’i ekleyin, systemctl show ile doğrulayın.
  5. conntrack boyut/ömrünü ayarlayın; durumsuz servisleri notrack ile tablo dışına alın.
  6. nftables oran sınırını önce counter modunda bir hafta çalıştırın, sonra drop’a çevirin.
  7. 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