Capability

FTP Security Proxy

Manage FTP not as an open port, but as a command-by-command controlled secure file transfer session.

The TR7 WAAP FTP security proxy layer brings legacy FTP traffic — currently outside the reach of modern WAAP protection — into the security perimeter. FTP is still in active use across banking, government, healthcare, logistics, manufacturing, EDI and partner file exchange; yet in most environments it is protected by nothing more than an open port and a username/password check. TR7 WAAP treats the FTP session at the application layer: command-level whitelisting, per-user policy, user-based backend selection, FTP bounce and FXP attack mitigation, session timeout, file transfer auditing and SIEM log streaming are all managed within the same policy model. Only permitted commands reach the backend. This layer does not require replacing existing FTP services. Legacy systems keep running; TR7 terminates the session at the front, inspects it, logs it and forwards only what the policy permits to the backend. For FTPS scenarios, TLS termination and certificate management are folded into the same security chain. The result: TR7 removes FTP from an organization's blind spot and brings legacy file transfer flows up to modern WAAP security, per-user control and forensic audit standards.

20+
RFC 959 FTP commands — each individually allow/deny controllable
900 s
Default session timeout — configurable per policy
3
Separate log levels: command, transfer, session

FTP is the blind spot of modern security layers.

FTP is a legacy file transfer protocol that uses separate control and data channels. While modern web and API traffic is protected by tokens, TLS, session policy and WAAP controls, FTP in most organizations still operates at the level of "open port, check username and password." EDI workflows, batch transfers, partner file exchange, mainframe bridges and legacy document systems therefore run outside security visibility.

Traditional network security offers two weak options for FTP. Either port 21 is opened and no one can see which commands pass through, or FTP is removed entirely and a months-long integration project begins. Many legacy systems cannot absorb that transition quickly.

Using FTPS alone is not enough either. Traffic may be encrypted, but the questions remain: which user is running which command, which file is being retrieved or sent, which backend is being accessed, is the data connection coming from the right source, and how long has the session been open.

The protocol design of FTP creates a specific attack surface. The PORT command can direct data connections to third-party addresses, FXP-style server-to-server transfers can be abused, and weak anonymous or shared accounts can remain open for extended periods. These risks are difficult to observe at the network layer; application-level FTP session awareness is required.

The TR7 WAAP FTP security proxy layer operates classic FTP services — without removing them — under command whitelisting, per-user policy, bounce/FXP mitigation, session control and forensic audit.

Our approach

TR7 WAAP treats FTP not as a port-opening decision but as an application session that is authorized per user and audited command by command.

Command-level whitelist passes only permitted operations

FTP commands such as RETR, STOR, DELE, MKD, RMD, LIST, NLST, RNFR, RNTO, SIZE and MDTM are placed on an individual allow/deny list. Unknown commands or commands absent from the policy are rejected by default.

Per-user policy delivers different permissions and targets

The FTP username can be used as a policy key. Different users connecting through the same VIP can operate with different command sets, different timeouts and different backend pools.

Bounce and FXP protection validates the data connection

The source of the data connection is correlated with the control connection. PORT attempts directed at third-party addresses or server-to-server transfer behavior are blocked by default; exceptions are defined by an explicit policy decision.

Forensic audit makes every command and transfer traceable

Every session, command and file transfer is written to the audit log. Monitor mode surfaces the full file path; filecopy mode can store a timestamped copy of each transferred file.

Capabilities

The FTP Security Proxy brings the command, user, data channel, session and audit weaknesses of the classic FTP protocol under the WAAP policy model.

ValidCommands whitelist authorizes FTP commands one by one

TR7 manages standard FTP commands as allow/deny decisions at the policy level. In a read-only role, commands such as RETR, LIST, NLST, SIZE, MDTM and STAT remain open while STOR, DELE, RMD or RNTO can be denied. In an upload role, only STOR and the necessary directory commands are permitted. This ensures that "has FTP access" does not translate into unlimited file permissions.

