As I just mentioned, the most important feature of Windows Server 2003 is the .NET Framework. In last month's article, Reduce Application Development and Deployment Costs with Microsoft Windows Server 2003, I explained why I think this is the case; here is a quick summary of the key points: Its first and most important benefit is simply that it is there, backed right into the OS; you don't need to think about it or worry about whether a machine will have the .NET Framework. Starting with Windows Server 2003, you just know it's there. The productivity gains from Base Class Library and the declarative programming style simply reduce the number of lines of code you need to produce, which translates into savings in both development effort (obviously) and maintenance (also obvious but often overlooked). Because Windows Server 2003 is built on open standards, it makes integration much easier because you can deal with common APIs, protocols, and data formats rather than having to custom-code support for a variety of proprietary systems. Additionally, these open standards make development projects more modular. Finally, I looked at XML Web Services and how they will reduce the total cost of ownership of new applications because the model is so easily extensible.
 

Once you've used Microsoft .NET to build a server-side application, you need to configure an application server to host it. To simplify that process, Windows Server 2003 includes the CYS wizard. To use this wizard, simply select the Add Or Remove Role Link from the MYS screen that greets you when you first install the operating system shown in Figure 1.

Figure 1: The MYS wizard that greets you when you first install Windows Server 2003.

The CYS wizard in Windows Server 2003 is similar to the CYS menu in Windows 2000. However, the new version is based around roles rather than features. This makes it easier to use and provides a better match for how people approach configuring new servers. In this example, when you select the Application Server role as shown in Figure 2, the CYS wizard guides you through securely configuring a new server with all the components necessary to make Windows Server 2003 a great host for your .NET applications. The wizard groups together all the components required for an application server and enables you to install them as a single package. You don't have to worry about forgetting to install all the required components or accidentally installing ones you don't need.

Figure 2: The Application Server role walks you through securely installing and configuring the components required to turn Windows Server 2003 into an application server.

When you select the Application Server role, the CYS wizard installs IIS 6.0, the Application Server Console, and enables remote access to COM+ and the Microsoft Distributed Transaction Coordinator (DTC). Additionally, you have the option of enabling FrontPage® Server Extensions or ASP.NET or both. Most of these components should be familiar if you have used earlier versions of Windows. The Application Server Console (shown in Figure 3) is new by name but the functionality should be familiar; it is a standard Microsoft Management Console (MMC) that contains the .NET Framework Configuration, IIS, and Component Services snap-ins.

Figure 3: The Application Server console provides a single tool to manage the .NET Configuration, IIS, and your COM+ components.

It's important to realize that Microsoft Message Queue (MSMQ) is not installed as part of the Application Server role. If your applications require MSMQ, you will need to install it separately through the Add or Remove Programs applet in Control Panel.

