Adding a Protective Layer to FTP and Telnet
June 25, 2002
Security and convenience are often at loggerheads with one another, and human nature usually leans toward convenience. The heightened profile of network security breaches, however, is leading many organizations to take security more seriously. Like locking up the car or the house, it would be nice if we didn't have to worry about server security, but unfortunately that's not the world in which we live.
Telnet and FTP are two popular and convenient ways to gain access to commands or files on remote servers. Many organizations rely on these network tools if their contributors are far flung, whether telecommuters or simply distributed teams of people working together.
Despite their convenience and popularity, neither telnet nor FTP are at all secure. Communications with these protocols can be intercepted, allowing a hacker to obtain access to user names, passwords, and other types of sensitive information.
Secure Shell Protocol, or SSH, replaces the functionality of telnet (i.e., access to a commandline from which one can remotely execute commands on the server) with an encryption layer that prevents an interloper from coming between the client and the server. Secure FTP (SFTP) provides a similar encryption layer for file transfer sessions akin to the FTP protocol.
Van Dyke Technologies' VShell for Windows servers (NT 4.0 and 2000) allows remote users to execute commands (SSH) or transfer files (SFTP) securely, provided they are using a secure client that also supports SSH or SFTP (such as Van Dyke's SecureCRT and SecureFX, although alternative compatible clients are available from other developers).
VShell is simple to install. It consumes less than 2 MB of disk space and a handful of megabytes of memory while running. When VShell is first installed it will create a host key for the machine. The system administrator can select the size of this key. VShell advises that a larger key will be more secure but take longer to authenticate, while shorter keys are quicker to create and authenticate, but -- mathematically speaking -- more subject to compromise.
From within the VShell control panel the administrator can tailor the server's behavior. He or she can, for example, limit the number of failed connection attempts from one host before refusing further attempts. He or she may also create individual user accounts and limit those accounts among certain VShell services, including SSH, SFTP, and port forwarding. Connection filters allow or deny connection attempts from IP addresses, hostnames, or entire domains. Extensive logging options create an audit trail for analyzing server activity.
VShell supports the SSH2 protocol for commandline access to the server. Secure clients that do not yet support SSH2 (vs. SSH1) will not work with VShell, although most up-to-date secure clients should feature SSH2 support. VShell can be configured to launch a particular shell environment in Windows for an SSH connection (it defaults to the Windows CMD.EXE shell).
It is important to note that a shell environment is text-only; VShell is not designed to support remote access to the Windows graphical desktop.
Van Dyke offers a variety of licensing options for VShell, which it most generally categorizes as "personal," "group," and "enterprise" levels. These categories define how many simultaneous client connections VShell will allow on one server -- two, 10, and unlimited, respectively. Within each license category the price-per-server varies depending on the number of servers on which VShell will be installed.
Van Dyke's pricing scheme reflects its intention to aim VShell at the business market. The single server version supports two connections and is priced starting at $249. Reduced pricing for educational institutions on these licenses is also available.
VShell inherently presents a convenience trade-off. Supporting telnet access to a server allows remote users to connect from virtually everywhere because telnet clients are ubiquitous (indeed, one is included with Windows). Disabling telnet service and substituting an SSH server like VShell is becoming more common, and in a way limiting, since remote users need a secure client to connect. This is precisely where the increased security comes in. For organizations that place a priority on secure, remote access to Windows servers, VShell is a clean and effective way to sidestep the gaping holes inherent in traditional telnet and FTP tools.
Pros: Very simple set up; Configurable for a variety of user privilege levels; Fast and effective way to replace telnet and FTP, two widely used but highly unsecure protocols Cons: Security comes at the cost of convenience; Users must have secure clients supporting SSH2 (for commandline) or SFTP (for file transfers) to connect with VShell; Pricing scheme is oriented more toward security-conscious enterprises than security-conscious consumers
Version Reviewed: 1.1.1