[HOW TO] Set up your ProFTPd FTP server to support the secure protocols while disabling insecure FTP


Verified User
Feb 27, 2006
- The only ones that know much about security of Internet protocols are those who administer the web servers.
- People work from public hot spots around the world.
- Users who hire web development services often don't know the person or their character who will be working on their site. They want to restrict them to being virtual users, not give them admin rights to all of their domain's resources and correspondence.

- I will put file edit inside of quotes because it sets it apart and I cannot highlight inside of code tags.
- File changes are highlighted in the color RED.
- Green areas are changes from DirectAdmin's procedures: How to install mod_sftp into ProFTPD where I had to make changes to make it work.
- DirectAdmin installed with CSF Firewall
- Basic CustomBuild ProFTPd install

1. Change ports on the Firewall

- Log in Admin to the and under Extra Features click on ConfigServer Security & Firewall.
- Click on Firewall Configuration and scroll down to IPv4 Port Settings. In the port lists for both incoming and outgoing, add port 44 (for SSH) and remove port 20 (FTP data)
- Pull scroll bar to bottom and press Change followed by restart.
2. Configure SSH to use Port 44 to free up Port 22 for ProFTPd's soon to be added mod_sftp to enable SFTP for virtual users.
*Since SFTP and SSH are part of the same protocol suite, they both use the same port 22. Since both processes cannot service the same port, we must move the sshd process for administrators to use non-standard port 44.
- Edit /etc/ssh/sshd_config and add the Port 44 line below the commented default port of 22.
# Port 22
Port 44 # Change SSH in order to use SFTP on 22
# service sshd restart
- Change ports on WinSCP and PuTTY and MAKE SURE you can connect using port 44.
3. Remove our client IP from CSF's whitelist - The CSF Firewall install program is clever and records the IP of the client performing the install (usually) and whitelists it so he doesn't lock himself out. The problem that presents is not being able to determine if the firewall is working correctly. Since we have proven PuTTY and WinSCP work fine on port 44, we can safely remove ourselves from csf's white list.
- Edit the /etc/csf/csf.allow file and check for the public IP of your client machine. If present, remove it, and restart the firewall with:
# csf -r (restart the firewall)
4. Reconfigure ProFTP to allow secure file transport only
- Edit Options file:
# cd /usr/local/directadmin/custombuild
# ./build update
# ./build set ftpd proftpd
# mkdir -p custom/proftpd/conf (make a directory for custom ProFTPd config that adds mod_sftp)
# wget -O custom/proftpd/configure.proftpd http://files.directadmin.com/services/all/sftp/configure.proftpd.sftp
# wget -O custom/proftpd/conf/proftpd.conf http://files.directadmin.com/services/all/sftp/proftpd.conf
# chmod 755 custom/proftpd/configure.proftpd
# wget -O /etc/proftpd.sftp.conf http://files.directadmin.com/services/all/sftp/proftpd.sftp.conf
# mkdir /etc/proftpd.ssl
# cp /etc/ssh/ssh_host_rsa_key* /etc/proftpd.ssl
# chmod 400 /etc/proftpd.ssl/ssh_host_rsa_key

# cp /etc/proftpd.sftp.conf /etc/proftpd.sftp.conf_original
- Edit /etc/proftpd.sftp.conf
<IfModule mod_sftp.c>
# The SFTP configuration
# Port 23
Port 22 # Change to standard port now possible after moving SSH to 44
AuthUserFile /etc/proftpd.passwd
TransferLog /var/log/proftpd/xferlog.legacy
ExtendedLog /var/log/proftpd/ WRITE,READ userlog
SFTPEngine on
SFTPLog /var/log/proftpd/sftp.log
# SFTPHostKey /etc/ssh/ssh_host_rsa_key
SFTPHostKey /etc/proftpd.ssl/ssh_host_rsa_key # Change to use key pair copied to /etc/proftpd.ssl and given necessary rights (0400) for mod_sftp.c work.
SFTPAuthorizedUserKeys file:~/.sftp/authorized_keys
# cp /etc/proftpd.sftp.conf /etc/proftpd.sftp.conf_current_running_copy
- Edit /usr/local/directadmin/custombuild/custom/proftpd/conf/proftpd.conf
- Near the top of the file inside <VirtualHost> change the Port to 0
# Port 21
Port 0 # Changed to prevent unencrypted FTP
AuthUserFile /etc/proftpd.passwd
- and the mod_tls area nearest the top.
<IfModule mod_tls.c>
TLSEngine on
TLSRequired on # Changed added to force encryption on port 21 for for FTPeS (Explicit)
Port 21 # Changed added to enable 21 for FTPeS (Explicit)
# TLSOptions UseImplicitSSL # Change add for FTPS (Implicit)
# Port 990 # Change add for FTPS and in the firewall open ports 989 and 990 and remove port 21 (FTP & FTPeS)

TLSLog /var/log/proftpd/proftpd.tls.log
TLSProtocol ALL -TLSv1 -TLSv1.1
# cd /usr/local/directadmin/custombuild
# ./build proftpd (rebuild ProFTPd with new config)

5. Test Install with FTP client
- Set up profiles for FTP, FTPS, and SFTP
- FTP should fail, and both FTPS and SFTP should work fine.

