Readers of this blog may recall that, last year, my open FTP server was hacked. That experience taught me a valuable lesson and earlier today, I needed to establish a secure FTP server installation using Microsoft Internet Information Services (IIS) 5.0 (well, as secure as you can with a protocol that passes authentication details in clear text – of course, there are SSL-secured alternatives available).

The first step was to install only the essential components of IIS, using the unattended IIS installation method that I posted last year.

Once installed, I ensured that the server was fully patched with all relevant security updates before working through the advice from the 10 steps to a secure an FTP server article on windowsecurity.com as well as some more advice which was given to me last year by Craig Schofield, a consultant from Microsoft who was working alongside me at the time:

• Change the default port number for the site from 21 to a non-standard port. This is security through obscurity; however it may not be suitable depending on the clients used to connect to the server.
• Remove all other protocols, using the IIS Lockdown tool to remove sample sites, other protocol mappings (e.g. WebDAV if installed) and to ensure that only the FTP Publishing Service is available (note that there is no point in installing URLScan for FTP servers, as it only applies to HTTP requests).
• Use anonymous access, and only anonymous. This ensures that no security credentials details are passed over the wire (remember, FTP uses clear text for authentication). If user authentication is necessary, use a dedicated account that has no access to any other systems, files or components and the recommendation is to create a local or domain local group, assign this group the required permissions (log on locally, NTFS access), and add users to this group (removing them from the Users group).
• Enable FTP logging, and ideally propagate all logs to a central location. Monitor logs for sign’s of attack/penetration.
• Use a virtual private network (VPN) connection between machines, to ensure that all traffic is encrypted. Alternatively, create a secure IP (IPSec) tunnel between server and client.
• Limit the number of FTP site connections to the maximum expected number.
• Assign NTFS security restrictions to the user/group accounts used to access the FTP site.
• Ensure any virtual directories are also protected by NTFS permissions, and are directed at secure locations (not C:\ for example).
• Change the default home folder for the FTP Site from C:\InetPub\ftproot to another folder (preferably not on the C:\ drive so as to avoid a denial of service attack by using all available storage on the system disk)
• Ensure appropriate steps are taken to secure the other accounts on the machine (disable Guest, rename Administrator, assign complex passwords).

Of course, operational requirements will mean that it is not usually possible to implement every one of the above measures, but each one adds to the principle of defence in depth.

Whilst checking my configuration, I came across Microsoft knowledge base article 318380, which lists IIS status codes for HTTP and FTP as well as providing links to the original World Wide Web Consortium (W3C) definitions and some common status codes and their causes.