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

# sk180505 - Report from a port scanner software shows that the Security Gateway accepts FTP connections

| Property | Value |
|----------|-------|
| Solution ID | sk180505 |
| Date Created | 2023-06-13 |
| Last Modified | 2025-07-16 |
| Technical Level | General |
| Products | Security Gateway |
| Versions | R81.20, R81.10 (EOS), R81 (EOS) |
| OS | Gaia |

## Symptoms

- Report from a port scanner software shows that the Security Gateway accepts FTP connections.

## Cause

The **in.aftpd**daemon is running and handles the FTP connections from the port scanner.

The FWD process is listening to the incoming traffic and spawns the applicable Security Server processes. The FWD process communicates with the Security Server processes using high port numbers. However, these ports are not synchronized between all CoreXL Firewall instances in the "`auth_services_real_ports`" table.

If a CoreXL SND instance forwards the port scanner traffic to a CoreXL Firewall instance that is not synchronized correctly, then this CoreXL Firewall instance handles this traffic as external.

**Example outputs before the port scan:**

As we can see, there are no FTP processes:

```
[Expert@MyGW:0]# ps aux | grep -i ftp
admin    149116  0.0  0.0   2644   580 pts/2    S+   13:42   0:00 grep --color=auto -i ftp
[Expert@MyGW:0]#
```

**Example outputs during the port scan:**

As we can see, the IN.AFTPD is running and listening on the ports 21 and 45000:

```
[Expert@MyGW:0]# ps aux | grep -i ftp
admin    149791  2.5  0.0 336684 48448 ?        Sl   13:44   0:00 in.aftpd 21 45000
[Expert@MyGW:0]#
```

As we can see, the FWD process is listening in on port 45000:

```
[Expert@MyGW:0]# netstat -anp | grep ":45000"
tcp        0      0 0.0.0.0:45000               0.0.0.0:*                   LISTEN      102517/fwd
tcp        0      0 192.168.1.72:45000          192.168.1.16:57154          TIME_WAIT   -
[Expert@MyGW:0]#
```

## Solution

This problem was fixed. The fix is included in:

* [Jumbo Hotfix Accumulator for R81.20](https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.20/Default.htm) starting from Take 43
* [Jumbo Hotfix Accumulator for R81.10](https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.10/Default.htm) starting from Take 113
* [Jumbo Hotfix Accumulator for R81](https://sc1.checkpoint.com/documents/Jumbo_HFA/R81/Default.htm) starting from Take 89
* [Jumbo Hotfix Accumulator for R80.40](https://sc1.checkpoint.com/documents/Jumbo_HFA/R80.40/Default.htm) starting from Take 211

**Important Note** : This fix contains **two**parts:

1. A Hotfix package for the Management Server.
2. A Hotfix package for the Security Gateway / Cluster.

**Important Note:** Only Management side of fix is included in JHF. You must have management side installed before installing the Security gateway fix. If not it will cause issues. Gateway side is PRHF-38231 and will not be included in **ANY** R81.xx JHFs. Both sides of the fix are included in R82.  

<br />

If it is not possible to install the Hotfixes, these workarounds are available:

* Permanent workaround - Prevent the spawning of the in.aftpd process:

  **Critical Note** - This step effectively prevents FTP traffic inspection in these Software Blades: Anti-Virus, Anti-Bot, Data Loss Prevention.
  > 1. Connect to the command line on the Security Gateway / each Cluster Member.
  > 2. Log into the Expert mode.
  > 3. Back up the current `fwauthd.conf` file:  
  >    `cp -v $FWDIR/conf/fwauthd.conf{,_BKP}`
  > 4. Edit the current `fwauthd.conf` file:  
  >    `vi $FWDIR/conf/fwauthd.conf`
  > 5. Comment out the line for the in.aftpd process:  
  >    Before
  >
  >    ```
  >    21              fwssd       in.aftpd        wait    0
  >    80      fwssd       in.ahttpd       wait    -8
  >    513     fwssd       in.arlogind     wait    0
  >    25              fwssd       in.asmtpd       wait    0
  >    ```
  >
  >    After
  >
  >    ```
  >    #21              fwssd       in.aftpd        wait    0
  >    80      fwssd       in.ahttpd       wait    -8
  >    513     fwssd       in.arlogind     wait    0
  >    25              fwssd       in.asmtpd       wait    0
  >    ```
  >
  > 6. Save the changes and exit the Vi editor.
  > 7. Restart Check Point services:  
  >    `cpstop ; cpstart`   
  >    **Important**- In a cluster, this can cause a failover.
* Temporary workaround - Install the Access Control policy:

  > In SmartConsole, install the Access Control Policy on this Security Gateway / Cluster object.
* Temporary workaround - Restart Check Point services:

  > 1. Connect to the command line on the Security Gateway / each Cluster Member.
  > 2. Restart Check Point services:  
  >    `cpstop ; cpstart`   
  >    **Important**- In a cluster, this can cause a failover. In the ClusterXL High Availability Mode, start with the Standby Members.
* Temporary workaround - Reboot:

  > 1. Connect to the command line on the Security Gateway / each Cluster Member.
  > 2. Restart Check Point services:  
  >    `cpstop ; cpstart`   
  >    **Important**- In a cluster, this can cause a failover. In the ClusterXL High Availability Mode, start with the Standby Members.

**Additional Notes** :  

If the issue persists after you install the fix:   

The `fwd `process is permitted to open ports for internal functions such as Data Loss Prevention (DLP), Security Server communication, and other internal services. When the Security Gateway opens ports for its own use, this is part of normal system behavior and reflects how the `fwd `architecture operates.  

When FTP traffic is blocked, the port scanner does not show `aftpd `in a LISTEN state.  

When FTP is allowed in the rulebase:  

* From the external side, no LISTEN state is observed in netstat.
* From the internal side, aftpd is in a LISTEN state.

This behavior is due to port folding, a mechanism where the system dynamically opens a listening socket in anticipation of relevant traffic.  

To clarify, the presence of a LISTEN port on the internal interface does not imply that the port is open or accessible from the external interface. The folding behavior occurs internally only, and the port is not exposed externally or reachable from outside the Gateway.  

This is a expected behavior by design for Scalable Chassis Environment. The system is functioning as expected, no fix is required.

---

# 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
