FTP Illegal PORT command

Question

I've set up proftpd to use ssl/tls. Trying to connect I get an 'Illegal PORT command'

Finding Host xxx.nl ...
Connecting to xxx.xxx.xxx.xxx:21
Connected to xxx.xxx.xxx.xxx:21 in 0.018001 seconds, Waiting for Server 
Response
Initializing SSL Session ...
220 FTP Server ready.
AUTH TLS
234 AUTH TLS successful
SSL session NOT set for reuse
SSL Session Started.
Host type (1): AUTO
USER xxx
331 Password required for xxx
PASS (hidden)
230 User xxx logged in
SYST
215 UNIX Type: L8
Host type (2): Unix (Standard)
PBSZ 0
200 PBSZ 0 successful
PROT P
200 Protection set to Private
PWD
257 "/" is the current directory
CWD /var/www/html/
250 CWD command successful
PWD257 "/var/www/html/" is the current directory
TYPE A
200 Type set to A
PORT 192,168,192,14,211,181
500 Illegal PORT command
Port failed 500 Illegal PORT command
PASV
227 Entering Passive Mode (xxx,xxx,xxx,xxx,160,151).
connecting data channel to xxx.xxx.xxx.xxx:160,151(41111)
Failed to connect data channel to xxx.xxx.xxx.xxx:160,151(41111)

iptables:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     icmp --  anywhere             anywhere            /* 000 accept all icmp */
ACCEPT     all  --  anywhere             anywhere            /* 001 accept all to lo interface */
REJECT     all  --  anywhere             loopback/8          /* 002 reject local traffic not on loopback interface */ reject-with icmp-port-unreachable
ACCEPT     all  --  anywhere             anywhere            /* 003 accept all to eth1 interface */
ACCEPT     all  --  anywhere             anywhere            /* 004 accept related established rules */ state RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere            multiport ports ftp /* 021 allow ftp. */
ACCEPT     tcp  --  anywhere             anywhere            multiport ports ssh /* 022 allow ssh. */
ACCEPT     tcp  --  anywhere             anywhere            multiport ports smtp /* 025 allow smtp. */
ACCEPT     tcp  --  anywhere             anywhere            multiport ports pharos /* 051 allow rundeck. */
ACCEPT     tcp  --  anywhere             anywhere            multiport ports 8140 /* 814 allow puppetserver. */
ACCEPT     tcp  --  anywhere             anywhere            multiport ports http /* 080 allow http. */
ACCEPT     tcp  --  anywhere             anywhere            multiport ports https /* 443 allow https. */
DROP       all  --  anywhere             anywhere            /* 999 drop all */

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Connecting via normal ftp works just fine...

I'm using WS_FTP with ftp-authssl//xxx.nl/.... I tried several other connection options, ports, etc. But all give the same error. Althoiugh it seems that sometimes a first directory listing is shown (but that might be caching of WS_FTP)

Solution 1

I posted the question also on SuperUser and got the answer there: I've added the following to the proftpd.conf:

PassivePorts 49152 65534
TLSOptions NoSessionReuseRequired

For PassivePorts see http://proftpd.org/docs/directives/linked/config_ref_PassivePorts.html

For TLSOptions see http://www.proftpd.org/docs/howto/TLS.html (based on some log messages from WS_FTP I figured out that NoSessionReuseRequired should help).

Solution 2

First note that the two final commands, PORT and PASV, have nothing to do with each other. They're two independent connection attempts (one for active FTP, one for passive FTP).

---

So, your PORT failure is expected.

The way PORT works (the "active FTP" mode) is by having the client send its own address to the server – the server connects back to you for data transfer.

According to the logs, your client computer is behind a NAT and has a "private" IP address. That's the only address it knows, so that's what it sends with the PORT command.

Usually, your router would recognize an FTP connection and sneakily edit the PORT command, replacing your private address with the router's own public one. (Or, if you're unlucky, it would replace it with garbage.)

However, since your control connection is now encrypted using TLS, the router cannot perform this fixup (all it sees is encrypted data), and the server receives exactly what your client sends: your private address.

