Windows Networking Troubleshooting 8: Brief Analysis of Windows SynAttackProtection Mechanism
Recently, a Syn Flood Attack caused connection problems for some application services on Windows servers, which caused some doubts as to whether Windows could withstand Syn Flood Attacks. Due to the “good” closure of Windows, the official documents were vague and did not give a clear introduction for this issue. Therefore, we have carefully studied the SynAttackProtection Implementation driven by tcpip.sys on Windows Server 2008 R2.
Note: If you do not know much about SynAttackProtection, you are recommended to review the reference materials first.
SynAttackProtection is briefly described in the documentation of Microsoft:
1.From Windows Vista, SynAttackProtection is enabled by default and cannot be turned off.
2.The threshold of SynAttack is dynamically adjusted based on the CPU/Memory.
3.The Windows server administrator can only know whether SynAttackProtection is enabled when the server encounters Syn Attack, by opening TCPIP ETL trace in advance, stopping the trace afterwards, and then analyzing it.
Generally, the system that is providing services will not initiatively start the TCPIP ETL trace in advance without knowing it. Once a problem occurs, we can only capture a Memory Dump, and try to find the key information in the Dump through the complete Public Symbol provided by Microsoft.
The easiest way to find the information is to display the function names and global variables of the relevant drivers through the windbg/kd x command. Through the Syn Attack keyword, we can easily find it.
Furthermore, we can use Live Debug to attach the Windows Debugger to the Kernel Debug virtual machine interface of Windows Server 2008 R2, and use the ba SynRcvdLimit method to set the memory read breakpoint, so that we can easily obtain the entire call stack and the key Kernel functions.
Static Data Analysis
Finally, static analysis is performed on these key functions.
The intermediate analysis process is complex, but it is nothing more than constantly analyzing the logic of the entire function using the three methods above.
In the Microsoft Blog, it is mentioned that the Windows system starts dropping new connection attempts after entering the “attack state”. It looks rough, but whether the description is correct or not remains to be discussed.
According to our current analysis:
1.When the Windows system starts up, the system calculates SynRcvdLimit according to the memory and the number of CPUs in the system. This variable determines the time when the operating system recognizes that SynAttack is occurring. The minimum value is 256 and the maximum value is 4096.
2.The TcpCheckSynRcvdLimit function of the system determines whether SynAttackInProgress is set by computing the SynReceivedCount of the two-tuple “hash partition”. Judgment rules
a.The current accumulated SynReceivedCount is greater than 3 times the SynRcvdLimit.
b.The current accumulated SynReceivedCount is greater than SynRcvdLimit, and SynRetransmitionCount is greater than 1/2 of SynRcvdLimit.
3.When SynAttackInProgress is not 0, the system recognizes that it has been attacked by the Syn Flood, thereby adjusting the logic for creating TCP_ENDPOINT to prevent resources from being consumed in large quantities.
a.Under normal circumstances, after receiving the SYN request, the system calls TcpCreateAndAcceptTcb to create TCP_ENDPOINT and allocates all required resources, such as Receive Buffer.
b.When SynAttackInProgress takes effect, TcpCreateSynTcb is called to create a SYN_TCB structure to temporarily store the SYN requests from clients, such as some Options fields in the SYN packet. However, at this time, TCP_ENDPOINT is not created and the memory required by the buffer is not prepared. It is similar to the SynCookie, but does not rely on constructing a special ACKNOWLEDGE NUMBER.
4.When SynAttackInProgress takes effect, all these special SynTcbs are retransmitted and revoked quickly. The basic principle is to decide whether to shorten the SYN retransmission time according to SynDropRate:
a.If a Syn Drop exists, Initial RTO is shortened, thus the retransmission time is greatly reduced.
b.If no Syn Drop exists, the SYN_ACK is still retransmitted according to the Initial RTO time and Max SYN Retransmissions configuration.
Note: The Initial RTO and Max SYN Retransmissions are available through “netsh interface tcp show global”. On Windows Server 2008 R2, the default Max SYN Retransmissions = 2. If the corresponding patch is not installed, users cannot configure the Max SYN Retransmissions.
Hotfix enables the configuration of the TCP maximum SYN retransmission amount in Windows 7 or Windows Server 2008 R2https://support.microsoft.com/en-us/help/2786464/hotfix-enables-the-configuration-of-the-tcp-maximum-syn-retransmission
The minimum value of the Max SYN Retransmissions is 2, and the maximum value is 8.
5.After entering the SynAttackInProgress state, the system periodically checks whether it is necessary to exit SynAttackProtection.
a.The current accumulated SynReceivedCount is less than 2 times the SynRcvdLimit. At the same time, SynRetransmitionCount is less than 3/8 of SynRcvdLimit.
b.The current accumulated SynReceivedCount is less than 1/2 of SynRcvdLimit.
Therefore, from the current analysis, SynAttackProtection will not actively discard SYN requests, but similar to SynCookie, it exchanges time for available memory space at a lower cost to avoid situations, such as the system not responding, due to insufficient resources. At the same time, SynAttackProtection accelerates the recovery of resources according to the situation to ensure the normal service request.
As for how SynDropRate is judged and how SynRcvdLimit is determined, you can dig and discover for yourself.
For the description by MS on Windows SynAttackProtection, only the following articles may be available:
- Syn attack protection on Windows Vista, Windows 2008, Windows 7, Windows 2008 R2, Windows 8/8.1, Windows 2012 and Windows 2012 R2
- TCP/IP Stack hardening in Operating Systems starting with Windows Vista
- Azure DDoS Protection Standard overview
- Description of some registry values prior to Windows 2003 server
- Syn Cookies mechanism of Linux
Although at present, the Windows operating system has not adopted this method to defend against Syn Flood.