Passive FTP Behind a Static NAT and a Strict ACL
Cobalt Freight runs an FTP server at 10.10.5.20 in a DMZ, statically NATed to 203.0.113.20 on the internet-facing router R-EDGE. A new partner must pull daily shipment files from it. The security team wrote this ACL and applied it inbound on R-EDGE's WAN interface:
permit tcp any host 203.0.113.20 eq 21
permit tcp any host 203.0.113.20 eq 20
deny ip any any log
The partner can log in successfully, but directory listings hang until they time out. The partner's client is configured for passive mode. Nothing else in the DMZ is reachable from outside. The inside network sits behind a stateful firewall that was not consulted. The auditor has flagged plaintext FTP from the internet as unacceptable and wants a migration plan by Friday.
1. Explain why authentication succeeds while the listing fails, covering the roles of port 21, port 20 and passive mode.
Read the worked answer
Port 21 is the control channel. It carries the login, the commands and the server's replies, and the ACL permits it - hence a successful login and a working USER/PASS exchange.
Passive mode changes who opens the data connection. The client sends PASV on the control channel; the server opens a random high port and answers with 227 Entering Passive Mode (h1,h2,h3,h4,p1,p2). The client then makes an outbound connection to that address and port. That new connection arrives at R-EDGE on a port the ACL does not permit, so it is dropped and the client waits for a data channel that never establishes - the listing hangs.
Port 20 is only used in active mode, where the server connects from source port 20 to a port the client nominated. The second ACL line therefore does nothing for a passive client. It also does not help in active mode, because the permit is for traffic to the server on port 20 rather than from it. In short: the ACL was written for a mode the partner is not using.
2. Give a minimal remediation and a preferred architectural remediation, including the NAT problem that a passive FTP fix must also solve.
Read the worked answer
NAT problem first, because it bites even after the ACL is fixed. The server builds its 227 reply from its own IP address, which is 10.10.5.20. Unless the NAT device rewrites the payload of that reply (an FTP ALG) or the server is configured with an external address, the partner receives a private IP and tries to connect to an unroutable address. So opening ports alone is not sufficient.
Minimal fix:
- Configure the FTP server with a narrow passive port range, for example 50000-50010, and set its advertised external address to 203.0.113.20.
- Permit exactly that range inbound to host 203.0.113.20 in the ACL, and delete the misleading port-20 line.
- Restrict the source to the partner's known IP ranges rather than
any. Trade-off: still plaintext, still credentials in the clear, still a wide-ish port opening.
Preferred fix: retire FTP. Stand up SFTP (TCP 22) or explicit FTPS on a single port, terminate on a hardened DMZ host with key-based authentication and a source-IP allowlist. One port, encrypted, no PASV problem and nothing for an ALG to rewrite.
3. The auditor wants plaintext FTP off the internet. Describe the end state and the migration path that does not break the partner.
Read the worked answer
End state:
- No plaintext FTP listener reachable from the internet; the service is disabled on 10.10.5.20.
- SFTP or FTPS in the DMZ on a single port, with an ACL that permits only the partner's documented source ranges.
- Key-based or certificate authentication for the partner account, no shared passwords, no anonymous access.
- Logging of every login and transfer to the SIEM, with an alert on authentication failures and on unexpected source addresses.
- File integrity checking (hash comparison) so the partner can prove what they received.
- The WAN ACL ends with an explicit deny and logging, and both the stateful firewall and R-EDGE are documented as a single rule set rather than two half-rules.
Migration path:
- Build the SFTP service alongside FTP and test from a lab host on the partner's address range.
- Issue credentials, run both services in parallel for two weeks, and confirm the partner's automated job completes over the new channel.
- Agree a cutover date, then remove the FTP ACL lines and disable the daemon.
- Verify afterwards by scanning the external address: only the intended port responds.