Home / server / Questions / 811431
Accepted
raffe
Asked: 2016-10-27 06:22:55 +0800 CST

Are my iptables for FTPS with TLS OK?

  • 772

I have tried to Google around to get a iptable for my FTPS with TLS (proftpd) working with the iptables killswitch I now have working (see https://www.reddit.com/r/linuxquestions/comments/57mga5/is_my_iptables_killswitch_working_have_some_p/ ).

I use port 10210 for the FTPS and 60100-60119 for passive ports, this traffic don't go thru the VPN. I have come up with this (they are above the last drop lines):

# Allow traffic via TLS FTPS
iptables -A INPUT -p tcp -m tcp --dport 10210 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
# It seems to be working without the line under
#iptables -A INPUT -p tcp -m tcp --dport 20 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -m tcp --sport 10210:60119 --dport 60100:60119 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -j REJECT --reject-with icmp-port-unreachable
iptables -A OUTPUT -p tcp -m tcp --dport 10210 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
# It seems to be working without the line under
#iptables -A OUTPUT -p tcp -m tcp --dport 20 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --sport 10210:60119 --dport 10210:60119 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

It seems to work, but as I am a iptables noob, I'm wondering what I have done wrong (I probably have ;), not sure about the port ranges and maybe it is to open?)

EDIT I had problems with connections, so I have changed to this that work better

-A INPUT -p tcp -m tcp --dport 10210 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --sport 10210 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 60100:60119 -j ACCEPT
-A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 10210 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m tcp --sport 10210 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 60100:60119 -j ACCEPT
-A OUTPUT -p tcp -m tcp --sport 60100:60119 -j ACCEPT

I will later, after reading http://ipset.netfilter.org/iptables-extensions.man.html , try this instead of the port ranges above

iptables -A INPUT -p tcp --dport 60100:60119 -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 60100:60119 -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 60100:60119 -m conntrack --ctstate NEW,ESTABLISHED,RELATED-j ACCEPT

And remove -A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT and also I wonder if I actually also should remove -m conntrack --ctstate NEW,ESTABLISHED for 10210 as it IS the incoming port for the FTPS?

linux iptables linux-networking

1 Answers

  1. Best Answer

    OUTPUT part is only for the connection, which is INITIATED from the server, it doesn't affect connection initiated from the client at all. Usually OUTPUT is NOT FILTERED, unless you have special requirement for blocking something outgoing.

    INPUT is the part you should filter.

    ESTABLISHED and RELATED parts are for connection, which is already initiated and should continue working (i.e. like TCP after handshake) and usually there is higher match than on other rules.

    We can divide FTP connection in three types:

    1. Active FTP (plain)
    2. Passive FTP (plain)
    3. FTP with SSL (any encrypted)

    In case of Active FTP you need to open incoming TCP 21 and outbound with source TCP 20 port and random destination at client side and this type of connection is rarely used, i.e. one connection is initiated from the client and one connection is initiated from the server. Because of the last one - it practically never works.

    In case of Passive FTP situation is worse, Passive FTP uses TCP 21 port for commands and RANDOM TCP port for data transfer for any connection, which port will be that is specified in FTP response of the server, so, firewall must "listen" to the FTP traffic, which requires deeper inspection of packets and then dynamically open the port - this is normal situation. In this case FTP connection tracking helpers/kernel modules are used and that solves the issue - you only have to open TCP port 21.

    In case of SSL - it's even crazier, because data about RANDOM port is also encrypted and firewalls are unable to guess which port to open, in this case some guys specify number of random ports in the FTP server configs and open all of these ports on the firewall.

    Normally rule order for filter table usually looks like this:

    *filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m conntrack --ctstate NEW -m tcp -m multiport --dports 22,80,443 -j ACCEPT
-A INPUT -i eth1 -p tcp -m conntrack --ctstate NEW -m tcp -m multiport --dports 22,53,80,1234 -j ACCEPT
-A INPUT -i eth1 -p udp -m conntrack --ctstate NEW -m udp -m multiport --dports 53,67,123 -j ACCEPT
COMMIT

    For SSL you might add following rule somewhere

    -A INPUT -p tcp -m conntrack --ctstate NEW -m tcp -m multiport --dports 21,15000:15050 -j ACCEPT
    • 2