3

I am a newbie, so maybe I'm missing something. Why would anyone use ftp or telnet for site administration? If they use them, why would they wonder how they've been hacked? Isn't it obvious that all this stuff should go over sftp, ssh, or an https connection? Or am I just paranoid?

5 Answers 5

7

The right answer is somewhere between the size of the install-base of FTP and Telnet, and the relative complexity of SSH/SFTP. Every SSH client I'm aware of gives a big scary warning like:

The authenticity of host 'example.com (10.0.0.1)' can't be established.
RSA key fingerprint is 17:cf:fb:1c:82:19:39:12:b1:76:a6:a1:8a:ff:34:75.
Are you sure you want to continue connecting (yes/no)?

Instead of the more helpful:

You haven't connected to 'example.com (10.0.0.1)' before. 
Please verify that its RSA key fingerprint is:
   17:cf:fb:1c:82:19:39:12:b1:76:a6:a1:8a:ff:34:75
and if not, contact your network administrator for advice.

while FTP clients don't pop-up a similar warning, so on presence alone: FTP is simply less scary.

That said, there are real reasons to consider using FTP and Telnet that aren't motivated by being ignorant:

FTP may be faster

On a trusted, switched, and managed network, there's little risk of packet sniffing that doesn't also involve root compromise. On my primary dev server, SFTP maxes out at 11mb/sec where FTP can get around 70mb/sec.

Note using HPN-SSH is almost as fast as FTP, so if you don't mind replacing all your ssh servers, and tracking upgrades, and merging in the patch manually (because it doesn't apply to the current SSH tree), it might be a better approach.

There aren't many files that would benefit from a 7x speed boost, that also contain privileged data, but backups are one of them. IPsec doesn't introduce as much latency as SSH, so tunnelling FTP through IPsec may be a reasonable middle-path.

Telnet may be safer

On a system that is only accessed via a trusted, switched, and managed network, there's little risk of packet sniffing that doesn't also involve root compromise, but putting an ssh server on your router might be riskier than you think.

Meanwhile ssh access to a secret serial console server that requires portknocking provides even greater security, and it's more likely that you can keep it safe.

3
  • Hmm, I overlooked the trusted network case.
    – chernevik
    Nov 24, 2009 at 17:49
  • 1
    I'm sorry but even on a trusted network I would NEVER use FTP or Telnet to connect. Passwords are just too simple to grab off the wire.
    – Dscoduc
    Nov 28, 2009 at 20:13
  • 1
    Sniffing a trusted network involves breaking root on either of the communication partners, or breaking a managed (and correctly configured) switch. Alternatively using SSH everywhere means the attacker has to break root on the partners, or break the SSH implementation or its keys. As the network administrator, it's your job to determine what's more likely; in my case pushing my backups with FTP means my throughput is 7x over ssh, which means instead of a backup every week, I can take a backup every day.
    – geocar
    Nov 30, 2009 at 13:50
7

Some are:

  • Legacy -- ssh/sftp isn't always an option
  • Laziness / Ignorance
  • Not everything needs to be secured (For example, downloads of Adobe Acrobat)
  • For telnet, security could be provided in another way, for instance, IPSec encapsulation
4
  • 1
    Even when SSH is an option, sometimes its hard to sell on having to buy a more expensive IOS for your switches just to access them with SSH over telnet.
    – sclarson
    Nov 24, 2009 at 15:18
  • sparks: Ya, in that situation you could just have a server you ssh into, and then is connected to the console port on the switches. Nov 24, 2009 at 15:19
  • 5
    You're right - downloads of Adobe Acrobat need to be prevented.
    – RainyRat
    Nov 24, 2009 at 15:20
  • Upvoted for legacy. I have systems that need transfers from mainframe so FTP is the method they choose/use to transfer files.
    – SQLChicken
    Nov 24, 2009 at 18:59
3

Pure unadulterated inertia. The user doesn't understand why FTP is such a bad idea, so they refuse any attempt to move them to something better.

1

People still use FTP/telnet for much the same reason they still use IE6. Established applications have inertia. It takes effort to change and so it takes time to replace existing way of doing things. Remember that FTP/telnet are >20 years old. There's lots of existing procedures and devices that rely on them.

(Most) new procedures/devices being built use newer protocols and the old ones that aren't upgraded will eventually fall off via attrition.

EDIT: Telnet is still useful as a debugging tool to test connectivity to remote computers.

telnet example.com 80
1
  • The BSD telnet client in this case is just a generic TCP client. You could use more featurecomplete alternatives like netcat or one of its forks as a "debugging tool".
    – joschi
    Dec 9, 2009 at 0:07
0

It's easier to give untrusted users FTP access than SFTP access. With SFTP you have to give them ssh access and then go to the trouble of disabling everything they could use that isn't FTP-related. With FTP, they don't even have to be real users (real being users on the OS with home folder and such). There's also a method of doing FTP with SSL, but I've always found SSL to be a pain to deal with.

This isn't to say that FTP is a good idea, but I could see why administrators would still set it up.

3
  • That's not correct. You can also use virtual users with SSH or SFTP. Remember: SSH is just a protocol, not a concrete implementation (like OpenSSH) - just in the same way FTP is just a protocol and not a concrete implementation (like vsftpd, ProFTPd...).
    – joschi
    Dec 9, 2009 at 0:09
  • It doesn't change the fact that it's easier to do with FTP. Dec 10, 2009 at 8:00
  • Why vote this down? This is the exact reason I still use FTP for some stuff. I know it sucks but it's just so simple. Jan 16, 2011 at 20:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .