Windows Server DDoS Sıkılaştırma: Neyi Ayarlarsınız, Neyi İşletim Sistemi Zaten Halleder

Bu rehber, Windows Server host’unun kendisini, önünde herhangi bir cihaz olmadan, bir DDoS saldırısının durum ve istek tüketen kısmına karşı sertleştirmekle ilgilidir. Çoğu Windows rehberine göre kayıt defteri düzenlemesi tarafında bilerek daha kısadır, ve bunun tek bir sebebi vardır. Düzenlemelerin çoğu eskimiştir, uygulanması ise işe yaramamaktan zararlı olmaya kadar uzanır.

Windows DDoS sıkılaştırması hakkında bilinmeye değer en önemli şey, ne yapılmayacağıdır. Eski rehberleri dolduran kayıt defteri anahtarları SynAttackProtect, TcpMaxHalfOpen, TcpMaxHalfOpenRetried ve sabitlenmiş bir TcpWindowSize ya Windows Server 2003’ten sonra kaldırıldı ya da autotuning tarafından ezildi. Bunları yazmak en iyi ihtimalle hiçbir şey yapmaz. Bir pencere boyutunu sabitlemek ise yığının bağlantı başına ayarlamasını fiilen bozar.

Cihaz	Eski tavsiye (uygulamayın)	Neden geçersiz	Yerine ne yapılır
SynAttackProtect	Kayıt defterinde SynAttackProtect=2 yapın	Server 2003'ten sonra kaldırıldı; SYN koruması otomatiktir	netstat ile doğrulayın; gerekirse WFP'de oran sınırlayın
TcpMaxHalfOpen	Kayıt defterinde yarı açık bağlantıyı sınırlayın	Yığın bu değeri artık okumaz	Get-NetTCPConnection -State SynReceived ile gözleyin
TCP alım penceresi	TcpWindowSize değerini sabitleyin	Vista/2008'den beri autotuning bağlantı başına boyutlar	Set-NetTCPSetting şablonu kullanın, sabitlemeyin
Bağlantı sınırları	İşletim sistemi varsayılanına güvenin	Varsayılan cömerttir; kaynak başına hiçbir sınır yoktur	Kaynak adres başına WFP filtresi veya güvenlik duvarı kuralı

Soldaki sütunun tamamı internetin biriktirdiği Windows 2003 folklorudur. Modern yığın çoğunu otomatikleştirdi. Kaldırılmış anahtarları yazmak hiçbir işe yaramaz, birkaç sabit değer ise autotuning'i ezerek durumu kötüleştirir.

0. Önce temel ölçüler: değiştirmeden önce sayaçları okuyun

Windows kendi durumunu /proc yerine performans sayaçları ve Get-Net* cmdlet’leri üzerinden gösterir. Normal bir haftayı şunlardan kaydedin:

# TCP durumuna göre bağlantı sayısı (SynReceived satırı yarı açık backlog'unuzdur)
Get-NetTCPConnection | Group-Object -Property State | Sort-Object Count -Descending

# TCP yığını sayaçları: segment, reset, başarısız bağlantı
Get-Counter '\TCPv4\*' -SampleInterval 5 -MaxSamples 3

# Etkin bağlantı şablonu ve autotuning düzeyi
Get-NetTCPSetting -SettingName Internet | Format-List *

# Adaptör RSS durumu ve kuyruk sayısı
Get-NetAdapterRss | Format-Table Name, Enabled, NumberOfReceiveQueues

Bu çıktıyı saklayın. Aşağıdaki her yargı ona görelidir. “SynReceived sayısı yüksek” ancak normal hafta rakamına göre bir anlam taşır.

1. TCP yığını: kayıt defteri anahtarları değil, şablonlar

Modern Windows Server eski skaler TCP kayıt defteri değerlerini ayar yüzeyi olarak sunmaz. Bunun yerine bağlantı türü başına bir şablon uygular, ve siz şablonu ayarlarsınız. Şablonlar Internet, Datacenter, Datacenter Custom, Internet Custom ve Compat’tır.

