Table of Contents
In this previous post we explained how to install and configure a FTP server in Linux CentOS 7 using the popular VSFTPD open-source package. As we have clarified there, the File Transfer Protocol is not secure by design because it doesn’t encrypt data being transmitted between two machines: this basically means that everything, including the user’s credentials and all the data, are sent and received in an unprotected way and are thus exposed to sniffing attacks of any kind. This poses a serious threat to data, as well as server security, and can also be addressed as a major privacy issue.
In this follow-up article we’ll try to mitigate all that by showing how to manually enable data encryption services in a FTP server; we will go through various steps of securing VSFTPD (Very Secure FTP Daemon) services using a self-signed SSL/TLS certificate, which is often more than enough to grant us a decent security layer without additional costs.
This guide takes for granted that we have a VSFTPD server up an running on our CentOS 7 machine: if that’s not the case, we can do these required steps by follow the instruction depicted in our previous article about this topic (installing & configuring VSFTPD). Be sure to set the Passive Mode ports and open the firewall accordingly.
Create the SSL Certificate
The first thing to do is to create a /etc/ssl/private/ folder on the server, which we’ll use to store the SSL/TLS key and certificate files:
Once done, we can run the terminal command below to create the certificate and key for VSFTPD in a single file:
sudo openssl req -x509 -nodes -keyout /etc/ssl/private/vsftpd-selfsigned.pem -out /etc/ssl/private/vsftpd-selfsigned.pem -days 365 -newkey rsa:2048
Here’s a useful explanation of the above switches:
- req – is a command for X.509 Certificate Signing Request (CSR) management.
- x509 – means X.509 certificate data management.
- days – defines number of days certificate is valid for.
- newkey – specifies certificate key processor.
- rsa:2048 – RSA key processor, will generate a 2048 bit private key.
- keyout – sets the key storage file.
- out – sets the certificate storage file.
Note that both the certificate and the key will be stored in the same file: /etc/ssl/private/vsftpd-selfsigned.pem.
Once submitted, the above command will ask you to answer the questions below:
- Country Name (2 letter code) [XX]: the ISO 3166-1 two-letter country code for your country. Example: US
- State or Province Name (full name) : the state or province name. Example: Massachusetts
- Locality Name (eg, city) [Default City]: the city of the service. Example: Boston
- Organization Name (eg, company) [Default Company Ltd]: the FTP company name. Example: Example.com
- Organizational Unit Name (eg, section) : The company main area of interest. Example: Information Technology
- Common Name (eg, your name or your server’s hostname) : the hostname required to connect to the FTP server. Example: example.com
- Email Address : the admin e-mail address. Example: firstname.lastname@example.org
Fill out the prompts appropriately. The most important line is the one that requests the Common Name: we need to enter the domain name associated with our server or our server’s public IP address.
Configuring VSFTPD To Use SSL/TLS
Before we perform any VSFTPD configurations, we need to open the TCP port 990 on the firewall in order to allow TLS connections:
firewall-cmd --zone=public --add-port=990/tcp --permanent
Needless to say, the above lines take for granted that the public zone is bound to the WAN: if this is not the case, be sure to open these ports on the right zone.
Right after that, we can open the VSFTPD config file in /etc/vsftpd/vsftpd.conf and specify the SSL details in the following way:
# SSL configuration (TLS v1.2)
It’s worth noting that, since TSL is more secure than SSL, we also took the chance to restrict VSFTPD to employ TLS instead, using the ssl_tlsv1_2 option: doing that will shield your server from some malicious exploits which take advantage of known SSL vulnerabilities, such as POODLE.
The next options to set are those required to define the location of the SSL certificate and key file:
# configure the location of the SSL certificate and key file
Now that SSL has been set, it’s highly advisable to force it whenever possible with the following directives:
# prevent anonymous users from using SSL
# force all non-anonymous logins to use SSL for data transfer
# force all non-anonymous logins to use SSL to send passwords
# Select the SSL ciphers VSFTPD will permit for encrypted SSL connections with the ssl_ciphers option.
# turn off SSL reuse
The last two options specified above is meant to boost up FTP server security. Setting the ssl_ciphers value to HIGH will greatly limit efforts of attackers who try to force a particular cipher which they probably discovered vulnerabilities in; setting require_ssl_reuse to NO won’t force all SSL data connections to exhibit SSL session reuse, thus proving that they know the same master secret as the control channel – which is an info we wouldn’t like to give.
Enabling Passive Mode
The last thing we need to do is to set the port range (min and max port) of passive ports:
Remember to also open them within the firewall, as explained in this post.
Setting up SSL debug
If we feel like we need to we can allow SSL debugging, meaning that all openSSL connection diagnostic info will be recorded to the VSFTPD log file:
Once done, save all the changes and close the file, then let’s restart VSFTPD service in the following way:
systemctl restart vsftpd
That’s about it. We can now easily test our new FTPS server from a remote client by typing the following line from its command-line terminal:
When prompted for the username and password, just insert those you want to test, depending on how you chose to configure the user blacklist or whitelist (see this post for further details). If you choose to go with a valid user who could actually access the server, you should get the following response:
530 Non-anonymous sessions must use encryption.
421 Service not available, remote server has closed connection
The above messages clearly show how VSFTPD won’t allow any user to login from clients that support encryption services – such as the above command-line. Right after that, we can try to run another test with a FTP client that supports SSL/TLS connections such as FileZilla.
That’s it for now: we sincerely hope that this post will help System Administrators to securely setup their FTP server.