Now that you know how to configure your new Application Server, take a closer look at two new features, COM+ and IIS. (For information on the other components, see Jerry Honeycutt's Introducing Microsoft Windows Server 2003.)

COM+ 1.5 includes a number of enhancements that make it easier to build robust server applications. The most talked-about new feature is the ability to partition applications. This enables you to have multiple versions of the same COM+ component installed on a single system. A related feature is Component Aliasing, which enables you to take one physical component and provide several different logical configurations of it.

To help you debug your components, you can now dump an image with the entire state of your COM+ application at runtime without killing the processes. Once COM+ has created the dump, you can load it into WinDbg (or your favorite debugger). This is a huge boon to developers because we are no longer forced to choose between maintaining system availability and debugging faulty applications. COM+ now supports recycling of applications, which enables you to dramatically increase the availability of even the buggiest applications. Say you have inherited a buggy application that has a subtle memory leak. Rather than simply waiting for the application to fail (or worse yet, bring down the entire server), you can configure the application to automatically recycle based on several criteria such as amount of memory used, number of times it has been called, or the amount of time it has been running. As an example, you could configure your application to recycle itself every two days or whenever its memory utilization increases beyond 1 GB.
   

Of the components installed as part of the Application Server role, the one that has changed the most is IIS. The changes fall into two broad categories. First Microsoft re-architected the entire process model to allow for individual applications to be completely isolated from one another yet still communicate directly with the new kernel mode HTTP listener. As a result, applications are much more stable (a single bad application cannot affect any other application), and performance has increased (because there are fewer context switches).

In next month's article I will go into the details of the new process mode, but this month I want to spend the remainder of the article covering some changes to the security model.

A key goal of the new security model is to take a defense-in-depth approach. The idea is to place as many hurdles in the way of a potential attacker as possible. Let's take a look at some of these barriers.

First, the most obvious change to IIS 6.0 is that it is no longer installed by default. If you want a new installation of Windows Server 2003 to respond to HTTP requests, you must explicitly install IIS. An attacker can't penetrate something that isn't installed.

By default, IIS 6.0 serves only static content such as HTML files. If you want it to serve up dynamic content, you must configure IIS to do so. Furthermore, IIS only responds to requests for files with known extensions. For example, when you enable ASP.NET, IIS executes files with an ASPX extension, but will return a File Not Found error (404) for files with an ASP extension even if the files exist. If you want IIS to process ASP files, you need to specifically configure it to do so. Although this can be a bit frustrating at first (it was for me when I couldn't get my HelloWorld.asp test page to work), it does have its advantages-it makes it more difficult for an attacker to exploit a new vulnerability because you would have had to enable that exact file extension first.

Even if an attacker were able to locate a vulnerability, IIS 6.0 runs under a low privileged account which greatly reduces the amount of damage a user can do. Additionally, the Web server cannot execute command line tools  (cmd.exe, ftp.exe, format.com), and the anonymous user does not have write permissions to the Web content directories, so defacing attacks are more difficult. Therefore, even after finding and exploiting a vulnerability, an attacker would still need to elevate his or her privilege (which is made more difficult because IIS runs under a low-privileged account) to do any damage.

As a final protection, the IIS worker processes will exit if they detect a buffer overrun.

Besides defense in depth, Microsoft has made great strides to reduce the attack surface of IIS 6.0. Let's look at some of the steps they have taken and then apply the same lessons to your applications.
 

As I mentioned above, the first change everyone notices about IIS 6.0 is that it is not installed. This approach is part of Microsoft's overall effort to reduce the attack surface of its products. The idea behind this is quite simple; the more services are installed by default and the more ports a server listens on, the more potential entry points you open up for attackers. The same theory explains why only known extensions are executed.

You can reduce the attack surface of your application in one of two ways. First, limit the number of entry points or interfaces your application supports. This is especially important when it comes to deprecated functionality because you probably wrote the supporting code long ago when there were fewer ways of exploiting vulnerabilities and before security became such an important issue. Therefore, this old code probably has not been reviewed with the signatures of the latest attacks in mind. By disabling ASP files by default, Microsoft has made it less likely that an attacker can exploit old asp code that has never been reviewed. Second, if there is a feature in your application that is used infrequently or only by a subset of your users, disable it by default like Microsoft did with IIS. If particular users wants to use that specific feature, they will know that they want the feature, and they can always enable it. The converse is not always true; a user may not know all the features included in your application and therefore may not know which ones are unnecessary and can be turned off.

By limiting your application's attack surface, you gain three important benefits:

• It is harder for an attacker to compromise your system because there are fewer entry points. Just as you secure a building, a public place, or any other location in the physical world by limiting the number of access points available to people, you secure software by limiting the number of ways one can connect to your system. With a smaller attack surface, it is less likely that an attacker will succeed in compromising your system.
• Because you have fewer entry points, it is, from a statistical standpoint, less likely that your system is vulnerable. Furthermore, because you have fewer interfaces to develop, you have more development and testing resources you can devote to each one to make sure each one is as robust as it can be, and there are no bugs that compromise security.
• With fewer entry points, it is easier for administrators to monitor exactly who is accessing a server and what they are doing. This helps address the audit overload that often overwhelms administrators. With so much data to analyze, administrators often find it difficult to separate the important log entries from all the noise. By decreasing the attach surface of your application, you make your application easier to monitor and increase the likelihood that your administrators can quickly identify any unauthorized activity.

This month I started off with a quick review of last month's article, Reduce Application Development and Deployment Costs with Microsoft Windows Server 2003, and the benefits of including the .NET Framework in Windows Server 2003. I then covered how you can configure Windows Server 2003 as an application server using the new role-based CYS wizard. Next I talked about some of the enhancements in COM+ 1.5 such as application partitions and application recycling. Finally, I detailed some of the security changes in IIS 6.0 that help you provide defense in depth and reduce the attack surface of your applications.

As I mentioned at the beginning of the article, Jerry Honeycutt's Introducing Microsoft Windows Server 2003 is the best place to learn about Windows Server 2003.

Check out the following resources for information related to developing for .NET.

Books about Microsoft .NET

Books about Developer Tools and Technologies

MSDN® Web Services

To learn more about designing and building secure applications, you will want to pick up the new second edition of Michael Howard and David LeBlanc's book Writing Secure Code.

For a more broad overview of all the .NET technologies, you should look at David S. Platt's Introducing Microsoft .NET. It has some great information on COM Interop, Windows Forms, and .NET memory management.

For information on developing for Windows, you will want to read Inside Microsoft Windows 2000, Third Edition, which provides the definitive guide to the internals of Windows 2000. The Microsoft product team wrote this book with full access to the source code, so you know you are getting the most comprehensive, technical information available.

Another great resource is Programming Server-Side Applications for Microsoft Windows 2000. It takes an in-depth tour of Windows 2000 services and provides expert guidance for designing and implementing applications that exploit their capabilities.

Finally, you will want to consult Active Directory® Services for Microsoft Windows 2000 Technical Reference. This practical guide to planning and deploying the Active Directory will help you design your applications to be better network citizens.