# Etkin şablonun uyguladığı her ayarı gör
Get-NetTCPSetting -SettingName Internet

# Autotuning alım penceresi — ölçülmüş bir sebep olmadıkça 'normal'de bırakın
Set-NetTCPSetting -SettingName InternetCustom -AutoTuningLevelLocal Normal

# Autotuning'in eski bir sıkılaştırma betiğiyle kapatılmadığını doğrula (sık bir bulgu)
Get-NetTCPSetting | Format-Table SettingName, AutoTuningLevelLocal
netsh int tcp show global

Denetlenen bir Windows sunucusundaki en yaygın gerçek sorun eksik bir ayar değildir. Sorun, autotuning’i netsh int tcp set global autotuninglevel=disabled ile kapatmış eski bir sıkılaştırma betiğidir. O tek satır alım penceresini küçük sabit bir değerde tutar ve her meşru bağlantıyı boğar. Yeniden açmak genelde tek başına en büyük iyileşmedir:

netsh int tcp set global autotuninglevel=normal

SYN seli koruması zaten otomatiktir ve desteklenen bir işletim sisteminde kayıt defterinden anlamlı biçimde iyileştirilemez. Onu yapılandırmaz, baş edip etmediğini doğrularsınız:

# Şu andaki yarı açık bağlantılar
(Get-NetTCPConnection -State SynReceived).Count

# Başarısız bağlantı denemeleri ve reset'ler, yığın sayaçlarından
Get-Counter '\TCPv4\Connection Failures','\TCPv4\Connections Reset'

Bir olay sırasında SynReceived sayısı on binlere doğru tırmanıyorsa cevap bir kayıt defteri anahtarı değildir. Cevap, aşağıda ele alınan WFP katmanında ya da bir üst katmanda kaynak başına bir sınırdır.

2. Windows Filtering Platform: kaynak başına sınırın yaşadığı yer

Linux kaynak başına oran sınırlamasını bir nftables dinamik kümesiyle yapar. Windows karşılığı Windows Filtering Platform içinde yaşar, ve çoğu operatör için onun erişilebilir yüzü bir güvenlik duvarı kuralıdır. nftables’ınki kadar temiz, yerleşik bir “kaynak başına saniyede N bağlantı” öğesi yoktur. Bu yüzden uygulamadaki kalıp, izlemeyle sürülen kapsamlı bir engelleme ile açık yüzeyi küçülten bağlantı güvenliği kurallarıdır.

# Belirli bir kötücül kaynağı engelle (otomatik bir yanıtlayıcının çağıracağı şey)
New-NetFirewallRule -DisplayName "DDoS-block-203.0.113.0/24" -Direction Inbound `
  -RemoteAddress 203.0.113.0/24 -Action Block

# Bir servisi yalnızca ona erişmesi gereken adreslere kısıtla — saldırı yüzeyinde
# tek seferde en büyük azalma, ve hiçbir oran mantığı gerektirmez
New-NetFirewallRule -DisplayName "RDP-restrict" -Direction Inbound -Protocol TCP `
  -LocalPort 3389 -RemoteAddress 10.0.0.0/8 -Action Allow

# Gerçekte neyin etkin olduğunu incele
Get-NetFirewallRule -Enabled True -Direction Inbound |
  Where-Object Action -eq Allow | Format-Table DisplayName, Profile

Dürüst sınır şudur. Windows güvenlik duvarı tek başına, nftables kümesinin yaptığı gibi kaynak başına yeni bağlantıyı oran sınırlamaz. Bunun gerektiği yerde çözüm bir WFP callout sürücüsünden, üçüncü taraf bir katmandan, ya da her ölçekte gerçek cevap olan host’un önündeki şebeke katmanından gelir. Güvenlik duvarının DDoS dayanıklılığına en güçlü katkısı oran sınırlama değildir. Katkısı yüzey azaltmadır, yani her dinleyen portun yalnızca olması gereken yerden erişilebilir olmasını sağlamaktır.

