> Source: [sk157112](https://support.checkpoint.com/results/sk/sk157112)

# sk157112 - Gateway responds to TCP connections on unused ports

| Property | Value |
|----------|-------|
| Solution ID | sk157112 |
| Date Created | 2019-07-01 |
| Last Modified | 2025-12-23 |
| Technical Level | General |
| Products | Security Gateway |
| Versions | R82.10, R82, R81.20, R81.10 (EOS) |
| OS | Gaia |

## Symptoms

- * Vulnerability scans show a high number of random ports open on the firewall.
* The Gateway responds to random ports over Telnet.   
  **Note**: IPS is enabled with SYN Defender / Accelerated SYN Defender.

## Solution

This is an expected behavior.

SYN Defender is an IPS protection designed to protect a corporate network from a common DoS attack known as SYN Flooding. It does this by using two different modes to track the behavior of clients and react to suspected malicious activity: **Passive Mode** and **Active Mode**.

### **Passive Mode:**

While in passive mode, SYN Defender counts unestablished connections (i.e., connections that are in SYN or in SYN/ACK state), and if the number of these unestablished connections reaches a specified threshold in a certain amount of time (both threshold and timeout settings are configured via the GUI), SYN Defender moves to Active mode.

When SYN Defender is in passive mode, opening a Telnet connection to a server that is not listening has the expected result. As seen below, the connection times out because Google's servers are not listening on port 777 and the Gateway is not intercepting the traffic.

![](https://sc1.checkpoint.com/sc/SolutionsStatics/NEW_SK_NOID1561755457415/PassiveModeBehavior1906281430.PNG)

### **Active Mode (Relay Mode):**

When the Gateway decides that a server is under attack, it switches to SYN Relay Defense. SYN Relay counters the attack by making sure that the three-way handshake is complete before sending a SYN packet to the connection's destination.

Even if the destination server is not listening on that port, the Gateway will respond with a SYN-ACK to make sure that the client completes the three-way handshake with an ACK; it does this to determine the legitimacy of the connection. After the Gateway has determined that the connection is legitimate, it forwards the packet to the firewall layer and eventually to the destination server. As a result, Telnet connections to servers that are not listening open to a blank screen.

![](https://sc1.checkpoint.com/sc/SolutionsStatics/NEW_SK_NOID1561755457415/ActiveModeBehavior1906281431.PNG)

### **Why "Accelerated SYN Defender" Processes SYN Packets Before the Rule Base in Active Mode (Relay Mode):**

1.

   #### Where SYN Defender Operates

   * **SYN Defender (Accelerated SYN Defender)** is implemented in SecureXL (SXL) starting from R80.20.
   * It is designed to protect against SYN flood attacks by intercepting and validating TCP handshakes.
2.

   #### Packet Flow Order (with SecureXL and SYN Defender)

   * When SecureXL is enabled, the **first component to process the packet is SecureXL**
   * SYN Defender logic is part of SecureXL, so it can act on packets before they reach the full firewall (F2F) path.
   * **The rule base is never bypassed for final access control**. SYN Defender may respond to SYNs, but it does not permit traffic that violates policy.
3.

   #### What Happens to a SYN Packet?

   * If SYN Defender is enabled and the gateway is under attack (Active/Relay mode), SYN Defender will intercept and validate the handshake before the connection is passed to the firewall rule base.
   * Only after the handshake is validated (or the SYN flood threshold is not exceeded) does the connection proceed to the rule base for policy enforcement.
   * **If the rule base does not allow the connection, it will be dropped after handshake validation**.
4.

   #### Implications

   * **SYN Defender may respond to SYN packets on ports that are not allowed by the rule base**.
   * This means the gateway may appear to respond to connection attempts on ports that are not open in the rule base, because SYN Defender is handling the handshake before the rule base is enforced.
   * This is why vulnerability scans may show "open" ports even if the rule base would ultimately drop the connection.
   * However: The connection to the server will not be completed, No application data is ever allowed if the rule base blocks it.
5.

   #### Effective SYN Flood Mitigation

   * **Purpose:** SYN Defender is designed to protect against SYN flood attacks, which attempt to exhaust server resources by sending a large number of half-open TCP connections.
   * **How it Works:** By intercepting and validating the TCP handshake (three-way handshake) before the connection reaches the rule base, SYN Defender can filter out malicious or incomplete connection attempts early, preventing them from consuming firewall and server resources.
6.

   #### Resource Protection

   * **Firewall Load Reduction:** If every SYN packet had to be processed by the full rule base, a SYN flood could overwhelm the firewall's CPU and memory, leading to performance degradation or even denial of service.
   * **Early Filtering:** SYN Defender, operating at the SecureXL (acceleration) layer, can drop or challenge suspicious SYN packets before they reach the more resource-intensive rule base, preserving system performance.
7.

   #### Legitimacy Verification

   * **Handshake Validation:** SYN Defender ensures that only clients who complete the full TCP handshake are allowed to proceed to the rule base. Attackers who do not complete the handshake are filtered out early.
   * **Prevents Resource Exhaustion:** This prevents attackers from filling up the firewall's connection table with half-open connections, which could otherwise block legitimate users.
8.

   #### Adaptive Defense

   * **Active/Relay Mode:** When under attack, SYN Defender can switch to an active mode where it acts as a relay/proxy for the handshake, only forwarding connections that appear legitimate, to be processes by the rule base.
   * **Dynamic Response:** This adaptive approach allows the gateway to respond to changing attack patterns without manual intervention.
9.

   #### Consistent with Industry Best Practices

   * **Layered Security:** Handling SYN flood protection at a lower layer (before the rule base) is a common best practice in network security, as it offloads attack mitigation from the main firewall engine.

Additional Information:  

* R82 Performance Tuning Administration Guide \> [Accelerated SYN Defender](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_PerformanceTuning_AdminGuide/Content/Topics-PTG/SecureXL-Accelerated-SYN-Defender.htm?TocPath=SecureXL%7C_____9)
* [sk120476: Important changes in the IPS "SYN Attack" (SYN Defender) protection](https://support.checkpoint.com/results/sk/sk120476)
* [sk112241: Best Practices - DDoS attacks on Check Point Security Gateway](https://support.checkpoint.com/results/sk/sk112241)

---

# Agent Instructions

This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products.

## Navigating This Knowledge Base

- **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt)
- **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml)
- **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}`
- **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content