Monday, January 30, 2017

Security+ Topic - FTP & Telnet Security (or lack thereof)

Usually the secure protocols that we enjoy today have a rough and shaky past.  This is extremely true for protocols that I can assure will be used by you during your time in IT.  Even major companies are still using these insecure protocols because they are easy to use and reduce customer stress when moving files through the internet.  I am firstly referring to the FTP protocol of which almost every company happily uses.  Secondly I would like to address the use of Telnet which is much less common as a connection method across the internet but widely used on internal networks.

So why not use FTP?  What if I encrypt my files and then transfer via FTP?  What about SFTP?  Well lets talk about each one of these.  At the very basics of the situation is that FTP sends everything in clear text on the wire.  You may have heard of this before but you need to understand what this means.  When you open a network packet, there are of course ones and zeros.  More importantly is that the header of the packet contains everything it needs such as MAC addresses and IP information.  This stuff is required for network travel and cannot be encrypted for the network to work.  The same process used to view the header information is then used to analyze the payload of the packet.  While the actual data (such as a your passwords.xls document) may be encrypted, the FTP protocol itself with authentication information is sent in the clear.

After someone is able to compromise the username and password of your FTP connection, they can then log into the FTP server and grab anything that may have been uploaded.  Even if the files you transferred to the FTP server are encrypted themselves, you are still at risk.  Once those files are downloaded to the attacker computer, they can brute force or password crack a file as fast as their machine or server cluster will allow.  So why are big companies still using it?  Risk vs cost.  Generally speaking it is cheaper to just implement an FTP server and go from there and if something happens, it was the user who decided to transmit their data via the unsecure FTP protocol.

This brings up SFTP or SCP protocols that can be used to transfer files.  Why this hasn’t become the golden standard is beyond me for transferring files.  It is entirely possible to setup the SSH server (SSH is used for the SFTP/SCP to move data) that is locked down to nothing but transferring those files.

On a final note of this whole transmitting in clear text issue is Telnet.  Telnet has been historically used for the management of network routing and switching.  It is possible to have a server setup with Telnet but most IT admins are very aware that if they allow a telnet connection, they are basically opening the server to the world.  Telnet transmits everything, and I mean everything, in clear text on the wire.  This means that if you type “my password is abc123”, whoever is looking at the packets will see it word for word.  Being that everything can be viewed, unless you are on an extremely secure network being one hundred percent sure that no one was sniffing the wire, you could log into a device to reset the password whereupon you log out and the attacker will know exactly what the new password is.

Whats the moral of the story?  STOP USING FTP and TELNET!  If for some reason your device doesn’t support SFTP/SCP/SSH then there are alternate methods of connecting to that device.  One item I will specifically mention here is a Linux server with a console connection to an older Cisco router.  The older routers only supported Telnet but if you can SSH into a server, then console in the router, you completely eliminate the insecure protocol from the equation.

No comments: