There is no such thing as a completely secure server: as long as you provide public access to services running on a server, there is a risk that somebody at some point is going to try something like a privilege escalation or denial of service. What one can do is to minimize the chance of success of such attack or at least to minimize the damages.
I am not going to provide here some “high tech” security mechanisms but rather some “common sense” ones; such measures will most likely prevent speculative attackers or bots from doing their stuff. Let’s start with the first trick from the book:
1. Set up iptables
One may think: why set the firewall up? If I provide 3 services to the world and those are the only ones with listening sockets, why would I need a completely configured firewall?
The answer is: the firewall is always necessary. Having a policy of “deny all + exceptions” will render useless any rogue service that an attacker may inject through some privilege escalation attack.
On a RedHat (CentOS) system one will find the firewall configuration file as /etc/sysconfig/iptables. A typical restrictive configuration might be:
*filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m multiport --dports 22,80,443 -j ACCEPT
The configuration above allows new tcp traffic (new connections) to ports 22 (ssh), 80 (http) and 443 (https), while allowing all outgoing traffic and also the responses received in relation to such traffic. It also allows icmp (ping), but denies everything else.
Switching to “secure mode” from a ftp perspective usually means creating a server certificate (X509, the type used for other secure protocols such as https), loading the “secure module” within the daemon configuration – this step is usually achieved by default – and filling in the gaps in the config file.
For proftpd the steps are easy:
First, create the certificate with a validity of 10 years (yes, yes…):
# openssl req -new -x509 -days 3650 -nodes -out /etc/proftpd/ssl/proftpd.cert.pem -keyout /etc/proftpd/ssl/proftpd.key.pem
Then, ensure that you set the right permissions over the files:
-rw------- 1 root root 1298 Oct 10 15:53 proftpd.cert.pem
-rw------- 1 root root 887 Oct 10 15:53 proftpd.key.pem
And finally wrap things up in the config file; just pick the defaults from the documentation:
<IfModule mod_tls.c> TLSEngine on TLSLog /var/log/proftpd/tls.log TLSProtocol SSLv23 TLSOptions NoCertRequest TLSRSACertificateFile /etc/proftpd/ssl/proftpd.cert.pem TLSRSACertificateKeyFile /etc/proftpd/ssl/proftpd.key.pem TLSVerifyClient off TLSRequired on TLSRenegotiate none </IfModule>
Restarting the proftpd daemon (e.g. with the service command) means that a modern client such as Filezilla can connect, ask you to accept the certificate data and then proceed with the normal operation. Well, not so fast!
Actually, at this point, if everything runs smoothly, there is a security issue waiting to blow just around the corner: you have multiple open ports in the iptables configuration. A secure iptables implementation means a policy of “deny all traffic but this particular exception list” and having “free ports” not closed by the firewall is an invitation for somebody to inject a script and set up a listening socket, accepting commands from outside. This may be used to try privilege escalation attacks or just do some old school DDoS; either way, this is not something one may want to happen on his shift.
What this have to do with the ftp protocol? Well, this uses the known port 21 (tcp) for control (e.g. sending commands from the client to the server) while the data transfer (e.g. directory listing, file contents) happens on a different port. Actually there are 2 protocol variants here:
Passive – when the server opens a listening socket on a dynamic port (allocated and managed by the kernel in the 1024:65535 dynamic pool) and it sents it to the client through the control channel; the client then connects to that port and does the data transfer.
Active – when the client advertises a listening socket on a local port and the server connects to the client from port 20 to that advertised port.
The “active mode” is no longer used by default by the modern ftp clients as most workstations are today behind firewalls; only when “passive mode” fails – and this happens when the server does not actually support it or has it disabled in the configuration – the ftp client switches to “active mode”. Proftpd does not have a configuration switch for disabling “passive mode”, though.
So, wrapping things up, how do you get the passive mode port accessible through iptables while not compromising the node security? You may have learned before about “ip_conntrack_ftp”, the kernel module that allows such traffic to go through the firewall even when all the possible “passive mode” ports are explicitly filtered by iptables. This kernel module can be enabled on RedHat distributions (e.g. RHEL, CentOS, Fedora) in “/etc/sysconfig/iptables-config”:
# Load additional iptables modules (nat helpers) # Default: -none- # Space separated list of nat helpers (e.g. 'ip_nat_ftp ip_nat_irc'), which # are loaded after the firewall rules are applied. Options for the helpers are # stored in /etc/modprobe.conf. IPTABLES_MODULES="ip_conntrack_ftp"
Does it work? The better question should be “How does it work?”.
This kernel module works by looking inside the contents of the data packet; if it positively identifies data transfer associated to an already open connection between a ftp client and the local ftp server, it lets the packet go through. The problem with secure ftp (ftps – not sftp, as that is a different kind of beast) is that such type of traffic analyisis can no longer happen so the packets get silently dropped. This means that a previously secure working (plain) ftp configuration no longer works with secure ftp.
Are there any fixes for this? Yes, you can explicitly open some ports in iptables and make proftpd aware of them, but that’s a security risk as I have explained before:
# iptables -A INPUT -p tcp -m tcp --dport 62000:62500 -j ACCEPT
You may have somewhere on the node a iptables configuration file where to put such command, like “/etc/sysconfig/iptables” (and reload the rules).
Once the ports are no longer filtered, the proftpd configuration may be completed with:
PassivePorts 62000 62500
Restarting proftpd should allow ftps to finally work – that is, until the number of simultaneous clients (for this particular configuration) exceeds 501. At that point it will no longer work. For a soft-fail approach one should consider setting MaxClients, MaxClientsPerUser and MaxTransfersPerUser in the proftpd configuration file.
That’s it for today – or, how to phrase it, that’s why I have not personally enabled ftps in any production environment until now. Have fun – and stay safe!