News: IIS 7.0 tackles security, manageability, the metabase, and componentization
This just in, from the department of the painfully obvious: Security was your biggest concern in this month's survey about Microsoft IIS.
Of course, this non-news came as no surprise when I discussed readers' responses to our IIS survey with Microsoft Group Product Manager Eric Feagler (Web platform and tools marketing) and IIS Product Unit Manager Bill Staples. As Eric noted, "Security is top of mind for at least two-thirds \[of the 392 respondents\], and we're really focused on that."
"Security has to be job one," commented one reader. Another said, "I am not concerned with functionality. I am very concerned with security." Delving into that theme, I found that readers weren't simply asking Microsoft to lock down IIS 7.0, as the company has already done with IIS 6.0. Rather, readers view security as integral to every aspect of IIS and want security improvements to be reflected in better manageability—including dumping the infamous metabase—and reduced complexity. One respondent succinctly requested "more security focus, security tools, security control."
Eric and Bill talked to me about how IIS 7.0, which is now in beta, addresses those concerns. "Managing the attack surface, the footprint of the server, is key in IIS 7," Bill explained. "The changes span all aspects of the server, from making it easier to manage, control, and delegate configuration tasks, to the way that the core Web server is implemented and extensibility, right down to the way you diagnose and troubleshoot the server when things start going wrong."
Under New Management
These changes align with survey feedback, particularly with regard to manageability. One reader simply demanded, "Please make it easier to manage."
Bill (who manages the IIS engineers, developers, testers, and program managers) replied, "IIS 7 has a new administration tool that makes managing the server much easier. Management was a top problem because, in 1994, we built a new admin UI for Windows NT 4.0 and IIS 4.0. In 2005, we had the same UI, and we'd added radio buttons, check boxes, and tabs. The result is really complex with lots of features. You have to know where you're going to make it work. For IIS 7, we wrote from scratch a task-oriented admin UI."
Answering a reader who suggested, "Why not forget the management console and build a dedicated IIS front end for people who have to manage sites?" Bill said, "The new UI lets both the administrator who manages the box and the Web site administrator or developer use the same tool. Site admins complain about IIS management because they have to either write scripts or ask the machine administrator to change a setting. With IIS 7, the machine admin can delegate control in a very granular way to the site admins and let them self-service."
Bill continued, "We also added ASP.NET features because we often hear that customers can manage IIS in one place, but ASP.NET is in a completely different configuration store. We now have one admin tool, but there are 50 or 60 features to manage. How do you find the one you want? With this new UI, which can run standalone or as an MMC snap-in, a pop-up lets you narrow down the list of administration options. If you just want security settings, you can click on the security filter and you see only security options. Also, you can multiselect. If you select security and diagnostics, you see just the features for those two areas. It's much faster than searching through tab after tab."
Troubleshooting is another management task that readers want Bill's team to address. In particular, readers asked for "a real-time activity monitor so I could easily see what's going on now and potentially react."
Bill agreed. "Troubleshooting a server is difficult today. IIS is essentially a black box: Requests come in, and most of the time they come out OK. But when they don't, it's almost impossible to tell what went wrong. With IIS 7, we automatically capture trace data. Suppose you're seeing Server 500 errors—a common server failure—every so often.You can tell IIS to monitor a specific area on the Web site, or the entire site, or the entire Web server for those errors. When IIS detects that condition, it logs a detailed trace stack of everything that happened for that request so you can see exactly where that failure happened."
Also, IIS 7 exposes "internal state information in real time," Bill added. "A common issue is that occasionally, IIS will spin up the CPU to 100 percent and just sit there. You have no idea why. You can kill the process, but the next request takes usage back to 100 percent. Often the cause is code that has an infinite loop. IIS 7 has a new Runtime State and Control API that lets you see the status of all applications, application pools, worker processes, and sites on the box. In real time, you can see requests as they flow through the server. If one is taking the CPU to 100 percent, you can pinpoint it and turn off that site or investigate that URL to see what the code is."
Death to the Metabase!
A notorious management headache in previous IIS versions was the metabase. "The metabase is a pain. What is being done with it?" was a typical reader question. Bill agreed, "In IIS 6, metabase.xml is the configuration store from hell. It's ugly. You open it, and unless you're a real technical expert, you can't make sense of it."
Bill seemed pleased to announce, "We finally killed the metabase with IIS 7. We now have one configuration store based on the .NET configuration store. It's the same basic system as web.config or machine.config. There's a configuration file for IIS settings, and for any Web site or application, you can store IIS or ASP.NET settings in the same web.config file in the \windows\system32\inetsrv\config directory. The new files are XML, but they're easier to present, use, and interact with, and the schemas are cleaner."
For example, Bill said, "Think about configuration properties such as access flags (a property that controls what type of access the request can have—e.g., read only, run as a script, executable). You can configure a property, and then, depending on the request, IIS will do different things with the URL. We stored that configuration in the metabase XML file as a bit mask, which is a binary format (e.g., binary 5, 3, 1) that represents those attributes (e.g., read, script, execute). Unless you know what binary 5 means, or binary 3, or binary 1, you have to look it up. Well, now words represent those things. Instead of saying "access flag equals 5," we say "access flag equals read." Also, instead of using Boolean values—0 or 1—we have true and false. We got rid of GUIDs and binary BLOBs in the metabase. We still encrypt passwords, because, obviously, you don't want clear-text passwords in the file."
From One DLL to Modules
Many readers rated hotfixes and consequent reboots as top concerns. Bill's answer: componentization. "Today the core Web server does all the request processing—response caching, request parsing, authentication, authorization, ISAPI \[Internet Server API\], CGI \[Common Gateway Interface\], etc. All those features are implemented in one DLL, one binary. In IIS 6, we turn features off by default, but that binary is always installed with the Web server and all those features are always available."
CGI is an example. "It's always on the IIS 6 box, whether you use CGI or not. It's off by default in IIS 6, but it's always there. So if a CGI patch comes out, you have to install it. With IIS 7, we've ported all those features that were previously baked into that one DLL on top of a new API, and we're porting them as individual modules—individual DLLs. So now if you're not using CGI, you don't have to install the CGI module. We now have more than 40 modules you can add and remove independently, which helps admins reduce their attack surface more than ever. Also, if you're not using the CGI module and a CGI patch comes out, you'll never even see it because the binary that implements it is not on the box."
What about rebooting? "A lot of the binaries that run inside the worker process are already installable without a reboot," Bill explained. "You can install the patch and recycle the worker process, and it automatically picks up the new DLL. Actually, I don't think there's any IIS reason for reboots. Sometimes you have to restart the service, but no reboots. Often, rebooting results from the patching infrastructure for Windows OS, but the Windows team is also working to minimize reboots."
Are We Secure Yet?
The security strategy for IIS 6 was locking down potential attack vectors. "As a result," Bill pointed out, "we haven't had a single critical security fix for IIS 6 since release." However, my takeaway from talking with Bill and Eric was that they realize they have to go beyond lockdown with IIS 7 and rebuild the product to incorporate security throughout.
Eric said they recognized that "there's a hangover effect from NT 4.0. Back then, we designed IIS for ease of use and getting up on the Internet fast. Code Red and Nimda cost our customers millions of dollars and hours of downtime. That's why now we think about how far out will security go."
Bill added, "Customers want Microsoft not only to prevent security issues but also to be proactive by helping customers stay secure in terms of detecting new vulnerabilities and helping customers understand how to cope better with the hostile environment on the Internet. So because of the secure defaults, internal code reviews, and new features we've built in, IIS 7 has multiple layers now protecting customers."