IIS 8 FTP
This post began its life as ‘What’s new in IIS 8 FTP’ but has since morphed into something quite different. As the ultimate goal is still to talk about what’s new with FTP for IIS 8, I have retained IIS, 8, and FTP in the title but nothing more.
Many of us are cognizant of the history of the Internet but I will do a quick review to build the foundation of this post. We know that it wasn’t Al Gore’s extensive technical knowledge that built the foundations of the Internet as we know it today, but rather the scientists and engineers of DARPA, the agency formerly known as ARPA. To turn what could be an unbearably long story short, ARPANet, the world’s first operational packet switching network went live in early December of 1969 with a total of four nodes.
The File Transfer Protocol (FTP) standards were published in early 1971 and the FTP protocol has remained the de facto standard for transferring files ever since. When Microsoft developed its own web server, Internet Information Services, as an add-on for NT 3.5.1, it also included FTP. The foundation of their FTP server supporting FTP client connections to transfer files remained largely unchanged through IIS 6. With the introduction of IIS 7, the biggest change with FTP was the introduction of FTPS (FTP over SSL) support. That addressed the security concern of FTP passwords being transmitted over the Internet in plain text.
That brings us to what’s new in IIS 8. The short answer is essentially nothing. The stable work horse of FTP that has been around since 1971 continues as the predominant method to transfer files to your web server. Why has it remained largely unchanged over all these years? Because it just works. If you take the time to look around the FTP settings for your site in IIS 8, you will notice that it looks exactly like FTP on IIS 7.5.
While you are looking around, your web server, you should also take time to look through the FTP logs for existing sites as well as Security Event Viewer. If your server is like most servers I’ve seen, you don’t have to look far to see numerous failed logon attempts to FTP. That has been an issue as long as I can remember which brings us back around (once again!) to what is new in IIS 8 FTP.
Built into FTP server is FTP Logon Attempt Restrictions. From a precursory glance it is not apparent that the feature exists because it is only configurable at the server level and not the site level. Because of that you have to click on the server name in IIS Manager and select FTP Logon Attempt Restrictions.
That navigates us to the FTP Logon Attempt Restrictions feature. There is a calm simplicity to the small number of options but I have found this feature to be extremely powerful in spite of that. Checking a single check box is all that is needed to enable this for all FTP sites on the server. You can configure how many failed logon attempts over the specified period will trigger this. You can also set it to deny the IP address or simply log the failed attempts and take no further action. Let’s take a deeper look into what happens when this is enabled.
Regardless of whether this is enabled or not, all login attempts to your FTP site are logged into a folder under the path you specified named FTPSVCX where X equals the site ID of the respective FTP site. Enabling FTP Login Attempt Restrictions creates a new directory simply called FTPSVC and logs activity related to the feature there. Taking a look at a snippet of that log file from my tests reveals some information.
Either way (active or log-only mode) the feature logs the date, time, server IP address, and client IP address once it is enabled. Also logged are two status codes, sc-win32-status code of 1236, and a sc-substatus code of either 56 or 57. When I was in log-only mode the sc-substatus code was 57, but when I was actively denying the connection the sc-substatus code was 56.
Looking more closely at the sc-win32-status code of 1236, we can run net helpmsg and see that it means ‘The network connection was aborted by the local system.’ That shows us that when we enable this feature essentially the connection is dropped by the server. At the time of this writing I was unable to find the exact meaning of the substatus codes other than observing what I previously mentioned.
One tidbit that is published about this feature is that the connection is only blocked temporarily. The amount of time has not been released by Microsoft which is I highly applaud. While as administrators we want to know all of the details of topics such as this, to continue the effectiveness of this feature it is better that the exact details are not known. Doing so would enable the ill-doers an easier route to circumvent this great security measure.
While there are no major FTP changes in IIS 8 that are apparent to end-users, the addition of FTP Logon Attempt Restrictions makes it well worth moving your site to run under IIS 8.
Rick is a Senior Support Lead at OrcsWeb, a hosted server company providing managed hosting solutions.