FTP Bounce Attack is reduced by disabling FTP PORT and related proxying features, and by restricting outbound connections from the FTP server. Defenders should also patch or replace legacy FTP services, segment the server from internal targets, and monitor for unexpected third-party connection attempts. If active FTP is not needed, remove it entirely.
How to stop FTP bounce attacks at the protocol and network layers
ftp bounce attack work because legacy FTP features can be abused to make the server open connections to third-party hosts on the attacker’s behalf. The practical fix is to remove that ability entirely where possible, or at minimum shut off PORT and any proxying behaviour so the server cannot be used as a relay.
In modern environments, the safest answer is usually to retire active FTP rather than tune it. If the service must remain, treat outbound connectivity from the FTP host as a controlled exception, not a default capability, and keep the service isolated from internal systems it should never reach.
That isolation point is not just theoretical. A hardened network design should make it difficult for an FTP server to talk to anything except the specific destinations it truly needs, which reduces the usefulness of the server as a pivot point and makes bounce-style abuse much harder to sustain.
What to verify before you assume the server is safe
Start by confirming whether the FTP service still accepts active-mode workflows or exposes features that let the server initiate arbitrary third-party connections. If those capabilities are present, the server remains a potential relay even if it is behind a perimeter firewall.
Check whether the service is still maintained by the vendor or distribution, and whether any known fixes are available for the exact FTP implementation in use. Where a legacy product cannot be safely updated, replacement is usually the better control than continued exposure.
Also verify the server’s egress path. If outbound rules are broad, the attacker does not need full compromise of the host to abuse it as a network probe or relay. A narrow egress policy is one of the most effective containment measures because it limits what the server can be made to contact.
How to detect and contain bounce-style abuse in practice
Look for unexpected connection attempts from the FTP server to hosts that are outside its normal business role. Those attempts often stand out in firewall logs, proxy logs, or flow telemetry because the destination is unusual for an ordinary file transfer service.
Monitoring should focus on outbound destinations, failed or repeated connection attempts, and any pattern that suggests the FTP host is being used to test reachability of internal or external targets. When that behaviour appears, the question is not just whether the FTP service is working, but whether it is being used as an unintended network intermediary.
Where the FTP server sits near sensitive systems, segmentation matters as much as the protocol setting. A server that cannot reach internal targets cannot be leveraged the same way as one with broad east-west access, even if an attacker can still trigger connection attempts.
Risk and Threat Considerations
FTP bounce attacks turn a legitimate server function into an abuse path for scanning, relay, and indirect connection attempts. The main risk is not only data exposure, but also trust abuse, because defenders may mistake server-originated traffic for normal service behaviour until the pattern becomes obvious.
Failure mechanism: If PORT and related proxying features remain enabled, the FTP server can be induced to initiate connections to arbitrary destinations. Broad outbound access and weak segmentation then let the server act as a pivot for probing or reaching systems it should never contact.
Impact: Attackers can use the server to map reachable hosts, assist reconnaissance, or create a stepping stone toward internal targets. Even when the attack does not succeed in exploitation, it can still expand visibility into your network and create noisy but meaningful exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | Bounce attacks are exposed by unusual outbound connection attempts from a server. |
| CIS-12 — Network Infrastructure Management | Segmentation and restricted pathways limit an FTP server's ability to reach internal targets. | |
| Recommendation — Monitor server egress and alert on unexpected third-party connection attempts. Segment the FTP host and restrict east-west reachability to approved systems. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Egress filtering and network boundaries directly constrain bounce-style relay abuse. |
| CM-7 — Least Functionality | Disabling PORT and removing unused FTP capability follows least functionality. | |
| Recommendation — Enforce outbound boundary controls that block unauthorized connections from the FTP server. Disable active FTP features and remove the service when it is not required. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | Network controls and segmentation reduce abuse of the FTP host as a relay. |
| Recommendation — Apply network security controls to constrain the FTP server's permitted communication paths. | ||
Practitioner Guidance
What to prioritise: Remove active FTP if the business does not need it, then disable PORT and any similar server-side proxying behaviour on the remaining estate. That sequence gives the biggest reduction in abuse potential with the least ambiguity.
What to verify: Confirm that the FTP host cannot initiate outbound sessions except to explicitly approved destinations. If the server can reach internal systems, treat that as a separate containment issue, not just an FTP configuration detail.
Common mistake: Teams often patch the FTP daemon but leave the network shape unchanged. That leaves a service that is technically updated but still structurally able to be abused as a relay.
Practitioner takeaway: The right control is usually less about hardening FTP in place and more about removing its ability to originate untrusted connections at all.