Per-user policy matching delivers different behavior over the same VIP

The username is read at the login stage and fed into the WAAP policy engine. Two users connecting to the same VIP can operate with different command sets, different session durations, different audit depth and different backend pools. This architecture consolidates partner-, department- or tenant-based file transfers at a single entry point. Operations teams define security boundaries per user.

Per-user backend selection simplifies multi-target FTP

One user can be directed to a specific backend pool while another is routed to a different pool. The client-side `user@server` selection pattern can be used, or TR7 can resolve the user to the appropriate backend through a central table. This eliminates the need to open many separate VIPs for B2B partner FTP, department sharing or tenant separation. Controlled routing happens under a single entry point.

Data port and PORT/PASV behavior is managed under policy

Active and passive FTP modes behave differently with respect to the data connection. TR7 correlates PORT and PASV flows with the session to ensure the data channel is established correctly. The passive port range can be restricted by policy; the source IP toward the backend can be pinned. This reduces transfer failures for FTP services behind NAT and firewalls.

FTP bounce and FXP mitigation blocks third-address data transfers

In FTP bounce attacks the PORT command attempts to direct data connections to a third target. TR7 can reject this behavior by matching the data connection against the real endpoint of the control connection. Server-to-server transfer behavior similar to FXP can be kept off by default. Required exceptions are defined explicitly; a security gap is never the default behavior.

Source IP and geographic access policy applies to FTP sessions

FTP sessions can be evaluated by source IP, country, ASN, time window or user information. Connections from outside specific partner countries or corporate IP ranges can be rejected. This brings the access-control approach used on the web and API side to FTP as well. Legacy file transfer flows are bound to modern access policy.

Session and idle timeout controls bound resource consumption

FTP sessions can stay open for long periods and consume sockets on the backend. TR7 can manage limits such as login timeout, idle timeout and total session duration at the policy level. A default session duration of 900 seconds can be used as a baseline and adjusted as needed. Idle sessions are closed without keeping the backend waiting.

Monitor mode converts relative file paths into full audit records

FTP clients can change directories with CWD and then issue relative file commands. Monitor mode tracks the working directory within the session and logs commands such as `RETR file.csv` with their full file path. The audit record therefore shows not just the command but the actual file location. Post-incident investigation clarifies exactly which file was retrieved or sent.

Filecopy mode stores a timestamped copy of every transferred file

For compliance or forensic needs, a copy of each transferred file can be written to a separate storage area. Files can be kept in a date-based directory structure and correlated with the audit log. This means the question "which file was sent?" can be answered not only with a log entry but with the file itself. Audit evidence is strengthened in regulated sectors.

FTPS termination preserves command visibility alongside encrypted traffic

When FTPS is in use the control channel is encrypted, but commands must be understood to apply security policy. The TR7 WAAP FTP security proxy layer terminates the FTPS session at the security layer and can inspect the commands. Under AUTH TLS, forwarding to the backend can be re-encrypted or adapted to the internal network model. Certificate and TLS policy align with the central management pool.

Operational depth

The FTP Security Proxy is operated together with command processing, data connection lifecycle, HA behavior, audit streaming, resource limits and compliance retention policies.

01

Command processing chain

Every FTP command is received from the control channel, parsed, evaluated against the ValidCommands list and the user policy. A permitted command is forwarded to the backend. A rejected command returns a protocol-compliant error response (502 or 550); the client remains protocol-compliant.

02

Data connection lifecycle

When a PORT or PASV command is seen, TR7 associates the data connection with the session. Separate data connections exist between client and TR7, and between TR7 and the backend. This structure makes it possible to close the session in a controlled way if a policy violation is detected during a transfer.

03

High-availability behavior

New FTP sessions open on the active node with the same policy. Ongoing large data transfers may be interrupted at a failover event due to the nature of the protocol; if the client supports resume, the transfer can be restarted or continued. Critical transfers should therefore be tested for client behavior before production deployment.