- With the above arrangement, the ProFTPd daemon will be monitoring FTPS on the standard port 21, SFTP on the standard port 22, with the SSHd daemon on monitoring custom port 44. Port 20 has been closed because it is only needed for the FTP that we disabled.
- Is there a reason to support FTPS? Actually there is for two reasons. First, a lot of web developer tools use it. Second, from my testing, it runs at the same speed or extremely close to unencrypted FTP while SFTP was 8% slower for some reason. Whether 8% matters depends on how much you are sending. I did not do the CPU measurements like some on the web do, but CPU power is not my bottleneck.

Too Much Information
runs on port 21 and is unencrypted. The login credentials, if any, and all data sent or received are unencrypted. Especially not cool to leave open when operating out of a coffee shop or while traveling. FTP is a very old protocol and due to the era, is not session based. Thus, to handle more than one session, the server had to use a different port set, one for send and the other receive, for each client being serviced. This means that port 21 is a control port where things get negotiated, but the actual transfer happens on different ports. By standard, the pairs are randomly assigned outside of the standard port range, which means anywhere in the range of 1024-65,535. Leaving all of those ports open is security issue, and it requires the client and/or server to have those same ports open. There are two modes for negotiating those ports, Active, and Passive.
1. Active - In Active mode, the client sends a PORT command and a random port, which the server adds 1 to for the call back. The server attempts to initiate the communication session back to the client, which their firewall will likely block, because it is an incoming connection to the client firewall on a port it is not expecting traffic on and thus would be no different than any other intruder from the Internet even though the client gave the server the ports because the client does not control the ports in the client's firewall. Thus, today it is useless because both computers would have to be connected directly to the Internet with a public IP address, and have all ports open from 1024-65535.
2. Passive - In passive, the client sends the PASV command, and the server passes back the port to use. The assumption is then again plus one, but the server specified the ports to the client, and then the client establishes both sessions. Outbound sessions are generally not blocked by firewalls. The firewall on the server end can be configured to use a much more restricted range of ports, such as 35000 35999, because the server is specifying to the client which ones to use. Thus, passive is normally the only mode that can work these days when there are firewalls involved. Even the cheapest home router that NATs is an effective firewall.

FTPS, like HTTPS, adds encryption to the same protocol, thus FTPS retains all of the characteristics of the underlying protocol, and uses the same port 21 for control. FTPS has been implemented in two different modes, Explicit an Implicit.
1. "Explicit FTPS (FTPeS) is the newer method of FTPS transfer and has generally overtaken implicit FTPS use, with the exception of legacy systems." Is the official word and also false. When explicit FTPS is used, a traditional FTP connection is established on the same standard port as FTP. Once the connection is made (before login), a secure SSL connection is established via port 21. Explicit FTPS inherently provides users with flexibility regarding how files are sent. So, you could choose to send data unencrypted, but protect your user credentials, or you could protect all information sent in a transfer. The client can decide how secure they want file transfers to be. The server can also disallow insecure requests, thereby forcing the client to use FTPS and not FTP.
2. Implicit FTPS (FTPS) was the first method created to encrypt data sent “via FTP” and a different set of ports are used. Rather than 20 and 21, it uses SECURE ports 989 and 990. When using implicit FTPS, an SSL connection is immediately established via port 990 before login or file transfer can begin. If the recipient fails to comply with the security request, the server immediately drops the connection. Implicit FTPS is actually more strict than explicit FTPS (FTPeS) with regard to establishing a secure connection. In fact, the entire FTP session is encrypted, in contrast to flexibility you have when using explicit FTPS. However, implicit FTPS is considered a deprecated protocol, meaning that it not the current standard. For this reason FTP server authors dropped it from their servers and for the reasons mentioned above they were also tarred and feathered for doing it so they added it back, but not as the default.

SFTP is a file transfer protocol is part of the SSH (Secure Shell) protocol suite, which is what enables administrators to open a remote terminal window to execute operating system commands. The protocol suite uses port 22 by default and is session-based, and thus does not require seperate ports for control and data nor a range of ports to enable multiple connections. This means that in a situation where you have one server process that only supports SFTP for users, and another that supports both Secure Shell and SFTP for administrators, one of those processes will need to be moved to a non-default port. Server admins commonly move SSH to a non-standard port for obscurity purposes anyway simply to cut down login attempts by robots. Untypically, I've been using port 44 simply because I want to. The last assignment that IANA assigned it was for special equpment that has not been used on the Internet for decades. Well-known are 1-1023, registered can be in the range of 1024-49151, and 49152-65535 is the dynamic range (e.g. nobody can register ports in this area, but can use it for anything. There is a somewhat defacto range for FTP ephereral ports in the 35000:35999 range, but there are a number of off-the-wall registrations in that area also, and officially it is anywhere between 1024 and 65,535. 2222 doesn't belong to DirectAdmin, but at least IANA gives them a grandfather mention. You could get run over anywhere in the Dynamic area by something. My thought is I'm safer at 44-46 than anyplace else because it is registered for equipment that hasn't had a purpose in today's Internet for decades, and 44 is double 22. "So that's my story and I'm sticking to it."
Last edited: