The Firewall Settings > Flood Protection page lets you view statistics on TCP Traffic through the security appliance and manage TCP traffic settings.
|
•
|
Enforce strict TCP compliance with RFC 793 and RFC 1122 – Select to ensure strict compliance with several TCP timeout rules. This setting maximizes TCP security, but it may cause problems with the Window Scaling feature for Windows Vista users.
|
|
•
|
Enable TCP handshake enforcement – Require a successful three-way TCP handshake for all TCP connections.
|
|
•
|
Enable TCP checksum enforcement – If an invalid TCP checksum is calculated, the packet will be dropped.
|
|
•
|
Enable TCP handshake timeout – The timeout period (in seconds) for a three-way TCP handshake to complete its connection. If the three-way TCP handshake does not complete in the timeout period, it is dropped.
|
|
•
|
Default TCP Connection Timeout – The default time assigned to Access Rules for TCP traffic. If a TCP session is active for a period in excess of this setting, the TCP connection will be cleared by the firewall. The default value is 15 minutes, the minimum value is 1 minute, and the maximum value is 999 minutes. Note: Setting excessively long connection time-outs will slow the reclamation of stale resources, and in extreme cases could lead to exhaustion of the connection cache.
|
|
•
|
Maximum Segment Lifetime (seconds) – Determines the number of seconds that any TCP packet is valid before it expires. This setting is also used to determine the amount of time (calculated as twice the Maximum Segment Lifetime, or 2MSL) that an actively closed TCP connection remains in the TIME_WAIT state to ensure that the proper FIN / ACK exchange has occurred to cleanly close the TCP connection.
|
SonicOS provides several protections against SYN Floods generated from two different environments: trusted (internal) or untrusted (external) networks. Attacks from untrusted WAN networks usually occur on one or more servers protected by the firewall. Attacks from the trusted LAN networks occur as a result of a virus infection inside one or more of the trusted networks, generating attacks on one or more local or remote hosts.
|
•
|
SYN Proxy (Layer 3) – This mechanism shields servers inside the trusted network from WAN-based SYN flood attacks, using a SYN Proxy implementation to verify the WAN clients before forwarding their connection requests to the protected server. You can enable SYN Proxy only on WAN interfaces.
|
|
•
|
SYN Blacklisting (Layer 2) – This mechanism blocks specific devices from generating or forwarding SYN flood attacks. You can enable SYN Blacklisting on any interface.
|
The internal architecture of both SYN Flood protection mechanisms is based on a single list of Ethernet addresses that are the most active devices sending initial SYN packets to the firewall. This list is called a SYN watchlist. Because this list contains Ethernet addresses, the device tracks all SYN traffic based on the address of the device forwarding the SYN packet, without considering the IP source or destination address.
Each watchlist entry contains a value called a hit count. The hit count value increments when the device receives the an initial SYN packet from a corresponding device. The hit count decrements when the TCP three-way handshake completes. The hit count for any particular device generally equals the number of half-open connections pending since the last time the device reset the hit count. The device default for resetting a hit count is once a second.
Because the responder has to maintain state on all half-opened TCP connections, it is possible for memory depletion to occur if SYNs come in faster than they can be processed or cleared by the responder. A half-opened TCP connection did not transition to an established state through the completion of the three-way handshake. When the firewall is between the initiator and the responder, it effectively becomes the responder, brokering, or proxying, the TCP connection to the actual responder (private host) it is protecting.