04

Audit and SIEM streaming

Separate logs can be produced at the session, command and transfer level. Logs can be sent to the SIEM stream in a structured format. Monitor mode appends the full file path to the log line; filecopy mode appends the location of the stored file copy.

05

Limit and resource management

Concurrent session count, sessions per user, sessions per IP, file size and transfer rate can all be restricted by policy. This prevents a single user or a misbehaving batch job from exhausting FTP infrastructure. Bandwidth and timeout should be planned together for large file transfers.

06

Compliance and auditing

The full path, timestamp, user information and, if required, a file copy of every transferred file can be retained. Retention duration is set according to the organization's compliance policy. During an audit, FTP traffic is no longer a dark area.

When to use it

Segment a B2B partner FTP gateway per user

A financial institution or government agency may exchange EDI files with partners over FTP. TR7 routes each partner behind a single VIP to its own backend pool, opens only the permitted commands and places every transfer under audit.

Add protection in front of a legacy document management system

If a legacy document platform supports only FTP upload, TR7 can be placed in front without touching the system. Policy opens only STOR and the necessary directory commands while rejecting delete and rename commands.

Enforce a read-only policy on a mainframe bridge

In integrations that retrieve files from a mainframe system, the user can be limited to read-only commands such as RETR, LIST and SIZE. STOR, DELE, RNFR, RNTO, MKD and RMD are rejected, reducing the risk of data modification.

Produce file copies and audit evidence for outbound sharing

When a healthcare or research team sends datasets to external partners, every transfer can be retained with filecopy. File size limits, per-user policy and SIEM log streaming make the sharing process auditable end to end.

Frequently asked questions

Which FTP commands can the FTP Security Proxy manage?
More than 20 commands defined in RFC 959 — including RETR, STOR, DELE, MKD, RMD, LIST, NLST, RNFR, RNTO, SIZE, MDTM, STAT, APPE, STOU, CWD and CDUP — can each be individually allowed or denied. Commands absent from the policy are rejected by default. Role profiles such as "read-only," "upload only" or "full control" are defined at the policy level.
Does FTPS traffic not block command visibility?
With FTPS sessions encrypted via AUTH TLS, the control channel is ciphered so commands are not directly visible. The TR7 WAAP FTP security proxy layer terminates the FTPS session at the application layer and inspects the commands; forwarding to the backend is then re-encrypted or adapted to the internal network model. Certificate management is handled from the central pool.
How are FTP bounce and FXP attacks blocked?
Data connections that a PORT command attempts to redirect to a third address are rejected by default; the source of the data connection is matched against the real endpoint of the control connection. FXP-style server-to-server transfer behavior is also kept off by default. Defining an exception requires writing an explicit decision into the policy.
What is the difference between monitor mode and filecopy mode?
Monitor mode tracks the working directory that the FTP client changes with CWD and logs relative commands with their full file path — a `RETR file.csv` command appears in the audit record as `/data/partner/2026/inbox/file.csv`. Filecopy mode stores a timestamped copy of every transferred file in a date-based directory structure. Used together, both full path visibility and a file copy are available.
Can different partners connected to the same VIP reach each other's backend?
No. Per-user policy matching reads the username at the login stage and routes each user only to the backend pool assigned to them. Different command sets, different timeouts and different backend pools are isolated per user under the same VIP. This architecture is designed for B2B partner separation, department isolation and multi-tenant scenarios.
Does the FTP Security Proxy also cover SFTP?
No. This capability covers FTP (RFC 959) and FTPS (TLS-wrapped FTP). SFTP is an SSH-based protocol and is outside the scope of this page.

Bring your FTP traffic under the WAAP security layer

Command whitelisting, per-user policy, bounce/FXP protection and forensic audit. Let us walk you through a live setup on your own FTP infrastructure.