FTPdrops and FTPdirs

LiquidFiles has two functions for dealing with old-school FTP when interacting with primarily external customers or external resources. They are both created to help you migrate automated batch-jobs to LiquidFiles. They are not meant to be a replacement for a fully fledged FTP server.

Example Usages:

• Every day you receive a spreadsheet of today's sales from offices around the country. This has always been done by uploading a file using FTP to a specifed server.
• Every week you distribute a list of current prices to your resellers around the country. They download this automatically using FTP every Sunday night to update their records.

What FTPdrops or FTPdirs are not intended for:

• You have a group of users who wants to collaborate by using FTP to share files between them. Some users have read/write access and some read-only access.

Our goal with FTPdrops and FTPdirs is to provide a simple stop-gap to fulfil a current workflow. We are not intending to make LiquidFiles a fully functional FTP server so users can continue using FTP. Our aim is to make FTP redundant, not embrace it. A better long term goal would be to replace automated FTP transfers with transfers using either the API or one of the LiquidFiles CLI applications.

What's the difference between FTPdrops and FTPdirs?

FTPdrops work as FTP upload version of LiquidFiles Filedrops. When someone uploads a file to an FTPdrop, LiquidFiles will remove it from the upload area and move it into the hidden LiquidFiles storage. It will then be logged, scanned and delivered to a predefined (local) user. There will be an email notifying the user of the delivery of the file and the user can then download the file same as if they receive a Filedrop, a Secure Message, File Request response or similar LiquidFiles functions.

If you send a file with FTPdrops, this is FTP upload only. It's not possible to download files using FTP when sent with FTPdrops (same as Filedrops, Secure Messages, ...).

FTPdirs is a simple FTP directory on the LiquidFiles system. Someone first uploads the files or directory, someone else downloads the files or directories at a later date. There's no integration with the rest of LiquidFiles. You cannot access any files in a FTPdir from the LiquidFiles web interface. There's one user per FTPdir. There are no different user classes with different access rights. Nothing like that, that you would exepct if the aim was to build a fully functional FTP server. But if you have a simple drop and retreive workflow using FTP, it will work just fine.

Supported Protocols

In this article, we're referring to FTPdrops and FTPdirs, for either of these, in terms of actual support protocols, what are referring to:

• FTP — old-school, unencrypted and generally unsercure FTP. You can enable or disable this as needed in Admin → System → Network.
• FTPs — FTP using TLS encryption. The TLS encryption will follow the same TLS protocols that are enabled for HTTPs (TLSv1.2, TLSv1.1, ...) as configured in Admin → System → Network. One thing to note with FTPs is that in the LiquidFiles configuration, everything is encrypted, the control channel and the data transfer, except for the Data Port negotiation. This is so that modern firewalls can intercept this and open FTP data ports dynamically (sometimes referred to as FTP snooping).
• SCP — Secure Copy from the SSH suite. SSH/SCP/SFTP all use TCP port 22 for control and data connections so a much easier protocol to deal with in firewalls and similar. You can configure SFTP (and SCP) encryption strength as High or Compatibility in Admin → System → Network.
• SFTP — Secure FTP from the SSH suite. SSH/SCP/SFTP all use TCP port 22 for control and data connections so a much easier protocol to deal with in firewalls and similar. You can configure SFTP encryption strength as High or Compatibility in Admin → System → Network.

If you configure SFTP (and SCP) Encryption Strength as High, that means AES256-CTR only. If you configure SFTP Encryption Strength as Compatibility, that means AES256-CTR, AES192-CTR, AES128-CTR, AES256-CBC, AES192-CBC, AES128-CBC and CAST128-cbc which is the OpenSSH default encryption algorithms in the underlying Ubuntu operating system for LiquidFiles. If these defaults where to change for OpenSSH in future versions, sowould the encryption algorithms when the SFTP Encryption Strength is set as Compatibility.
If all clients using FTPdrops/FTPdirs with SCP or SFTP support AES256-CTR, it's the preferred configuration.

Please note that with the exception of unencrypted FTP, it's not possible to disable specific protocols and it's not possible to specify that different FTPdrops or FTPdirs should only accept certain protocols.