Since the server is on another network, it cannot possibly reach a private address (that's the whole point of NAT). Although it doesn't even bother trying – for security reasons, most servers just immediately refuse any address that doesn't exactly match where the control connection came from.

tl;dr Switch your FTP client to passive mode. Yes, your logs show passive mode (PASV) being broken as well. But at least it's somewhat fixable if your server has a dedicated public IP address, whereas active mode is not.

---

What about PASV? Well, the problem is similar.

Usually, your server's firewall would snoop on the FTP control connection, extract the temporary port from the "Entering passive mode (x,y,z…)" reply, and mark it as belonging to a "RELATED" connection. Then your rule #004 would allow it.

However, again, iptables cannot see through TLS (all it sees is encrypted data) and can no longer recognize your FTP data connections as related. So your connection just hits rule #999 and is dropped.

To make PASV work, you will need to configure ProFTPd to use a specific range of passive ports (doesn't matter what range exactly), and tell iptables to allow connections to those ports.

Solution 3

PORT 192,168,192,14,211,181

This command means that the client is listening on the IP address 192.168.192.14 port 54197 for the data connection from the server. 192.168.*.* are private IP addresses which can not be routed over the internet. This means that this IP address can not reachable from a server on the internet. And this why the server considers the PORT command invalid.

Comments

[Frank Thomas]

PORT 192,168,192,14,211,181 translates to tcp://192.168.192.141:54197 which is a valid port, but may be in use. securitypronews.com/understanding-the-ftp-port-command-2003-‌​09

[user1686]

@FrankThomas: That's normal – it's supposed to be a random port allocated by the FTP client just for this one transfer. (If the client hadn't successfully bound to it, it would have tried another one.)

[user1686]

General tip: If you suspect the firewall might be related, get some feedback from it. iptables keeps packet counters for every rule, and is capable of logging and tracing.

[Avis]

Patrick - I am getting the same issues. Did you solve this problem? if yes could you please share?

[Patrick]

Yes, got it solved, see my own answer to my question.

[Mokubai]

Your question from Stack Overflow was moved here and merged. In future please do not cross post questions on multiple sites.

[user1686]

People like to use this as an argument that FTP is garbage and should be avoided. They're not wrong, but personally I'd rather say NAT is garbage and should be avoided...

[Frank Thomas]

I can't agree with you on NAT. we wouldn't have simple consumer-configured routers in every home without it, and NAT + SPF does provide unsophisticated home users a significant degree of protection without significant work. It should be only sophisticated users that have every computer on a publically addressable IP, so they can put 100% of their trust in their own skills. doing otherwise endangers the web ecosystem on a grand scale. besides, we can always say that the issues with NAT are actually that we want to keep doing things with TCP paradigms, and not reinvent. Just my two bits.

[user1686]

Sure we would have -- if ISPs had instead pushed forward protocols with proper addressing, like IPv6/IPng/etc.

[Frank Thomas]

IPv6 exacerbates the issue of direct connections to systems with no business being directly publicly accessible; it does not diminish it.

[A.B]

Some clients (like the extremely powerful lftp, not available on windows except cygwin AFAIK) have options to choose the ip and port(s range) to send (in lftp with set ftp:port-ipv4 and set ftp:port-range). With some synchronization with the firewall rules (including some protection using the recent match) it should be possible in this case to use PORT with TLS. But this will be limited to a "privileged" client, it won't be automatic for everybody

[Patrick]

(Sorry for the delay) I've configured ProFTPd and iptables: PassivePorts 49152 65534 Illegal PORT command still shows up, but then continues with PASV ` PASV 227 Entering Passive Mode (xxx,xxx,xxx,xxx,226,92). connecting data channel to xxx.xxx.xxx.xxx:226,92(57948) data channel connected to xxx.xxx.xxx.xxx:226,92(57948) LIST -la 150 Opening ASCII mode data connection for file list 425 Unable to build data connection: Operation not permitted`

[Patrick]

Had to add TLSOptions NoSessionReuseRequired to ProFTPd and it worked!

[SomeDude]

Your post was migrated; this is now redundant.