Over the past two month we had hard time trouble with Sync attack
We are running windows 2008 R2 server
We have firewall on Linux

When Sync attack start the server blocks all traffic and it takes time for our Linux guy to find IP of attacker and block them. He told us that the Sync attack on our server are not heavy and the server should handle them and we need to do some adjusting.

What we done:
1. increased the number of the Threads per processor limit on IIS from 25 (default) to 50.
2. Reduced SQL server memory allocation to increase the free memory.
3. Reduced the TIME_WAIT by setting the TcpTimedWaitDelay TCP/IP parameter to 30 seconds on the windows registry key HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.
4. Increased the range of ephemeral ports by setting the dynamicportrange to an higher value through the command netsh int ipv4 set dynamicportrange tcp start=32767 num=32768, this set the port range from 32768 to 65535.

Did not help a lot. What else could be done. I have run into some instruction at
https://alnitech.com/2014/06/how-to-protect-your-windows-server-from-syn-flood/

yet not sure whether it will help.

Would apreciate any help

You should use built in windows firewall and logging settings. The logs will tell you the address of all incoming and outgoing requests. You can also view firewall activities in eventviewer : https://technet.microsoft.com/en-us/library/ff428140%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396
From here you will be able to block all the ip addresses with suspicious behavior or ip addresses making requests from unnecessary ports

It is half opened connection and they do not reach the IIS. They are flooding on the TCPIP level and then server blocks all requests

IIS blocking does not help here

• Edited by Viktorka Wednesday, April 22, 2015 5:12 PM

It is half opened connection and they do not reach the IIS. They are flooding on the TCPIP level and then server blocks all requests

IIS blocking does not help here

• Edited by Viktorka Wednesday, April 22, 2015 5:12 PM

Hi VIktorika,

I suppose you're talking about SYN flood attack (not Sync). Windows server has integrated basic protection against such attacks.

Increasing client ports, timed wait or IIS threads will not help. SYN flood attack is on TCP handshake phase (in fact the attacker is sending multiple SYN packets and doesn't finish the 3-way handshake).

Please check the following registry values in HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ registry key:

SynAttackProtect [DWORD] registry value should be 1.

TcpMaxHalfOpen [DWORD] registry value should exists and set to something reasonable (500-1000)

TcpMaxHalfOpenRetried [DWORD] registry value should exists and set to a bit lower value than above.

Also before start modifying registry settings be sure that it's indeed SYN flood attack. It can be checked easily with netstat:

netstat -n -p TCP | find /i "syn"

Check the number of the connections listed. If they are too many, then it's SYN flood attack. Otherwise it's something else. Can you give us some more details what are observing on the server? Probably some netstat statistics (established, fin_wait, syn, time_wait number of connections).

SynAttackProtect, TcpMaxHalfOpen, TcpMaxHalfOpenRetried

Does not have such entries in the registry. Does Win 2008 R2 support it?

Checked netstat - nothing today. there was yesterday and the server was blocking all requests until we blocked the IPs causing it on the firewall level

• Edited by Viktorka Wednesday, April 22, 2015 6:09 PM adding more details

SynAttackProtect, TcpMaxHalfOpen, TcpMaxHalfOpenRetried

Does not have such entries in the registry. Does Win 2008 R2 support it?

Checked netstat - nothing today. there was yesterday and the server was blocking all requests until we blocked the IPs causing it on the firewall level

• Edited by Viktorka Wednesday, April 22, 2015 6:09 PM adding more details

They should be. But even if they don't exists by default from Windows Vista Syn attack protection is always on and cannot be turned off.

You can execute below command to log if SYN protection kicks in:

netsh trace start capture=yes provider=Microsoft-Windows-TCPIP level=0x05 tracefile=TCPIP.etl

Once you detect syn attack you can stop the logging with netsh trace stop and check the log with NetMon 3.4.

Are you sure that the SYN attack didn't broke the Linux firewall? Is there any SYN flood protection configured on this Linux box (with iptables for an example)?

How much time did it take for the server to start serving requests once the IP was blocked - 1,2, 20 minutes?

As per this blog on technet:

:

 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 doesnt 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.

• Edited by VikasRana Wednesday, April 22, 2015 7:46 PM

As per this blog on technet:

:

 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 doesnt 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.

• Edited by VikasRana Wednesday, April 22, 2015 7:46 PM

Are you sure that the SYN attack didn't broke the Linux firewall? Is there any SYN flood protection configured on this Linux box (with iptables for an example)?

How much time did it take for the server to start serving requests once the IP was blocked - 1,2, 20 minutes?

At this point the linux guy checks the traffic and blacklist the IP where SYN attacks comes from. yet, he is telling that the volume is not big and the Windows Server should be able to handle such small attacks.

regarding recovery time, it takes more then 10 minutes for Server to start serving the requests.

I set registry key as you suggested. If they are not supported by system, I think they will be just ignored and there should not be ay harm.

• Edited by Viktorka Wednesday, April 22, 2015 9:42 PM addition

Are you sure that the SYN attack didn't broke the Linux firewall? Is there any SYN flood protection configured on this Linux box (with iptables for an example)?

How much time did it take for the server to start serving requests once the IP was blocked - 1,2, 20 minutes?

At this point the linux guy checks the traffic and blacklist the IP where SYN attacks comes from. yet, he is telling that the volume is not big and the Windows Server should be able to handle such small attacks.

regarding recovery time, it takes more then 10 minutes for Server to start serving the requests.

I set registry key as you suggested. If they are not supported by system, I think they will be just ignored and there should not be ay harm.

• Edited by Viktorka Wednesday, April 22, 2015 9:42 PM addition

Hmm, 10 minutes is a lot. It's a wild guess, but probably you'd too many connections in TIME_WAIT state and not in SYN.

Regarding the SYN attack - I suggest you to implement such protection on the firewall/router. Usually they're the first which are affected and for me is a little strange that the Linux didn't have any problems (note that each connection from outside is terminated on the firewall and a new connection from the firewall to the server is made, so both should be affected).

You can check for existing too many TIME_WAIT connections even now. If you find such please apply https://support.microsoft.com/en-us/kb/2553549?wa=wsignin1.0 hotfix.

Hi Viktorka,

Syn attack protection is enabled by default in Vista/2008 R2 and cannot be disabled. If you are experiencing the attack please contact your firewall vendor for the further help, the following article may help you identify the attack.

Security guidelines to detect and prevent DOS/DDOS attacks targeting Azure Web Role (PAAS) or IIS hosted on Azure VM (IAAS)

http://blogs.msdn.com/b/friis/archive/2014/12/30/security-guidelines-to-detect-and-prevent-dos-attacks-targeting-iis-azure-web-role-paas.aspx

Im glad to be of help to you!