Make Firewall rules for Passive FTP which uses dynamic port

firewallftpiptableslinuxnetworking

The following two rules allow for passive transfers which i added as Firewall rules for my FTP server.

//The following two rules allow the inbound FTP connection
iptables -A INPUT -s $hostIP -p tcp --dport 21 -i eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -d $hostIP -p tcp --sport 21 -o eth0 -m state --state ESTABLISHED -j ACCEPT

// The following two rules allow for passive transfers
iptables -A INPUT -s $hostIP -p tcp --dport 1024:65535 -i eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -d $hostIP  -p tcp --sport 1024:65535 -o eth0 -m state --state ESTABLISHED -j ACCEPT

My FTP was server configured by assigning passive port to range "1024:65535" and above rules worked. But now FTP server configured to bind any free port instead fix port range. So what changes required in above two rules?

Edit
After applying three rules for passive FTP connection mentioned in answer i have rules in following order and now it's stopped working means client is connected but unable to retrieve remote directory.

//The following two rules allow the inbound FTP connection
iptables -A INPUT -s $hostIP -p tcp --dport 21 -i eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -d $hostIP -p tcp --sport 21 -o eth0 -m state --state ESTABLISHED -j ACCEPT

iptables  -A PREROUTING -t raw -p tcp -s $hostIP --dport 21 -j CT --helper ftp
iptables  -A INPUT -m conntrack --ctstate RELATED -m helper --helper ftp -s $hostIP -p tcp -j ACCEPT
iptables  -A OUTPUT -m conntrack --ctstate ESTABLISHED -m helper --helper ftp -d $hostIP -p tcp -j ACCEPT

Working Rules

iptables -A PREROUTING -t raw -p tcp -s $hostIP --dport 21 -j CT --helper ftp
iptables -A INPUT  -i eth0 -p tcp -s $hostIP -m conntrack --ctstate RELATED,ESTABLISHED -m helper --helper ftp -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -d $hostIP -m conntrack --ctstate ESTABLISHED -m helper --helper ftp -j ACCEPT

Best Answer

I assume $hostIP in your rules means a host you wish to allow FTP access for, otherwise your existing rules won't make sense to me.

If you are using unencrypted FTP, you should replace your wide-open FTP data connection rules with connection tracking.

First, add a rule that attaches a FTP connection tracking helper to any incoming FTP command connections:

iptables -A PREROUTING -t raw -p tcp -s $hostIP --dport $ftpCMDport -d $ftpServerIP -j CT --helper ftp

Here, $ftpCMDport is the port in which your local FTP server accepts logins; usually it's port 21.

(Historical note: this used to happen automatically for TCP port 21, but it turned out the automatic assignment could be abused, so the automatic assignment of connection tracking helpers was made optional in Linux kernel 3.5, and later the automatic assignment feature was completely removed.)

Once the FTP command connections are being monitored by the CT helper, the firewall will "know" which ports should be allowed for legitimate FTP data connections. You'll need two more rules to actually use this information to allow incoming data connections:

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -m helper \
   --helper ftp -s $hostIP -d $ftpServerIP -p tcp -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -m helper \
   --helper ftp -s $ftpServerIP -d $hostIP -p tcp -j ACCEPT

Together, these three rules should entirely replace your existing two rules for FTP data connections. These should be good for both active and passive connections, should your FTP server allow both types. If you only want to accept passive FTP data connections, you might want to remove the RELATED in the OUTPUT rule.

This was based on: https://home.regit.org/netfilter-en/secure-use-of-helpers/

If you are using SSL/TLS encrypted FTP, then the connection tracking helper won't be able to make sense of the encrypted FTP command traffic, and so if the FTP server will accept data connections in any free port, you cannot effectively firewall traffic by TCP ports at all, since any TCP port could become a FTP data port for some connection. Your only possibility would then be to limit traffic by IP addresses:

iptables -A INPUT -s $hostIP -p tcp -i eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -d $hostIP  -p tcp -o eth0 -m state --state ESTABLISHED -j ACCEPT

Note that these are essentially your existing rules, with the --dport and --sport options removed.

Related Solutions

Linux – Iptables: matching outgoing traffic with conntrack and owner. Works with strange drops

To cut a long story short, that ACK was sent when the socket didn't belong to anybody. Instead of allowing packets that pertain to a socket that belongs to user x, allow packets that pertain to a connection that was initiated by a socket from user x.

The longer story.

To understand the issue, it helps to understand how wget and HTTP requests work in general.

wget http://cachefly.cachefly.net/10mb.test

wget establishes a TCP connection to cachefly.cachefly.net, and once established sends a request in the HTTP protocol that says: "Please send me the content of /10mb.test (GET /10mb.test HTTP/1.1) and by the way, could you please not close the connection after you're done (Connection: Keep-alive). The reason it does that is because in case the server replies with a redirection for a URL on the same IP address, it can reuse the connection.

Now the server can reply with either, "here comes the data you requested, beware it's 10MB large (Content-Length: 10485760), and yes OK, I'll leave the connection open". Or if it doesn't know the size of the data, "Here's the data, sorry I can't leave the connection open but I'll tell when you can stop downloading the data by closing my end of the connection".

In the URL above, we're in the first case.

So, as soon as wget has obtained the headers for the response, it knows its job is done once it has downloaded 10MB of data.

Basically, what wget does is read the data until 10MB have been received and exit. But at that point, there's more to be done. What about the server? It's been told to leave the connection open.

Before exiting, wget closes (close system call) the file descriptor for the socket. Upon, the close, the system finishes acknowledging the data sent by the server and sends a FIN to say: "I won't be sending any more data". At that point close returns and wget exits. There is no socket associated to the TCP connection anymore (at least not one owned by any user). However it's not finished yet. Upon receiving that FIN, the HTTP server sees end-of-file when reading the next request from the client. In HTTP, that means "no more request, I'll close my end". So it sends its FIN as well, to say, "I won't be sending anything either, that connection is going away".

Upon receiving that FIN, the client sends a "ACK". But, at that point, wget is long gone, so that ACK is not from any user. Which is why it is blocked by your firewall. Because the server doesn't receive the ACK, it's going to send the FIN over and over until it gives up and you'll see more dropped ACKs. That also means that by dropping those ACKs, you're needlessly using resources of the server (which needs to maintain a socket in the LAST-ACK state) for quite some time.

The behavior would have been different if the client had not requested "Keep-alive" or the server had not replied with "Keep-alive".

As already mentioned, if you're using the connection tracker, what you want to do is let every packet in the ESTABLISHED and RELATED states through and only worry about NEW packets.

If you allow NEW packets from user x but not packets from user y, then other packets for established connections by user x will go through, and because there can't be established connections by user y (since we're blocking the NEW packets that would establish the connection), there will not be any packet for user y connections going through.

Best Answer

Related Solutions

Linux – Iptables: matching outgoing traffic with conntrack and owner. Works with strange drops

Related Question