İnternete bakmak zorunda olan servisler için bağlantı güvenliği (IPsec) kuralları, bir bağlantı uygulama kaynağı tüketmeden önce kimlik doğrulaması isteyebilir. Bu, anonim bir seli daha ucuz bir katmanda bir kimlik doğrulama hatasına çevirir:

Get-NetIPsecRule | Format-Table DisplayName, Enabled, Profile

3. http.sys: IIS’in önündeki çekirdek istek kuyruğu

Herhangi bir HTTP iş yükü için bir istek selinin çarptığı ilk kuyruk IIS değildir. O kuyruk http.sys’tir, yani HTTP isteklerini bir işçi süreci görmeden önce kabul edip kuyruğa alan çekirdek modundaki sürücüdür. Parametreleri HTTP servisi altında yaşar, ve kuyruğu IIS’in yapılandırdığı her şeyden ayrı bir kaynaktır.

# Çekirdek istek kuyrukları ve derinlikleri
Get-Counter '\HTTP Service Request Queues(*)\CurrentQueueSize'
Get-Counter '\HTTP Service Request Queues(*)\RejectedRequests'

Anlaşılması gereken temel davranışlar istek kuyruğu uzunluğu, bağlantı zaman aşımı ve başlık bekleme zaman aşımıdır. Bir sayaç aksini kanıtlamadıkça çoğunlukla varsayılanda bırakılırlar. Başlık bekleme zaman aşımı, yavaş başlık saldırılarına (bir bağlantı açıp başlıkları bayt bayt gönderme) karşı http.sys düzeyindeki savunmadır. Sürücü, başlıklarını zaman aşımı içinde tamamlamayan bir bağlantıyı, IIS ona bir işçi ayırmadan önce düşürür.

IIS tarafındaki ayarlar (uygulama havuzu kuyruk uzunluğu, dinamik IP kısıtlamaları, istek filtreleme) ayrı bir katmandır ve kendi IIS sıkılaştırma rehberine sahiptir. Buradaki nokta, http.sys’in IIS’in altındaki kuyruk olduğudur. Bir site işçi doygunken ayakta kalabilir, çünkü http.sys emmektedir; ya da işçi boş görünürken çökebilir, çünkü http.sys reddetmektedir.

4. Receive Side Scaling: paket hızı savunması

Hat dolmadan önce, yüksek bir paket hızı bir işlemci çekirdeğini kesme işlerken yüzde yüze sabitlerken diğerleri boş durabilir. Windows’ta çözüm, gelen paket işlemeyi çekirdekler arasında dağıtan Receive Side Scaling’dir. Fiziksel NIC’lerde genelde açıktır. Sanallaştırılmış NIC’lerde ise sık sık kapalı ya da yetersiz kuyrukludur, ve bir Windows sanal makinesinin nominal bant genişliğinin çok altında bir paket hızı saldırısına sessizce yenilmesi tam o varsayılanda olur.

# RSS açık mı, kaç kuyruk var?
Get-NetAdapterRss -Name * | Format-Table Name, Enabled, NumberOfReceiveQueues, MaxProcessors

# Etkinleştir ve yeterli kuyruk ver (mevcut çekirdeklere göre)
Enable-NetAdapterRss -Name "Ethernet"
Set-NetAdapterRss -Name "Ethernet" -NumberOfReceiveQueues 8

# Test sırasında işlemci başına kesme yükünü izle — tek sıcak çekirdek RSS dağıtmıyor demektir
Get-Counter '\Processor(*)\% Interrupt Time' -SampleInterval 2 -MaxSamples 5

# Receive Segment Coalescing çıktıyı artırabilir ama gecikmeye duyarlı iş yükünü bozabilir; ölç
Get-NetAdapterRsc | Format-Table Name, IPv4Enabled, IPv6Enabled

Yük altında tek sıcak çekirdek, gerisi boşken, RSS’in işini yapmadığının imzasıdır. Bu, Linux’un softnet_stat çıktısındaki üçüncü sütunun tırmanmasının birebir Windows karşılığıdır.

