The perils of running an unsecured FTP server

Last week I got hacked.

I’d opened up my previously stealthed firewall to:

  • Access my home network when I’m at work;
  • Allow one of my friends to post some large files to my FTP server.

The trouble is that I hadn’t been carrying out the best practices that I would advocate for my enterprise clients. Despite last month’s post on securing IIS, I had just opened up the standard ports to a standard IIS server which wasn’t even in a demilitarized zone (DMZ).

I didn’t think I’d be a target for a hacker but within a few days some guys in Italy and Belgium had started abusing my FTP server to dump their files (this article from ZD Net leads me to believe that it’s a common practice). I don’t know what the contents were. I deleted them quickly to be safe and shut down the firewall until I could implement something more secure.

Thankfully, I got off lightly (this time). I checked the logs last night and my new security measures are keeping the intruders out. If you do need to provide an FTP service, you might like to read the windowsecurity.com article with 10 steps to secure an FTP server.

2 thoughts on “The perils of running an unsecured FTP server


  1. One thing that is not clear in much of the documentation on securing a (Windows) FTP server is how to allow users to log on to the server once anonymous access has been disabled. The key point is to allow users to log on locally to the server (either using the local security policy MMC snap-in, or through group policy in an AD environment). Once you have allowed a group to log on locally, simply adding the appropriate accounts to that group should be sufficient to control access.

Leave a Reply