Hiding your FTP Server Type and Preventing Unauthorized Access
As evidenced by my How to Use Managed Code (C#) to Create an FTP Authentication Provider with Dynamic IP Restrictions walkthrough and my other FTP authentication extensibility walkthroughs, I spend a lot of time trying to find ways to prevent unauthorized access to my FTP server while still allowing valid users to have easy access to their site content. Today's blog discusses several of the ideas that I like to use on my FTP servers.
Preventing Unauthorized Access
To start things off, I globally disable FTP Basic Authentication on my server and I only use custom authentication providers. Since my FTP users do not have actual accounts on my server or my domain, that helps prevent access to my physical server. It was for this reason that I wrote the authentication provider that I discuss in my How to Use Managed Code (C#) to Create an FTP Authentication Provider using an XML Database walkthrough; I can hand out accounts with FTP access for sites that are hosted on my servers, but those accounts are stored in an XML file and not in the security accounts database on my server or my domain.
But there are other ways to help secure your FTP server. For example, I wrote an earlier blog post about Creating a Global Listener FTP Site. On my servers I like to create a global listener site and disable all of the built-in authentication methods.
Once that has been completed I add the custom authentication provider from my How to Use Managed Code (C#) to Create an FTP Authentication Provider with Dynamic IP Restrictions walkthrough, but I don't create any accounts in the database - I just want to log and block the IP addresses of would-be attackers that are attempting to brute force their way into my server. Configuring the authentication options is accomplished through the FTP Authentication feature in IIS Manager.
Ever since I wrote and deployed my dynamic IP address restriction authentication provider, it has faithfully blocked dozens of would-be attackers.
Hiding your FTP Server Type
The next approach that I take is "Security through Obscurity", where I hide the easily recognizable signatures that identify my FTP server. The first step is to suppress the default banner and add a custom FTP banner. This is accomplished through the FTP Messages feature in IIS Manager.
Next, switch your directory listing style to Unix format. All FTP clients that I have tested understand this format, but it hides the fact that your server can do MS-DOS listings. Configuring your directory listing style is accomplished through the FTP Directory Browsing feature in IIS Manager.
After implementing these changes, it might now resemble the following example FTP session when you log in with FTP:
CMD>ftp localhost Connected to DESKTOP.domain.local. 220 Welcome to my server! User (DESKTOP.domain.local:(none)): foobar 331 Password required for foobar. Password: 230 User logged in. ftp> dir 200 EPRT command successful. 125 Data connection already open; Transfer starting. drwxrwxrwx 1 owner group 0 Jan 22 11:45 App_Code drwxrwxrwx 1 owner group 0 Sep 10 10:32 App_Data drwxrwxrwx 1 owner group 0 Aug 17 13:35 bin -rwxrwxrwx 1 owner group 689 May 8 2008 iisstart.htm -rwxrwxrwx 1 owner group 2714 Jan 22 11:54 web.config -rwxrwxrwx 1 owner group 184946 May 8 2008 welcome.png 226 Transfer complete. ftp: 418 bytes received in 0.02Seconds 83.00Kbytes/sec. ftp> bye 221 Goodbye. CMD>
The last step that I take is to block the FTP infrastructure commands SYST and FEAT on the global listener FTP site. These commands respectively display your operating system and list of FTP features. Blocking these commands helps to further obfuscate your server type from attackers.
Note: It is important that you block these two commands only on your global listener FTP site and not on your other FTP sites, because some FTP clients may depend on these commands in order to interact properly with your other FTP sites. That said, if you are working with a small set of FTP clients and none of them seem to have a problem with suppressing the SYST command, you could probably suppress that globally. Most clients that I have tested seem to have no problem with that, especially if you are using Unix directory listings.
In any event, you block the SYST and FEAT commands through the FTP Request Filtering feature in IIS Manager.
Now when you log in with FTP and attempt to use the SYST and FEAT commands, it should look like the following example FTP session:
CMD>ftp localhost Connected to DESKTOP.domain.local. 220 Welcome to my server! User (DESKTOP.domain.local:(none)): foobar 331 Password required for foobar. Password: 230 User logged in. ftp> quote SYST 500 'SYST': command not allowed. ftp> quote FEAT 500 'FEAT': command not allowed. ftp> bye 221 Goodbye. CMD>
Summary
The steps in this blog are certainly not all-inclusive, and I keep coming up with other ideas as time goes on, but following these steps should help to prevent unauthorized access to your FTP service. All of the normal warnings about using strong passwords, changing your passwords often, using SSL whenever you can, and keeping your hotfixes up-to-date will always apply.
But that being said, one of the ways that I keep finding new things to block is by simply watching my FTP log files to see what attackers are trying to do. By using some of the techniques that I discuss in my Using LogParser with FTP 7.x Sessions blog, you can monitor your FTP log files in order to analyze what would-be attackers are trying to do.