Please note that when you login with ssh keys make sure your sftp client is permitted to use the ssh-rsa public key signature algorithm for host authentication. In newer Linux distributions this algorithm can be disabled and needs to be manually permitted for sftp clients.
i.e.: sftp -oPubkeyAcceptedAlgorithms=ssh-rsa -i /path/to/ssh_key.pem ftpuser@liquidfiles.domain.com

The easiest way to disable either FTP and FTPs, or SCP and SFTP, is to simply not enable the configuration in your firewall.

General Configuration

To use either FTPdrops or FTPdirs, you have to configure your network same as you would any other FTP server. In firewalls and similar you need to enable the incoming control connection on TCP port 21, and for maximum operability, you will need to configure your network for both passive and active FTP data connections.

Active data connections are initiated from the LiquidFiles system using TCP source port 20, to some random negotiated port on the client. Passive FTP data connections originate from the client to a range of TCP ports 44000-44100 on the LiquidFiles system.

Some firewalls have FTP "snooping" or similar functionality that listens on the FTP control channel and opens the required connections automatically. If your firewall does not have FTP "snooping" or similar, you will manually need to configure these ports. Please see th Network & Firewall configuration section for more information.

FTP Masquarading

When using FTP and FTPs in passive mode, both the control and data connection are initiated from the client side. The control connection will connect to TCP port 21 and the data connection port is dynamically negotiated. In the FTP data port negotiation, the FTP server will send something like: Connect to me using IP A.B.C.D on Port 44000. The A.B.C.D ip address it will get from the interface you connected to. Normally, you would have a firewall with public ip addresses, translating to an internal ip adress and the A.B.C.D ip address will therefore be the FTP servers internal address.

If you have a firewall with FTP snooping it will intercept this connection and replace the internal A.B.C.D ip address with the firewalls external ip address and then dynamically map the external data connection to the internal.

If you don't have a firewall with FTP snooping capabilities, you will run into problems because obviously the external client cannot connect to an internal ip address at your site.

If you have this issue you will see that logging in to the system works fine, but as soon as any data transfer is initiated, everything will just hang. If you look in the FTP clients log, you will also see that it's trying to connect to an internal ip address.

To fix this issue, we can configure the LiquidFiles FTP server with FTP masquarading. This will tell the FTP server to use a pre-defined ip address when initiating the data connection. You would set this address to the firewalls external ip address and all connections from the client will use the firewalls external ip address.

The only potential issue is if you have multiple interfaces on the firewall and you wish to use multiple interfaces, i.e. both external and internal users should be able to use FTP and FTPs. Internal connections will also be forced to use the firewalls external ip address if you configure FTP masquarading for the data connection and some firewalls don't like connections from internal addresses to the external interface. Please consult your firewalls documentation/support if you hace this issue as this is a generic FTP issue, not specific to LiquidFiles.

Multi-domain Limitations

When using additional domains with your Liquidfiles system, the use of FTPdrops/FTPdirs are slightly limited. The reason is that FTP does not have the equivalent of virtual domains same as HTTP/HTTPs does. With HTTP/HTTPs, we can use multiple FQDN's on the same ip address. Each HTTP/HTTPs will request a document with the FQDN and we can use this to have different domains, with different SSL/TLS certificates on the same IP address but with different domains. In the FTP/FTPs case, there's nothing similar. When connnecting to the FTP server to send and receive files using FTPdrops or FTPdirs, the FTP server will always present itself with the hostname of the default domains.

This would specifically be a problem when using FTPs as a well behaving FTP client should refuse to connect to liquidfiles.seconddomain.com if the certificate present itself as liquidfiles.primarydomain.com. Your options in this case would be limited to either get the clients to override the Certificate warning to accept it anyway, or get the clients when using FTPs to secondary domains instead use the hostname of the primary domain.

Please note that this issue is a generic FTP/FTPs issue and not LiquidFiles specific.

FTPdrop Specific Configuration

When adding a FTPdrop, you can configure the following:

FTPdir Specific Configuration

When adding a FTPdir, you can configure the following: