SYN Protector Rulebase Usage
IDP SYN Protector Rulebase SYN floods If you know that your network is vulnerable to a SYN-flood, use the SYN-Protector Rulebase to prevent it.
The SYN-Protector rulebase is a terminal Rulebase; when IDP finds a match on a rule, succeeding rules are not executed.
The SYN-Protector Rulebase protects your network from SYN-floods by ensuring that the three-way handshake is performed successfully for specified TCP traffic.
There are three methods os SYN-flood protection: non, relay, and passive
Creating a SYN-Protector Rule Use the following guidelines when creating a SYN-protector rule: - Source and Destination IP. To detect incoming interactive traffic, set the Source IP to any, and the Destination IP to the Network Object you want to protect from SYN floods. - Service. Select one or more TCP Service Objects. The default service, TCP-any, looks for SYN floods in all TCP-based traffic. - Mode. The mode indicates how IDP handles TCP traffic. Select one of the following three modes:
- None. IDP takes no action, and does not involve itself in the three-way handshake.
- Relay. IDP acts as the middleman, or relay, for the connection establishment, performing the three-way handshake with the client host on behalf of the server. Relay mode guarantees that the server allocates resources only to connections that are already in an ESTABLISHED state. The relay is transparent to both the client host and the server. IDP receives the initial SYN packet sent by the client host and returns a SYN/ACK packet. If the client host sends an ACK packet, IDP completes the three-way handshake and allows the connection to move to an ESTABLISHED state. If IDP does not receive an ACK packet from the client host, as would be the case during a SYN flood attack, IDP does not complete the three-way handshake and the connection is not established. - Passive. IDP handles the transfer of packets between the client host and the server, but does not actively prevent the connection from being established. Instead, IDP uses a timer to ensure that connections are established promptly, minimizing the use of server resources. The timer IDP uses for the connection establishment is shorter than the timer the server uses for the connection queue. IDP transfers the SYN packet sent by the client host to the server, then transfers the SYN/ACK packet sent by the server to the client host. If the client host sends an ACK packet to the server before the IDP connection timer expires, the connection is established. If the client host does not send an ACK packet to the server, as would be the case during a SYN flood attack, the IDP connection timer expires. IDP resets the connection to free resources on the server.
Here is the problem or goal:
Problem Environment:
Additional Information:
SYN-Floods Attackers initiate a SYN-flood by manipulating the basic three-way handshake: 1. A client host sends a SYN packet to a specific port on the server. However, the attacker ensures that the client host's IP address is a spoofed IP address of an unreachable system. 2. Next, the server sends the client host (spoofed address) a SYN/ACK packet. The potential connection is now in a SYN_RECV state. 3. Since the system is unreachable, the server never receives an ACK or RST packet back from the client host. The potential connection is now in the SYN_RECV state, and is placed into a connection queue while it waits for an ACK or RST packet. This potential connection remains in the queue until the connection-establishment timer expires (when it will be deleted). 4. The attacker sends another SYN packet to the server, requesting another connection. And then another. And another. The connection table fills to capacity and cannot accept new SYN requests. The server is overwhelmed, and quickly becomes disabled.
Applicable Products: