Applications /

FTP server security

By Mark Gibbs
Network World, 08/20/01

We have spent the last four weeks hacking through the light brush that is the FTP. If you've been following along we think you'll agree that it's a lot easier than tackling the jungles of HTTP or the mountains of SMTP and Post Office Protocol 3.

This week we're going to look at FTP servers. The server that is probably most common for Network World readers is the one that comes with Microsoft's Internet Information Server (IIS).

The version of FTP that came with Windows NT 3.5 was ugly to install, so many people screwed up their installations by leaving security holes big enough to drive a truck through. NT 4.0 made FTP part of IIS and vastly simplified installation and management.

That said, the Microsoft IIS FTP service is pretty vanilla, implementing all the expected features and some that seem odd in this age of heightened security awareness. For example, the default is to allow anonymous FTP access, so if you don't change that setting you'd better know what files are accessible through the service. In all fairness, it must be mentioned that the security issues we're discussing apply to all FTP servers, not just IIS' FTP service.

If you are going to use anonymous access you'd be advised to create "drop boxes" for incoming files - subdirectories that are write-only. Then, for files that are considered acceptable for public access (they have been inspected for hidden dangers), you would need other "outgoing" subdirectories configured as read-only. The downside of this is that you have to check and move files from incoming to outgoing subdirectories.

Now, if you don't take such precautions, don't be surprised to wake up one morning to find that you are hosting an illegal file distribution service for some enterprising hackers. And don't say that will never happen to you - pirate sites on hijacked FTP servers are pretty common and the cost of transferring terabytes of illegal content can be huge!

So let's say you disable anonymous access and have users authenticate through their NT accounts - now it is nice and secure, isn't it? Actually, no, it isn't.

You see, the problem is that names and passwords are transferred across the TCP/IP connection in plain text, so anyone sniffing the network will find out all they need to know to gain access.

This potential account exposure is usually more of a problem in corporate networks than on the 'Net, but if one of your users is on a cable modem system and accessing the corporate FTP server, other users on the same segment could potentially "listen in" with packet sniffers - then you can say goodbye to your corporate security.

The bottom line is that FTP servers should NEVER be used to distribute sensitive material. You could safely use write-only drop boxes for uploading sensitive files, but as there is no support for encrypted client/server connection to the server you'd better encrypt all uploaded files first.

Of course, if you constrain FTP access to circuits created over VPN connections, then as long as the VPN is secure end-to-end, FTP will also be acceptably secure.

Next week, we'll tell you the problem with the SITE command. Until then, make your connection to gearhead@gibbs.com.