CompleteFTP 6.2.0 has been released, and contains an exciting new feature in the Enterprise Edition called the multi-protocol gateway.

Basically, CompleteFTP can act as a gateway to other servers. It can present any of its own protocols to a client, and translate them into a different protocol to talk to another server. The client will be unaware it is communicating with this other server.

This is an extremely powerful feature. For example, you can use the gateway to:

• Provide secure access to another non-secure FTP server located on the same machine or network. CompleteFTP provides a secure wrapper to the secure server. This means SFTP or FTPS clients can connect to CompleteFTP, which proxies the requests on to the non-secure server.
• Add FTP or FTPS support to an existing SFTP server. This means FTP or FTPS clients can access the SFTP server without any other changes than setting up CompleteFTP to proxy the requests.
• Add SFTP support to an existing FTP or FTPS server. This means SFTP clients can access the FTP or FTPS server without any other changes than setting up CompleteFTP to proxy the requests.

The remote server can be used simply as a remotely mounted filesystem, but it can also be used to authenticate users logging into CompleteFTP.

We look forward to hearing from customers how they are using the multi-protocol gateway.

CompleteFTP Enterprise Edition has been released, and is available now.

The Enterprise Edition is aimed at users wanting enterprise features such as customization, multiple sites and built in failover.

This version of Enterprise Edition introduces .NET extensions for customization of authentication, filesystems, events and site commands. Now customers can plug in their own authentication mechanisms, their own file systems and events, as well as adding custom site commands. For more details on .NET extensions see the User Guide for extensions.

Multiple sites is the next feature slated for release in June, and will be followed by failover capabilities in Q3.

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

CompleteFTP 4.0 has now been released, and has added some significant new features (mainly in the Professional Edition).

Disk and bandwidth quotas mean that administrators have more control over users’ use of resources. Quotas are set on an individual user basis.

Extensive real-time charts for performance monitoring have been added, so that a variety of statistics can be displayed, such as logins, uploads and downloads.

Event notification has been extended beyond email notification to include process triggers. This means that server processes can be launched when events such as uploading or downloading occur. For example, after uploading a DOS process might be used to copy a file, or perhaps to launch a process to parse the file and insert its contents in a database.

And finally, SSH terminal access has been added, so that a command-line terminal on the server can be accessed by any SSH client on any platform. This is a Unix-like shell that allows basic file operations to be performed, as well as the ability to execute processes on the server.

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

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 SFTP servers to transfer files, using  edtFTPj/PRO.

Detail

SFTP is a protocol for transferring files securely via the SSH protocol. File transfer commands are implemented on top of SSH. For Java clients to communicate to SFTP servers, the client side of the SFTP protocol and SSH must be implemented in Java.

It is not realistic for most applications to directly implement the SFTP 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 SFTP 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.SFTP);
 
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();