Compartir a través de

SharePoint 2007 and General Network Errors

  • Artículo

I observed lately quite a lot of General Network Errors occurring on a few production servers at some customers.
I have been performing some checks on various environments and it looks like these errors are widely distributed among servers in various farms.

Multiple Error entries appear in the Application log of all SharePoint servers of the farms:

The error is raised because the SynAttackProtect registry key has its default value of 1 set up on the SQL server hosting SharePoint ® databases and/or on the SharePoint ® servers in farms

synattackprotect"=dword:00000001

A TCP Synchronize (SYN) attack is a denial-of-service attack that exploits the retransmission and time-out behavior of the Synchronize-Acknowledgement (SYN-ACK) segment during the TCP three-way handshake to create a large number of half-open TCP connections. Depending on the TCP/IP protocol implementation, a large number of half-open TCP connections could do any of the following:

  • Use all available memory.
  • Use all possible entries in the TCP Transmission Control Block (TCB), an internal table used to track TCP connections. Once the half-open connections use all the entries, further connection attempts are responded to with a TCP connection reset.
  • Use all available half-open connections. Once all the half-open connections are used, further connection attempts are responded to with a TCP connection reset.

To create a large number of TCP half-open connections, attackers send a large number of SYN segments, each from a spoofed IP address and TCP port number. Each spoofed IP address and TCP port number are for a process that does not respond to the SYN-ACKs being sent by the attacked host. SYN attacks are typically used to render Internet servers inoperative.

To mitigate the impact on a host experiencing a SYN attack, TCP/IP minimizes the amount of resources devoted to incomplete TCP connections and reduces the amount of time before abandoning half-open connections. When a SYN attack is detected, TCP/IP in Windows Server 2003 and Windows XP lowers the number of retransmissions of the SYN-ACK segment and does not allocate memory or table entry resources for the connection until the TCP three-way handshake has been completed.

You can control SYN attack protection through the SynAttackProtect registry entry at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters (type REG_DWORD). You set SynAttackProtect to 0 to disable SYN attack protection and to 1 to enable it.

For TCP/IP in Windows XP (all versions) and Windows Server 2003 with no service packs installed, SynAttackProtect is set to 0 by default. For TCP/IP in Windows Server 2003 SP1, SynAttackProtect is set to 1 by default.

For more information about TCP connection behavior and related registry entries, see

· Microsoft Windows Server 2003 TCP/IP Implementation Details

· https://technet.microsoft.com/en-us/library/bb878132.aspx

The issue is also extensively described in this blog post: https://blogs.msdn.com/sql_protocols/archive/2006/04/12/574608.aspx

I did not performed in-depth analysis in order to identify the elements that are the causing the packets backlog queue (which is max to 200 by default on w2k3 standard server), to be exhausted.

Depending on the OS version, the default setting for the SynAttackProtect might be different:

OS version

\SynAttackProtect default value

Windows Server 2003 RTM

0

Windows Server 2003 SP1

1

Windows Server 2003 SP2

1

Windows Server 2003 R2

1

The solution for this would be modifying the SynAttackProtect registry key on each server concerned by the issue, playing an active SharePoint ® role or a role in the general connectivity between servers in SharePoint ® farms.

Microsoft Windows Server 2003 Service Pack 1 and higher implements a security feature that reduces the size of the queue for concurrent TCP/IP connections to the server. This feature helps prevent denial of service attacks. Under heavy load conditions, the TCP/IP protocol in Windows Server 2003 may incorrectly identify valid TCP/IP connections as a denial of service attack. For more information see this

324270: How to harden the TCP/IP stack against denial of service attacks in Windows Server 2003: https://support.microsoft.com/kb/324270

Applications or services connecting to SQL could experience network errors due connection forcibly closed by the OS like "General network error".

Recommendation

On Windows 2003 SP1+ system with high number of TCP connections and/or heavy TCP traffic, set to 0 the registry key value "SynAttackProtect" under “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" as explained in these two KB articles:

A BizTalk Server Host instance fails, and a "General Network" error is written to the Application log when the BizTalk Server-based server processes a high volume of documents

https://support.microsoft.com/?id=899599

910228: SQL Server 2005 Readme and installation requirements

https://support.microsoft.com/kb/910228

There is not a risk of elevation of privileges, remote code execution or any other security risk. It just makes it more subjective to Denial Of Service attacks, which should be handled by perimeter devices such a switches for instance.

Hardening servers only might result in a situation where the customers facing this issues would put a SQL box directly connected to an unsecure network.

Conclusion

  • Set the SynAttackProtect key value to 0 on the affected servers
  • Communicate the issue to the network infrastructure team to ensure this kind of attack is addressed on the “Layer 3” TCP Transport level