Managed File Transfer

Managed File Transfer (MFT) refers to software solutions that facilitate the secure transfer of data from one computer to another through a network (e.g., the Internet). MFT solutions are often built using the FTP network protocol. However, the term specifically describes solutions that remedy the disadvantages associated with FTP.

Typically, MFT offers a higher level of security and control than FTP. Features include reporting (e.g., notification of successful file transfers), non-repudiation (i.e., guaranteed delivery), auditability, global visibility, automation of file transfer-related activities and processes, end-to-end security, and performance metrics/monitoring.

Background

From its inception in 1980, FTP has made moving large volumes of bulk data between any two entities--including file servers, applications, and trading partners--possible. However, FTP (and other communication protocols such as HTTP and SMTP) do not, on their own, provide a way to secure or manage the payload or the transmission. Yet, regardless of the lack of security and management capabilities, many companies have continued to transport large batches of structured and unstructured data using these protocols.

This practice is changing, however. According to Gartner Research, "Numerous factors cause companies to re-examine how they manage the movement of information from system to system, partner to partner, and person to person. FTP alone is not a viable option to give [organizations] the insight, security, performance and, ultimately, the risk mitigation necessary to responsibly conduct business."

Telnet - Current status

As of the mid-2000s, while the Telnet protocol itself has been mostly superseded for remote login, Telnet clients are still used, often when diagnosing problems, to manually "talk" to other services without specialized client software. For example, it is sometimes used in debugging network services such as an SMTP, IRC, HTTP, FTP or POP3 server, by serving as a simple way to send commands to the server and examine the responses.



This approach has limitations as Telnet clients speak is close to, but not equivalent to, raw mode (due to terminal control handshaking and the special rules regarding \377 and \15). Thus, other software such as nc (netcat) or socat on Unix (or PuTTY on Windows) are finding greater favor with some system administrators for testing purposes, as they can be called with arguments not to send any terminal control handshaking data. Also netcat does not distort the \377 octet, which allows raw access to TCP socket, unlike any standard-compliant Telnet software.



Telnet is popular with:

* enterprise networks to access host applications, e.g. on IBM Mainframes.
* administration of network elements, e.g., in commissioning, integration and maintenance of core network elements in mobile communication networks.
* MUD games played over the Internet, as well as talkers, MUSHes, MUCKs, MOOes, and the resurgent BBS community.
* embedded systems

Telnet Security

When Telnet was initially developed in 1969, most users of networked computers were in the computer departments of academic institutions, or at large private and government research facilities. In this environment, security was not nearly as much of a concern as it became after the bandwidth explosion of the 1990s. The rise in the number of people with access to the Internet, and by extension, the number of people attempting to crack other people's servers made encrypted alternatives much more of a necessity.

Experts in computer security, such as SANS Institute, and the members of the comp.os.linux.security newsgroup recommend that the use of Telnet for remote logins should be discontinued under all normal circumstances, for the following reasons:


* Telnet, by default, does not encrypt any data sent over the connection (including passwords), and so it is often practical to eavesdrop on the communications and use the password later for malicious purposes; anybody who has access to a router, switch, hub or gateway located on the network between the two hosts where Telnet is being used can intercept the packets passing by and obtain login and password information (and whatever else is typed) with any of several common utilities like tcpdump and Wireshark.

* Most implementations of Telnet have no authentication to ensure that communication is carried out between the two desired hosts and not intercepted in the middle.

* Commonly used Telnet daemons have several vulnerabilities discovered over the years.


These security-related shortcomings have seen the usage of the Telnet protocol drop rapidly, especially on the public Internet, in favor of the ssh protocol, first released in 1995. SSH provides much of the functionality of telnet, with the addition of strong encryption to prevent sensitive data such as passwords from being intercepted, and public key authentication, to ensure that the remote computer is actually who it claims to be.

As has happened with other early Internet protocols, extensions to the Telnet protocol provide TLS security and SASL authentication that address the above issues. However, most Telnet implementations do not support these extensions; and there has been relatively little interest in implementing these as SSH is adequate for most purposes. The main advantage of TLS-Telnet would be the ability to use certificate-authority signed server certificates to authenticate a server host to a client that does not yet have the server key stored. In SSH, there is a weakness in that the user must trust the first session to a host when it has not yet acquired the server key.

FTP servlet an intro

An FTP servlet is an intermediate application that resides between the FTP server and the FTP client. It works as a proxy interposed within client/server communications and helps to unload some of the computing power of the FTP server and distribute it to the FTP servlet. It also provides a firewall and proxy friendly file transfer environment by wrapping FTP traffic over HTTP. FTP traffic can be wrapped over HTTPs using a SSL certificate to provide enhanced security.

Architecture

FTP clients can connect to the FTP servlet through the Internet. In most cases FTP is wrapped over an application layer protocol. Most commonly used are HTTP (for easy, unencrypted transfers) or HTTPs (for encrypted transfers). The use of HTTPs requires an SSL certificate to be present at the site of the FTP servlet. A number of simultaneous connections can be made to the FTP servlet. The number of connections is restricted to the computing power of the server. The number of end-users supported through the number of connections is usually more. As all connected end-users aren’t “active” until they make a request from the server. Consequently, the number of end-users simultaneously online on the FTP server can be greater than the number of active connections supported by the FTP server.

Security

FTP servlets protect direct access to an FTP server from the outside world. The FTP servlet can be housed on the DMZ. The internal network can house the FTP server. Direct access from the outside can’t be initiated with the internal FTP server. For additional security, port forwarding can also be used to enhance security between the DMZ and internal network.

Issues and drawbacks

FTP servlets can only work with advanced FTP clients that support the wrapping of FTP over HTTP or HTTPs. There are a number of commercially available clients/FTP servlets that work in such a way.