The future of Telnet and FTP

BROWSE BY TAG Application Security,   VIEW ALL TAGS

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT Application Security Do Facebook URL security concerns justify blocking social networks? Is there a way to block iPhone widgets that bypass Web filters? Should enterprises be concerned with Twitter in the workplace? Are there still Google Desktop security problems? Can an IP spoofing tool be used to spam SPF servers? Will an application usage policy best control network bandwidth? How can URL-shortening services be manipulated? Is my security program ready for Web application firewall deployment? How to ensure the security of a shopping cart application When to use the service features of the Metasploit hacking tool

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

Because Telnet and FTP are both application layer protocols within the Internet protocol suite I don't believe there is any imminent danger of lack of vendor support. Vendors are trying to make their software's default setup more secure than it has been in the past. This is why you are beginning to see the default installation for OS software disregard Telnet and FTP services. Their philosophy used to be that the installation would install, and in most cases, enable all possible services to demonstrate how capable their software was. It was then up to the security conscious to disable or remove unwanted or vulnerable services from the system. Now that most computers are connected to the Internet, the approach has changed -- now most default installations and settings aim to make the system safe to connect to the Internet without the user having to disable lots of different services. This has to be a step in the right direction.

FTP and Telnet have long been considered a security risk because username, password login information and all subsequent commands are transmitted as plaintext. Secure Shell or SSH is an application layer protocol as well, however, it provides secure encrypted communications over an insecure network and should be used anytime data is transferred which is of a sensitive nature. This is why some vendors are begginning to offer it as a secure alternative for both Telnet and FTP. Also, many Web hosting service providers are limiting or removing Telnet and FTP access for their customers due to security concerns and replacing it with SSH. Although SSH is installed by default, on recent Red Hat Linux systems, SSH software is not part of the typical Windows desktop installation. So, if you use a Windows-based desktop you'll need to install a third party program in order to communicate over SSH to a Red Hat server.

Operating systems will continue to support the FTP and Telnet protocols and I am sure that programs that use these as well, will always be available. However, you should consider whether the security risks of FTP and Telnet warrant their continued use. Keep in mind that older software can be costly to maintain and may not continue to work effectively with newer applications. I recommend retiring software that's old, underused, or over-maintained. To learn more about the lifecycle of the products you are using, contact the vendor. Microsoft has a Support Lifecycle policy at http://support.microsoft.com/gp/lifeselectindex, which provides guidelines for product support availability. Windows 2000 Professional recently retired Mainstream Support, while Mainstream Support for Windows XP Professional runs until the end of 2006 (Extended Support runs until the end of 2011.) Microsoft also recently issued MS05-033, a security bulletin, which alerts users about a vulnerability in their Telnet Client in Windows Server 2003 and Windows XP Professional. This is a separate application to Microsoft HyperTerminal, but shows the importance of vendor support for the products you use.