5. Uygulama katmanı bağlantı davranışı

İki host düzeyi öğe, üstteki web sunucusu ne olursa olsun onu destekler. TCP keep-alive ölü bağlantıları sezip geri alır, ve dinamik port aralığı host’un ne kadar giden/efemer bağlantı sürdürebileceğini belirler:

# Efemer port aralığı — host çok sayıda giden bağlantı yapıyorsa genişletin
netsh int ipv4 show dynamicport tcp
netsh int ipv4 set dynamicport tcp start=1024 num=64511

# TCP keep-alive bağlantı başına bir yığın ayarıdır; şablon onu taşır
Get-NetTCPSetting -SettingName Internet | Select-Object SettingName, *KeepAlive*

Yavaş bağlantı saldırıları nihayetinde işletim sistemiyle değil, web sunucusunun kendi zaman aşımlarıyla cevaplanır. Bunlar IIS için IIS rehberinde, Windows üzerinde nginx ya da Apache çalıştırıyorsanız o rehberlerde yaşar.

İzlemeye bağlanacak sayaçlar

Windows sıkılaştırması da Linux gibi hissedilmez, sayaçtan okunur. Şunları izleme sistemine bağlayın:

# Bir yanıtlayıcının çağırabileceği tek seferlik sağlık okuması
Get-Counter @(
  '\TCPv4\Connection Failures',
  '\TCPv4\Connections Reset',
  '\HTTP Service Request Queues(_Total)\CurrentQueueSize',
  '\HTTP Service Request Queues(_Total)\RejectedRequests',
  '\Processor(_Total)\% Interrupt Time'
) -SampleInterval 5 -MaxSamples 1

# Yarı açık backlog tek bir sayı olarak
(Get-NetTCPConnection -State SynReceived).Count

Bunlar, bir saldırı sırasında Linux sayaçlarının cevapladığı soruyu cevaplar. Host mu daralıyor, hat mı doluyor?

Bu katmanın dürüst sınırı

Yukarıdaki her şey tek cümleye iner. Bir Windows Server, kendi bağlantı tablolarını, istek kuyruklarını ve çekirdek başına işlemesini tüketen saldırılara karşı savunulabilir. Bunun dışında iki durum vardır ve ikisi de host’ta çözülmez.

Birincisi hat doluluğudur. Erişim hattını aşan hacim Windows yığınına hiç ulaşmaz, ve hiçbir şablon, güvenlik duvarı kuralı ya da RSS kuyruğu bunu değiştirmez.

İkincisi, iyi dağıtılmış çekirdeklerin bile işleyebileceğinin ötesindeki paket hızıdır. RSS bu tavanı yükseltir ama kaldırmaz. Bu iki eşiğin üstünde konu sunucu değil, şebeke mimarisidir. Host sıkılaştırması sunucuyu bir üst katman devreye girene kadar ayakta tutar, ama o katman değildir, ve onu öyle saymak yanlış güven üretir.

Uygulama sırası

1. Temel ölçüleri kaydedin (Bölüm 0): duruma göre bağlantılar, TCP sayaçları, şablon, RSS durumu.
2. Autotuning’in eski bir betikle kapatılmadığını doğrulayın; kapalıysa açın. En yaygın tek kazanç budur.
3. Güvenlik duvarı yüzeyini azaltın: her dinleyen port yalnızca olması gereken yerden erişilebilir olsun.
4. RSS’in açık ve yeterli kuyruklu olduğunu doğrulayın, özellikle sanallaştırılmış NIC’lerde.
5. Bir sayaç belirli bir darboğazı kanıtlamadıkça http.sys’i ve TCP şablonunu varsayılanda bırakın.
6. Sayaçları izleme sistemine alarm olarak bağlayın.

Bu listede eksik olana dikkat edin: uzun bir kayıt defteri bölümü. Desteklenen bir Windows Server’da o bölüm, yirmi yıl önce yazılmış bir rehberin işaretidir.