CompleteFTP 3.3.0 has just been released, and has added some very useful features.

WinSCP is now supported for the SCP protocol. Most people would use WinSCP with the SFTP protocol, but for those wishing to use SCP only, CompleteFTP has not supported this mode until now. This is because WinSCP assumes a Unix shell is available, and sends a number of Unix commands to the server to provide directory navigation, creation and listing.

CompleteFTP nows supports the required Unix commands (even though it is a Windows server), and so WinSCP can now be used in SCP only mode.

Another important feature that has been added for 3.3.0 is auto-banning of IP addresses. It works by automatically banning IP addresses from connecting (for a period of time) if they have failed to authenticate a certain number of times within a time period.

For example, using the default settings, if a rogue client is attacking from a given IP address, and fails to guess a password correctly 10 times within a 60 second period, their IP address is banned from connecting for the next hour. After an hour has elapsed, the ban is automatically lifted. The auto-banning settings are configurable in the Professional Edition, although it is generally advisable to use the defaults.

Auto-banning significantly enhances the server security, preventing dictionary attacks that rapidly guess passwords in succession.

With the release of version 3.0, CompleteFTP has moved to a new level.

The Standard Edition continues to offer a fast, secure FTP/FTPS/SFTP server for the Windows platform.

The Professional Edition builds significantly on this with a number of new enterprise features. These include:

• support for SCP (secure copy)
• email notification for a variety of events such as file upload, download, delete
• Auditing (i.e. tracking all changes to files)
• Permission editing
• FTPS client certificate verification
• IP filtering (accept/reject connections based on IP address)

With these additional enhancements, CompleteFTP is now an extremely competitively priced and feature-rich solution for FTP/FTPS/SFTP/SCP support on the Windows platform.

A trial download and more details can be obtained at this link.

Introduction

FTP, the File Transfer Protocol, is used widely around the world for transferring files across networks, especially the Internet. Almost every organization with an IT infrastructure uses FTP to a greater or lesser extent.

There comes a time for many FTP users when they start considering security. FTP transfers passwords, commands and file contents in plain text - anyone who can sniff the packets can read what is being sent. And if the Internet is being used, in practical terms that means almost everyone, and so security is essential.

If file transfers are to be secure, there are basically two alternatives.

FTPS

The first is FTPS. FTPS, defined in RFC 4217, is the standard FTP protocol transmitted over a secure connection. FTPS is often described as FTP over SSL (or FTP over TLS), where SSL is the Secure Sockets Layer. TLS, or Transport Layer Security, is a revised version of SSL.

SFTP

The other alternative is known as SFTP, or the SSH File Transfer Protocol. SFTP is a completely different protocol to FTP, and runs over the SSH (secure shell) protocol. SSH is used to secure the connection, and SFTP provides the file transfer commands.

Comparison

So given that FTPS and SFTP are two completely different protocols, what is the best alternative?

Naturally, each protocol has its strengths and weaknesses, and these are discussed below. However an important consideration is existing infrastructure. If SSH is already widely implemented in an organization, it might make sense to use SFTP.  However many FTP servers also support FTPS, and so it may be very straightforward to upgrade existing FTP servers to FTPS. Of course client applications must also be upgraded no matter which secure protocol is used.

FTPS has a significant advantage over SFTP in that it is simply an extension to the existing FTP protocol, and is widely supported. If a server can be upgraded to FTPS (often simply by a configuration change), then little else need be changed. The existing user accounts can be used securely in the same manner they were previously.

However the use of the existing FTP protocol for FTPS also has a disadvantage. FTP uses a new network connection for each listing and data transfer, on essentially random port numbers. This can have its own problems when many small files are transferred - the system may run out of ports until freed sockets are returned to the operating system. Also, firewalls are smart enough to read the FTP commands and responses that are sent on the control channel, and automatically open the correct ports as required. However once the control channel is encrypted, firewalls can no longer do this. The result is that listings and transfers may fail because of blocked ports. Instead, the firewall must be configured to permit a range of port numbers, and this range must also be configured in the client or the server.

This is where SFTP comes into its own. Everything is transmitted on a single secure connection - there is no opening or closing of new sockets, and thus no problems with running out of ports. Firewalls normally let SSH through on the standard port 22, so SFTP generally has no firewall issues. Because changes in firewall configuration (if permitted) can take some time to organize in many organizations, this can be a significant advantage over FTPS.

There is a security issue with SFTP, related to its reliance on SSH. Generally, if the user credentials permit connecting via SFTP, they will also allow SSH access, meaning the user is able to run a secure remote shell on the server and execute remote commands. This may not be desirable, and care must be taken to disable SSH access if required.

Server validation is performed differently in the two protocols. In FTPS the server sends the client a certificate to identify itself, while in SFTP the server sends its public key. The FTPS certificate contains the server’s public key, however if the certificate is issued by a certificate authority (CA), then the client can take advantage of the chain of trust to accept the certificate. With SFTP the public key must already be installed on the client so that the server’s public key can be validated.

The actual algorithms used to encrypt the data are the same for both protocols, and so neither protocol could be said to be more secure than the other.

SFTP more commonly supports compression of data, which can be useful if large text files are being transferred.

Conclusion

Ultimately, the choice will probably depend on existing infrastructure and the availability of the in-house skills that are required to enable each protocol. If firewalls are a potential concern, then SFTP may edge ahead.

When it comes to writing client applications, it is prudent to hedge a little. Products such as edtFTPj/PRO and edtFTPnet/PRO support both protocols, and client applications using these libraries can be made to do so as well.

Introduction

This demonstrates how Java clients can connect to FTPS servers to transfer files, using  edtFTPj/PRO.

Detail

FTPS is a protocol for transferring files securely via FTP. Basically, the standard FTP protocol is encrypted via secure sockets, or SSL. For Java clients to communicate to FTPS servers, the client side of the FTP protocol and SSL must be implemented in Java.

It is not realistic for most applications to directly implement the FTPS protocol. Instead, it is best to acquire an implementation that is well tested and feature rich - for example, edtFTPj/PRO. The following example demonstrates how a client using edtFTPj/PRO can connect to an FTPS server and list the current directory on the server. It downloads every file in the directory:

import com.enterprisedt.net.ftp.*;
 
SecureFileTransferClient client = new SecureFileTransferClient();
 
// set params
client.setRemoteHost(host);
client.setUserName(username);
client.setPassword(password);
client.setProtocol(Protocol.FTPS_EXPLICIT);
 
client.connect();
 
// get a directory listing
FTPFile[] files = client.directoryList();
for (int i = 0; i < files.length; i++) {
   System.out.println(files[i].toString());
   client.downloadFile(files[i].getName(), files[i].getName());
}
 
client.disconnect();