FTP server
The File Transfer Protocol (FTP) is a standard network protocol used for the transfer of computer files between a client and server on a computer network.
FTP is built on a client-server model architecture using separate control and data connections between the client and the server. FTP users may authenticate themselves with a clear-text sign-in protocol, normally in the form of a username and password, but can connect anonymously if the server is configured to allow it. For secure transmission that protects the username and password, and encrypts the content, FTP is often secured with SSL/TLS (FTPS) or replaced with SSH File Transfer Protocol (SFTP).
Every webserver has a FTP server so you can upload files to your webserver. You can also use it as a NAS to store your data external.
Active vs passive
Active FTP
In active mode FTP the client connects from a random unprivileged port (N > 1023) to the FTP server's command port, port 21. Then, the client starts listening to port N+1 and sends the FTP command PORT N+1 to the FTP server. The server will then connect back to the client's specified data port from its local data port, which is port 20.
From the server-side firewall's standpoint, to support active mode FTP the following communication channels need to be opened:
FTP server's port 21 from anywhere (Client initiates connection)
FTP server's port 21 to ports > 1023 (Server responds to client's control port)
FTP server's port 20 to ports > 1023 (Server initiates data connection to client's data port)
FTP server's port 20 from ports > 1023 (Client sends ACKs to server's data port)
When drawn out, the connection appears as follows:
In step 1, the client's command port contacts the server's command port and sends the command PORT 1027. The server then sends an ACK back to the client's command port in step 2. In step 3 the server initiates a connection on its local data port to the data port the client specified earlier. Finally, the client sends an ACK back as shown in step 4.
The main problem with active mode FTP actually falls on the client side. The FTP client doesn't make the actual connection to the data port of the server--it simply tells the server what port it is listening on and the server connects back to the specified port on the client. From the client side firewall this appears to be an outside system initiating a connection to an internal client--something that is usually blocked.
Passive FTP
In order to resolve the issue of the server initiating the connection to the client a different method for FTP connections was developed. This was known as passive mode, or PASV, after the command used by the client to tell the server it is in passive mode.
In passive mode FTP the client initiates both connections to the server, solving the problem of firewalls filtering the incoming data port connection to the client from the server. When opening an FTP connection, the client opens two random unprivileged ports locally (N > 1023 and N+1). The first port contacts the server on port 21, but instead of then issuing a PORT command and allowing the server to connect back to its data port, the client will issue the PASV command. The result of this is that the server then opens a random unprivileged port (P > 1023) and sends P back to the client in response to the PASV command. The client then initiates the connection from port N+1 to port P on the server to transfer data.
From the server-side firewall's standpoint, to support passive mode FTP the following communication channels need to be opened:
FTP server's port 21 from anywhere (Client initiates connection)
FTP server's port 21 to ports > 1023 (Server responds to client's control port)
FTP server's ports > 1023 from anywhere (Client initiates data connection to random port specified by server)
FTP server's ports > 1023 to remote ports > 1023 (Server sends ACKs (and data) to client's data port)
When drawn, a passive mode FTP connection looks like this:
FTPS
FTPS (also known as FTPES, FTP-SSL, and FTP Secure) is an extension to the commonly used File Transfer Protocol (FTP) that adds support for the Transport Layer Security (TLS) and, formerly, the Secure Sockets Layer (SSL, which is now prohibited by RFC7568) cryptographic protocols.
FTPS should not be confused with the SSH File Transfer Protocol (SFTP), a secure file transfer subsystem for the Secure Shell (SSH) protocol with which it is not compatible. It is also different from FTP over SSH, which is the practice of tunneling FTP through an SSH connection.
Methods of invoking security
Two separate methods were developed to invoke client security for use with FTP clients: Implicit and Explicit. While the implicit method requires that a Transport Layer Security is established from the beginning of the connection, which in turn breaks the compatibility with non-FTPS-aware clients and servers, the explicit method uses standard FTP protocol commands and replies in order to upgrade a plain text connection to an encrypted one, allowing a single control port to be used for serving both FTPS-aware and non-FTPS-aware clients.
Implicit
Negotiation is not supported with implicit FTPS configurations. A client is immediately expected to challenge the FTPS server with a TLS ClientHello message. If such a message is not received by the FTPS server, the server should drop the connection.
In order to maintain compatibility with existing non-FTPS-aware clients, implicit FTPS was expected to listen on the IANA well known port 990/TCP for the FTPS control channel, and port 989/TCP for the FTPS data channel. This allowed administrators to retain legacy-compatible services on the original 21/TCP FTP control channel.
Note that implicit negotiation was not defined in RFC 4217. As such, it is considered an earlier, deprecated method of negotiating TLS/SSL for FTP.
Explicit
In explicit mode (also known as FTPES), an FTPS client must "explicitly request" security from an FTPS server and then step up to a mutually agreed encryption method. If a client does not request security, the FTPS server can either allow the client to continue in insecure mode or refuse the connection.
The mechanism for negotiating authentication and security with FTP was added under RFC 2228, which included the new FTP command AUTH. While this RFC does not explicitly define any required security mechanisms, e.g. SSL or TLS, it does require the FTPS client to challenge the FTPS server with a mutually known mechanism. If the FTPS client challenges the FTPS server with an unknown security mechanism, the FTPS server will respond to the AUTH command with error code 504 (not supported). Clients may determine which mechanisms are supported by querying the FTPS server with the FEAT command, although servers are not necessarily required to be honest in disclosing what levels of security they support. Common methods of invoking FTPS security included AUTH TLS and AUTH SSL.
The explicit method is defined in RFC 4217. In the later versions of the document, FTPS compliance required that clients always negotiate using the AUTH TLS method.
Installing
# yum -y install vsftpd
The ftp server is IPv4 or IPv6. If we want both we build 2 servers.
IPv4
Configuring
Before adding the SSL section test the server insecure and when it works setup TLS. This server whil run FTPS explicite with encrypted data in passive mode.
# vi /etc/vsftpd/vsftpd.conf anonymous_enable=NO local_enable=YES write_enable=YES local_umask=022 #anon_upload_enable=YES #anon_mkdir_write_enable=YES dirmessage_enable=YES xferlog_enable=YES connect_from_port_20=YES xferlog_file=/var/log/vsftpd.log xferlog_std_format=YES nopriv_user=ftp ftpd_banner=Welcome to example.com FTP service. chroot_local_user=YES chroot_list_enable=YES chroot_list_file=/etc/vsftpd/chroot_list listen=YES #listen_ipv6=YES # Setting-up passive FTP pasv_enable=YES pasv_max_port=10100 pasv_min_port=10080 #pasv_addr_resolve=YES #pasv_address=ftp.example.com pam_service_name=vsftpd userlist_enable=YES tcp_wrappers=YES #one_process_model=NO ssl_enable=YES allow_anon_ssl=NO force_local_data_ssl=YES force_local_logins_ssl=YES # SSL/TLS protocols to use ssl_sslv2=NO ssl_sslv3=NO ssl_tlsv1=NO ssl_tlsv1_1=YES ssl_tlsv1_2=YES #ssl_tlsv1_3=YES require_ssl_reuse=NO ssl_ciphers=HIGH rsa_cert_file=/etc/pki/tls/certs/example.com_fc.pem rsa_private_key_file=/etc/pki/tls/private/example.com.key
Testing
There is no testing option for the configuration.
Starting
# systemctl start vsftpd # systemctl enable vsftpd
Firewall
# firewall-cmd --permanent --add-service=ftp # firewall-cmd --permanent --add-port=10080-10100/tcp # For TLS use only # firewall-cmd --reload
Starting
# systemctl start vsftpd6 # systemctl enable vsftpd6
Router
When you use unsecure ftp the router needs only forwarding port 21 to our server.
When we use FTPS this won't work. We have to forward also the ports 10080 - 10100 to our server.