Security in Microsoft IIS
This chapter is from the book
This chapter is from the book
This chapter is from the book
Chapter 3: Security
In This Chapter
- Unlocking the IIS 6 Server
- Passport.NET Authentication
- Setting the identity of Worker Processes
What's New
IIS has a rather unfortunate reputation of being relatively insecure. This is largely due to a number of relatively high-profile attacks on the IIS platform. In recent years, the most famous of these was the NIMDA worm and the Code Red worm before it, which spread through a vulnerability in the IIS code.
The worm spread very quickly for two reasons. First, IIS was installed and enabled by default on Windows 2000, and was a frequently installed component of Windows NT 4.0 through the Option Pack even if IIS wasn't required. This meant that in many cases, computers that weren't even acting as IIS servers were exploitable. Because it was already installed, many administrators never disabled it and never considered it a threat.
The second problem is more difficult to counter. It's impossible to preconceive every possible attack, and frequently the exploits used by the hackers are either impossible to predict bugs or deliberate attempts to overload the application to the point where the excess of information crosses a crack through which the code enters.
Outside the realm of malicious attempts to break in to your IIS installation, the general security of your machine and Web sites is fairly high. Preventing your users from accidentally finding their way into a secure part of the site is handled through a number of security systems, including both authentication—that is, identifying the user—and authorization—the access rights and restrictions placed on different files, folders, and Web sites according to a user's credentials.
Microsoft has worked hard with IIS 6 to produce a secure environment, countering the potential gaps and problems by denying access or ability to a visiting user unless that feature or area has been specifically enabled by the administrator.
At the most fundamental level, they achieved this by not installing IIS by default. All Windows Server 2003 computers must specifically be enabled with IIS functionality through the Server Roles Wizard. Even when installed, IIS only serves static content, with dynamic processing tools such as ASP disabled, so it isn't possible for ASP or other code to execute on your Web server unless you've specifically allowed it.
Again, even when ASP is enabled, IIS is still in a relatively safe position—because, by default, all worker processes execute using a low privilege account. This prevents malicious ASPs from having access to the various parts of your system, and it also prevents non-malicious scripts from accidentally overwriting or modifying files they shouldn't have access too.
Further improvements in the security of IIS at an application level are offered through an expanded set of authentication methods, including integration with Microsoft's Passport system and improvements to the Secure Sockets Layer (SSL) implementation.
Behind the scenes, outside the direct scope of IIS, there are also some changes to the way the OS operates. Most notably, we can now control and limit the availability of IIS through group policy, allowing you to specify at a domain or OU level which machines can install IIS.
Web Resource
For a review of the security offered in earlier versions of IIS, go to the Delta Guide series Web site at http://www.deltaguideseries.com and enter article ID# A020301.