Firewall_tcpView
Firewall Settings > Flood Protection
The Firewall Settings > Flood Protection page lets you view statistics on TCP Traffic through the security appliance and manage TCP traffic settings. The page is divided into four sections
The TCP Settings section allows you to:
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.
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 SonicWALL. The default value is 5 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.
Default value: 8 seconds
Minimum value: 1 second
Maximum value: 60 seconds
SYN/RST/FIN Flood protection helps to protect hosts behind the SonicWALL from Denial of Service (DoS) or Distributed DoS attacks that attempt to consume the host’s available resources by creating one of the following attack mechanisms:
Sending TCP SYN packets, RST packets, or FIN packets with invalid or spoofed IP addresses.
Creating excessive numbers of half-opened TCP connections.
The following sections detail some SYN Flood protection methods:
SYN Flood Protection Using Stateless Cookies
The method of SYN flood protection employed starting with SonicOS uses stateless SYN Cookies, which increase reliability of SYN Flood detection, and also improves overall resource utilization on the SonicWALL. With stateless SYN Cookies, the SonicWALL does not have to maintain state on half-opened connections. Instead, it uses a cryptographic calculation (rather than randomness) to arrive at SEQr.
Layer-Specific SYN Flood Protection Methods
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.
To provide a firewall defense to both attack scenarios, SonicOS provides two separate SYN Flood protection mechanisms on two different layers. Each gathers and displays SYN Flood statistics and generates log messages for significant SYN Flood events.
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.
The thresholds for logging, SYN Proxy, and SYN Blacklisting are all compared to the hit count values when determining if a log message or state change is necessary. When a SYN Flood attack occurs, the number of pending half-open connections from the device forwarding the attacking packets increases substantially because of the spoofed connection attempts. When you set the attack thresholds correctly, normal traffic flow produces few attack warnings, but the same thresholds detect and deflect attacks before they result in serious network degradation.
A typical TCP handshake (simplified) begins with an initiator sending a TCP SYN packet with a 32-bit sequence (SEQi) number. The responder then sends a SYN/ACK packet acknowledging the received sequence by sending an ACK equal to SEQi+1 and a random, 32-bit sequence number (SEQr). The responder also maintains state awaiting an ACK from the initiator. The initiator’s ACK packet should contain the next sequence (SEQi+1) along with an acknowledgment of the sequence it received from the responder (by sending an ACK equal to SEQr+1). The exchange looks as follows:
Initiator -> SYN (SEQi=0001234567, ACKi=0) -> Responder
Initiator <- SYN/ACK (SEQr=3987654321, ACKr=0001234568) <- Responder
Initiator -> ACK (SEQi=0001234568, ACKi=3987654322) -> Responder
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 SonicWALL 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.
Configuring Layer 3 SYN Flood Protection
To configure SYN Flood Protection features, go to the Layer 3 SYN Flood Protection - SYN Proxy portion of the Firewall Settings > Flood Protection window that appears as shown in the following figure.
A SYN Flood Protection mode is the level of protection that you can select to defend against half-opened TCP sessions and high-frequency SYN packet transmissions. This feature enables you to set three different levels of SYN Flood Protection:
Watch and Report Possible SYN Floods – This option enables the device to monitor SYN traffic on all interfaces on the device and to log suspected SYN flood activity that exceeds a packet count threshold. The feature does not turn on the SYN Proxy on the device so the device forwards the TCP three-way handshake without modification. This is the least invasive level of SYN Flood protection. Select this option if your network is not in a high risk environment.
Proxy WAN Client Connections When Attack is Suspected – This option enables the device to enable the SYN Proxy feature on WAN interfaces when the number of incomplete connection attempts per second surpasses a specified threshold. This method ensures the device continues to process valid traffic during the attack and that performance does not degrade. Proxy mode remains enabled until all WAN SYN flood attacks stop occurring or until the device blacklists all of them using the SYN Blacklisting feature. This is the intermediate level of SYN Flood protection. Select this option if your network experiences SYN Flood attacks from internal or external sources.
Always Proxy WAN Client Connections – This option sets the device to always use SYN Proxy. This method blocks all spoofed SYN packets from passing through the device. Note that this is an extreme security measure and directs the device to respond to port scans on all TCP ports because the SYN Proxy feature forces the device to respond to all TCP SYN connection attempts. This can degrade performance and can generate a false positive. Select this option only if your network is in a high risk environment.
Configuring SYN Attack Threshold
The SYN Attack Threshold configuration options provide limits for SYN Flood activity before the device drops packets. The device gathers statistics on WAN TCP connections, keeping track of the maximum and average maximum and incomplete WAN connections per second. Out of these statistics, the device suggests a value for the SYN flood threshold. Note the two options in the section:
Suggested value calculated from gathered statistics – The suggested attack threshold based on WAN TCP connection statistics.
Attack Threshold (Incomplete Connection Attempts/Second) – Enables you to set the threshold for the number of incomplete connection attempts per second before the device drops packets at any value between 5 and 999,999.
Configuring SYN Proxy Options
When the device applies a SYN Proxy to a TCP connection, it responds to the initial SYN packet with a manufactured SYN/ACK reply, waiting for the ACK in response before forwarding the connection request to the server. Devices attacking with SYN Flood packets do not respond to the SYN/ACK reply. The firewall identifies them by their lack of this type of response and blocks their spoofed connection attempts. SYN Proxy forces the firewall to manufacture a SYN/ACK response without knowing how the server will respond to the TCP options normally provided on SYN/ACK packets.
To provide more control over the options sent to WAN clients when in SYN Proxy mode, you can configure the following two objects:
SACK (Selective Acknowledgment) – This parameter controls whether or not Selective ACK is enabled. With SACK enabled, a packet or series of packets can be dropped, and the received informs the sender which data has been received and where holes may exist in the data.
MSS (Minimum Segment Size) – This sets the threshold for the size of TCP segments, preventing a segment that is too large to be sent to the targeted server. For example, if the server is an IPsec gateway, it may need to limit the MSS it received to provide space for IPsec headers when tunneling traffic. The firewall cannot predict the MSS value sent to the server when it responds to the SYN manufactured packet during the proxy sequence. Being able to control the size of a segment, enables you to control the manufactured MSS value sent to WAN clients.
The SYN Proxy Threshold region contains the following options:
All LAN/DMZ servers support the TCP SACK option – This checkbox enables Selective ACK where a packet can be dropped and the receiving device indicates which packets it received. Enable this checkbox only when you know that all servers covered by the firewall accessed from the WAN support the SACK option.
Limit MSS sent to WAN clients (when connections are proxied) – Enables you to enter the maximum Minimum Segment Size value. If you specify an override value for the default of 1460, this indicates that a segment of that size or smaller will be sent to the client in the SYN/ACK cookie. Setting this value too low can decrease performance when the SYN Proxy is always enabled. Setting this value too high can break connections if the server responds with a smaller MSS value.
Maximum TCP MSS sent to WAN clients. The value of the MSS. The default is 1460.
Note When using Proxy WAN client connections, remember to set these options conservatively since they only affect connections when a SYN Flood takes place. This ensures that legitimate connections can proceed during an attack.
Always log SYN packets received. Logs all SYN packets received.
Configuring Layer 2 SYN/RST/FIN Flood Protection
The SYN/RST/FIN Blacklisting feature is a list that contains devices that exceeded the SYN, RST, and FIN Blacklist attack threshold. The firewall device drops packets sent from blacklisted devices early in the packet evaluation process, enabling the firewall to handle greater amounts of these packets, providing a defense against attacks originating on local networks while also providing second-tier protection for WAN networks.
Devices cannot occur on the SYN/RST/FIN Blacklist and watchlist simultaneously. With blacklisting enabled, the firewall removes devices exceeding the blacklist threshold from the watchlist and places them on the blacklist. Conversely, when the firewall removes a device from the blacklist, it places it back on the watchlist. Any device whose MAC address has been placed on the blacklist will be removed from it approximately three seconds after the flood emanating from that device has ended.
The SYN/RST/FIN Blacklisting region contains the following options:
Threshold for SYN/RST/FIN flood blacklisting (SYNs / Sec) – The maximum number of SYN, RST, and FIN packets allowed per second. The default is 1,000. This value should be larger than the SYN Proxy threshold value because blacklisting attempts to thwart more vigorous local attacks or severe attacks from a WAN network.
Enable SYN/RST/FIN flood blacklisting on all interfaces – This checkbox enables the blacklisting feature on all interfaces on the firewall.
Never blacklist WAN machines – This checkbox ensures that systems on the WAN are never added to the SYN Blacklist. This option is recommended as leaving it unchecked may interrupt traffic to and from the firewall’s WAN ports.
Always allow SonicWALL management traffic – This checkbox causes IP traffic from a blacklisted device targeting the firewall’s WAN IP addresses to not be filtered. This allows management traffic, and routing protocols to maintain connectivity through a blacklisted device.
Default UDP Connection Timeout (seconds) - Enter the number of seconds of idle time you want to allow before UDP connections time out. This value is overridden by the UDP Connection timeout you set for individual rules.
UDP Flood Attacks are a type of denial-of-service (DoS) attack. They are initiated by sending a large number of UDP packets to random ports on a remote host. As a result, the victimized system’s resources will be consumed with handling the attacking packets, which eventually causes the system to be unreachable by other clients.
SonicWALL UDP Flood Protection defends against these attacks by using a “watch and block” method. The appliance monitors UDP traffic to a specified destination. If the rate of UDP packets per second exceeds the allowed threshold for a specified duration of time, the appliance drops subsequent UDP packets to protect against a flood attack.
UDP packets that are DNS query or responses to or from a DNS server configured by the appliance are allowed to pass, regardless of the state of UDP Flood Protection.
The following settings configure UDP Flood Protection:
Enable UDP Flood Protection – Enables UDP Flood Protection.
UDP Flood Attack Threshold (UDP Packets / Sec) – The rate of UDP packets per second sent to a host, range or subnet that triggers UDP Flood Protection.
UDP Flood Attack Blocking Time (Sec) – After the appliance detects the rate of UDP packets exceeding the attack threshold for this duration of time, UDP Flood Protection is activated, and the appliance will begin dropping subsequent UDP packets.
UDP Flood Attack Protected Destination List – The destination address object or address group that will be protected from UDP Flood Attack.
ICMP Flood Protection functions identically to UDP Flood Protection, except it monitors for ICMP Flood Attacks. The only difference is that there are no DNS queries that are allowed to bypass ICMP Flood Protection.
The following settings configure ICMP Flood Protection:
Enable ICMP Flood Protection – Enables ICMP Flood Protection.
ICMP Flood Attack Threshold (ICMP Packets / Sec) – The rate of ICMP packets per second sent to a host, range or subnet that triggers ICMP Flood Protection.
ICMP Flood Attack Blocking Time (Sec) – After the appliance detects the rate of ICMP packets exceeding the attack threshold for this duration of time, ICMP Flood Protection is activated, and the appliance will begin dropping subsequent ICMP packets.
ICMP Flood Attack Protected Destination List – The destination address object or address group that will be protected from ICMP Flood Attack.
The Firewall > Flood Protection page provides the following traffic statistics:
The TCP Traffic Statistics table provides statistics on the following:
Connections Opened – Incremented when a TCP connection initiator sends a SYN, or a TCP connection responder receives a SYN.
Connections Closed – Incremented when a TCP connection is closed when both the initiator and the responder have sent a FIN and received an ACK.
Connections Refused – Incremented when a RST is encountered, and the responder is in a SYN_RCVD state.
Connections Aborted – Incremented when a RST is encountered, and the responder is in some state other than SYN_RCVD.
Total TCP Packets – Incremented with every processed TCP packet.
Validated Packets Passed – Incremented under the following conditions:
When a TCP packet passes checksum validation (while TCP checksum validation is enabled).
When a valid SYN packet is encountered (while SYN Flood protection is enabled).
When a SYN Cookie is successfully validated on a packet with the ACK flag set (while SYN Flood protection is enabled).
Malformed Packets Dropped - Incremented under the following conditions:
When TCP checksum fails validation (while TCP checksum validation is enabled).
When the TCP SACK Permitted (Selective Acknowledgement, see RFC1072) option is encountered, but the calculated option length is incorrect.
When the TCP MSS (Maximum Segment Size) option is encountered, but the calculated option length is incorrect.
When the TCP SACK option data is calculated to be either less than the minimum of 6 bytes, or modulo incongruent to the block size of 4 bytes.
When the TCP option length is determined to be invalid.
When the TCP header length is calculated to be less than the minimum of 20 bytes.
When the TCP header length is calculated to be greater than the packet’s data length.
Invalid Flag Packets Dropped - Incremented under the following conditions:
When a non-SYN packet is received that cannot be located in the connection-cache (while SYN Flood protection is disabled).
When a packet with flags other than SYN, RST+ACK or SYN+ACK is received during session establishment (while SYN Flood protection is enabled).
TCP XMAS Scan will be logged if the packet has FIN, URG, and PSH flags set.
TCP FIN Scan will be logged if the packet has the FIN flag set.
TCP Null Scan will be logged if the packet has no flags set.
When a new TCP connection initiation is attempted with something other than just the SYN flag set.
When a packet with the SYN flag set is received within an established TCP session.
When a packet without the ACK flag set is received within an established TCP session.
Invalid Sequence Packets Dropped – Incremented under the following conditions:
When a packet within an established connection is received where the sequence number is less than the connection’s oldest unacknowledged sequence.
When a packet within an established connection is received where the sequence number is greater than the connection’s oldest unacknowledged sequence + the connection’s last advertised window size.
Invalid Acknowledgement Packets Dropped –Incremented under the following conditions:
When a packet is received with the ACK flag set, and with neither the RST or SYN flags set, but the SYN Cookie is determined to be invalid (while SYN Flood protection is enabled).
When a packet’s ACK value (adjusted by the sequence number randomization offset) is less than the connection’s oldest unacknowledged sequence number.
When a packet’s ACK value (adjusted by the sequence number randomization offset) is greater than the connection’s next expected sequence number.
SYN, RST, and FIN Flood Statistics
You can view SYN, RST and FIN Flood statistics in the lower half of the TCP Traffic Statistics list. The following are SYN Flood statistics.
Max Incomplete WAN Connections / sec – The maximum number of pending embryonic half-open connections recorded since the firewall has been up (or since the last time the TCP statistics were cleared).
Average Incomplete WAN Connections / sec – The average number of pending embryonic half-open connections, based on the total number of samples since bootup (or the last TCP statistics reset).
SYN Floods in Progress – The number of individual forwarding devices that are currently exceeding either SYN Flood threshold.
RST Floods in Progress – The number of individual forwarding devices that are currently exceeding the SYN/RST/FIN flood blacklisting threshold.
FIN Floods in Progress – The number of individual forwarding devices that are currently exceeding the SYN/RST/FIN flood blacklisting threshold.
Total SYN, RST, or FIN Floods Detected – The total number of events in which a forwarding device has exceeded the lower of either the SYN attack threshold or the SYN/RST/FIN flood blacklisting threshold.
TCP Connection SYN-Proxy State (WAN only) – Indicates whether or not Proxy-Mode is currently on the WAN interfaces.
Current SYN-Blacklisted Machines – The number of devices currently on the SYN blacklist.
Current RST-Blacklisted Machines – The number of devices currently on the RST blacklist.
Current FIN-Blacklisted Machines – The number of devices currently on the FIN blacklist.
Total SYN-Blacklisting Events – The total number of instances any device has been placed on the SYN blacklist.
Total RST-Blacklisting Events – The total number of instances any device has been placed on the RST blacklist.
Total FIN-Blacklisting Events – The total number of instances any device has been placed on the FIN blacklist.
Total SYN Blacklist Packets Rejected – The total number of packets dropped because of the SYN blacklist.
Total RST Blacklist Packets Rejected – The total number of packets dropped because of the RST blacklist.
Total FIN Blacklist Packets Rejected – The total number of packets dropped because of the FIN blacklist.
Invalid SYN Flood Cookies Received – The total number of invalid SYN flood cookies received.
The UDP Traffic Statistics table provides statistics on the following:
Connections Opened – Incremented when a UDP connection initiator sends a SYN, or a UDP connection responder receives a SYN.
Connections Closed – Incremented when a UDP connection is closed when both the initiator and the responder have sent a FIN and received an ACK.
Total UDP Packets – Incremented with every processed UDP packet.
Validated Packets Passed – Incremented under the following conditions:
When a UDP packet passes checksum validation (while UDP checksum validation is enabled).
When a valid SYN packet is encountered (while SYN Flood protection is enabled).
When a SYN Cookie is successfully validated on a packet with the ACK flag set (while SYN Flood protection is enabled).
Malformed Packets Dropped - Incremented under the following conditions:
When UDP checksum fails validation (while UDP checksum validation is enabled).
When the UDP SACK Permitted (Selective Acknowledgement, see RFC1072) option is encountered, but the calculated option length is incorrect.
When the UDP MSS (Maximum Segment Size) option is encountered, but the calculated option length is incorrect.
When the UDP SACK option data is calculated to be either less than the minimum of 6 bytes, or modulo incongruent to the block size of 4 bytes.
When the UDP option length is determined to be invalid.
When the UDP header length is calculated to be less than the minimum of 20 bytes.
When the UDP header length is calculated to be greater than the packet’s data length.
UDP Floods In Progress – The number of individual forwarding devices that are currently exceeding the UDP Flood Attack Threshold.
Total UDP Floods Detected – The total number of events in which a forwarding device has exceeded the UDP Flood Attack Threshold.
Total UDP Flood Packets Rejected – The total number of packets dropped because of UDP Flood Attack detection.
The ICMP Traffic Statistics table provides the same categories of information as the “UDP Traffic Statistics” on page 443, except for ICMP Flood Attacks instead of UDP Flood Attacks.