[Last updated: 13th January 2014]
In this blog entry, I wanted to talk about some changes made in Syn attack protection on Windows Vista onwards systems.
Syn attack protection has been in place since Windows 2000 and is enabled by default since Windows 2003/SP1. In the earlier implementation (Windows 2000/Windows 2003), syn attack protection mechanism was configurable via various registry keys (like SynAttackProtect, TcpMaxHalfOpen, TcpMaxHalfOpenRetried, TcpMaxPortsExhausted). With this previous version of syn attack protection, TCPIP stack starts dropping new connection requests when the threshold values are met regardless of how much system memory or CPU power available to the system. As of Windows Vista and onwards (Vista/2008/Win 7/2008 R2/Windows 8/Windows 2012/Windows 2012 R2), syn attack protection algorithm has been changed in the following ways:
1) SynAttack protection is enabled by default and cannot be disabled! 2) SynAttack protection dynamically calculates the thresholds (of when it considers an attack has started) based on the number of CPU cores and memory available and hence it doesn’t expose any configurable parameters via registry, netsh etc. 3) Since TCPIP driver goes into attack state based on the number of CPU cores and the amount of memory available, systems with more resources will start dropping new connection attempts later compared to systems with less resources. That was hard-coded (as per the configured registry settings) on pre-Vista systems where the system was moved to attack state regardless of how much resources were available to the system. The new algorithm eliminates the need of any fine tuning and TCPIP stack will self-tune to best values possible depending on the available resources.
One of the questions asked most about TCP Syn attack protection is how an administrator could identify if a server has moved into attack state. Currently there's no event logged whether or not the system has entered into attack state and started dropping TCP Syn packets on Vista and later systems. The only way of understanding that syn attack protection has kicked in is to collect an ETL trace (and you need start it before the attack starts so that you can see the relevant TCPIP ETL entry).
The command that you need to run is the following from an elevated command prompt (Note: "netsh trace" command only works on Windows 7/Windows 2008 R2 and later systems)
netsh trace start capture=yes provider=Microsoft-Windows-TCPIP level=0x05 tracefile=TCPIP.etl
Once Syn attack starts, the ETL trace could be stopped with the below command:
netsh trace stop
Then you can open it up with Network Monitor 3.4. The ETL entry that you should be looking for is the below one:
Hope this helps
Is Window Server 2008 configurable or fine-tuneable with respect to Syn Attacks?
As I tried to explained in the blog post, there's no configuration for SYN attack protection on Vista onwards systems because the system dynamically does the fine tuning.
Hi - thanks for your answer. It seems pretty strange that Windows 2008 server would not have something to fine-tune for Syn attacks.
Well that's what MS fanboys deserve.
Is there a way to tell if syn attack protection is triggered? event log? We have a large 2008 server that randomly does connection reset when the rate of inbound connections is high. We are trying to find our what limit is being hit.
Do we NOT have to set SynAttackProtect to Windows7?
If we set the SynAttackProtect , is there some problems?
If we cant disable it then what if we want to make tcp cpnnection for any web service for number of times in loop. it's giving connection refused after some time.
Has anyone figured out to get a log of whether this is causing an issue on servers or not on server 2008 (not R2) system?
What kind of filter you can use in Network Monitor in order to get this particular frame?
And you can still take down every server by just using one command: hping3 -S --flood --rand-source -p someport host-ip
Ugly design. It can suffer many admins.
Microsoft again has made an feature which makes the system administrators to hate microsoft...