HostPapers - article What IIS Security?

It is possible to achieve and maintain an adequate level of security for Internet Information Services (IIS), Microsoft's Web server platform. If I didn't think this, I wouldn't have agreed to write a regular column on the topic.

This is not to say that IIS security is a trivial task. There are plenty of challenges involved in making and keeping any Web server secure. Hence this column, which I hope will be a useful place for anyone interested in the topic to catch up on Microsoft IIS security fundamentals, keep abreast of the latest issues, and anticipate future challenges.

Having said that, there is no denying that IIS has not always been as secure (or securable) as it needed to be, has become, and is becoming. That is where the reputation comes from, making the phrase "IIS Security" a source of potential amusement for harried sys admins. On balance, IIS' reputation has long since outrun reality here, but that reputation is fed by a real legacy of sub-par security. To inaugurate this column, we will take a hard look at the sources of IIS’ legacy of insecurity, the reasons for its persistence, and the way progress against this perception has been made.

A Legacy of Trust

The first thing to consider is the platform on which IIS emerged and to which it has remained bound. The first widespread use of IIS to host Web sites began with IIS 4.0 on Windows NT Server 4.0. But although NT 4.0 was a substantial improvement over previous versions of the Windows OS, it never completely overcame their influence. In particular, the OS had to contend with the fact that Windows had taken off as a server for fundamentally trusted environments -- LAN environments rather than WAN environments. In effect, NT was a desktop OS that matured to the point where it became capable of working the server end of the client/server equation.

Raised in a Sheltered LAN
When it came to Web or HTTP servers, NT's LAN heritage gave IIS obvious advantages as an intranet host in shops with Windows (or a mixture of Windows and MAC) on the desktop. These same advantages remain IIS selling points to this day: ease of configuration, multiple administration options, and abundant out-of-box functionality. But this also meant that IIS got into the HTTP business primarily in an environment where the trade-off between functionality and security could almost always be safely decided in favor of the former. Because of this, IIS security features had taken a backseat early on, and the urgency for improving them was relatively low. A good example of this is the long IIS dependence on the FAT file system and its lack of real access control capabilities.

Another aspect of this same LAN bias was IIS's ability to serve as a general purpose server rather than a Web server per se. This too was in line with the kind of role flexibility expected of NT boxes. In a small shop, a single NT box might be file server, database server, mail server, and intranet server -- all in one. You can see this bias toward multiple roles in IIS itself with its integrated HTTP, SMTP, FTP, and NNTP components, all under the IIS administration services umbrella. It was a sign of the low general degree of security consciousness that one was invited to install and run so many disparate services, when all one really needed was a Web server.

It's Not My Default
A more general effect of the LAN legacy are the remarkably loose default settings which have bedeviled, or at least made extra work for, IIS administrators right on through IIS 5.0 / Windows 2000. Even once NTFS and user/group file system ACLs became possible, the default posture remained that of a system expected to work first and be secured later. Only a server that has its roots in a trusted environment would have given us something like the Everyone group and its default permissions. Or think of the sheer number of superfluous services that often have to be turned off to make an IIS box secure in a WAN context.