Windows Server 2003: Secure By Default

Microsoft has made security the focal point of its Windows Server 2003 publicity, especially the publicity that's targeted toward IT professionals. Windows 2003 marketing materials tout Bill Gates's challenge to Microsoft employees in January 2002 to develop a Trustworthy Computing initiative, and product managers and developers from the Windows 2003 security team are taking center stage to convince IT audiences that Microsoft has radically changed the security philosophy of its Windows OSs.

Some of the changes announced with Windows 2003 are completely new functions, such as the Software Restriction Policy (SRP), which can prevent the execution of unapproved applications on any member of a domain. Just as important, though, are changes to existing security mechanisms and OS configuration standards. A key goal in the Trustworthy Computing initiative is to be secure by default. In other words, you shouldn't have to manually harden the OS by tweaking applications and the registry before you can safely deploy the system.

Windows 2000 took an overly innocent approach to object permissions, or ACLs. Although Win2K lets you set ACLs for files, directories, print queues, registry hives, directory shares, and other objects, Microsoft set lenient default permissions for all these objects. In Windows 2003, Microsoft has revised many of those too-lenient default permissions. These changes not only go a long way toward the secure-by-default goal, but they also change what you might have grown to expect as Windows OS defaults. Here are 10 major changes you should know about before installing Windows 2003.

1. New Default ACL for Directory Shares
When you created a new directory share in Win2K or Windows NT, you didn't need to enter any permission options. You simply clicked OK, and all authenticated users had full read/write permissions. Microsoft's reasoning for full-access share permissions was that administrators would restrict access through complementary NTFS file permissions.

That reasoning is contrary to Microsoft's new secure-by-default goal. When you create a share in Windows 2003, permissions are still granted to the Everyone group (i.e., all authenticated users) but only for read access. In other words, Microsoft changed the default ACL for directory shares from Everyone:F to Everyone:R. (This change doesn't alter the default ACL of Administrators:F for administrative shares.) If you upgrade a system from Win2K to Windows 2003, permissions for existing directory shares aren't altered, but all new directory shares created after you upgrade receive the new default ACL. Although administrators will have to take an extra step to assign permissions to specific users when setting up shares, the shares will be more secure as a result.

2. New System Root ACL Option
In pre­Windows 2003 OSs, the ACLs for files and directories had weak default settings. Although the winnt directory and its subdirectories were restricted to administrators, the root of system partitions (usually C:) was set at the same default NTFS permissions—Everyone:F—as the other directories. To remedy this situation, Windows 2003 includes a new option that, by default, sets the ACLs for these files and directories to full access for administrators and no access for every other user.

Windows 2003 administrators who are in the habit of storing data in the C: partition will have to move the data or not use the System Root ACL option. If you're one of these administrators, plan to do the former because using the System Root ACL is a good security measure. You can select the System Root ACL option from within the installation or upgrade process.

3. Service Accounts with Lower Privileges
User accounts are the stepping stones for external intruders. If intruders can log on to a system through an account that has more power than it should have, they can steal or damage potentially sensitive data and they might even be able to use the account to progress to more sensitive areas that require greater authority to access. Some of the most important aspects of Microsoft's secure-by-default goal arrest common account vulnerabilities, including vulnerabilities associated with system services and service applications that need to run with the privileges of a specific user account.

Many system services and service applications need to run under a highly privileged account, so they run under the all-powerful Local System account or an account created with Administrator or Domain Admin authority. If a service contains a security vulnerability (e.g., a buffer overflow) that lets intruders manipulate the server, running the service under such a powerful account gives intruders almost unlimited power to cause damage.

To block such vulnerabilities, Microsoft created two new built-in accounts that can support most services: Network Service and Local Service. Network Service is a domain account that services running on multiple systems can use. Local Service is an account that's local to each system. The Network Service and Local Service accounts don't have the authority to alter other user accounts, shut down systems, or manipulate any of the other administrative functions that can make exploited services so dangerous.

By default, the DHCP Client, Distributed Transaction Coordinator, DNS Client, License Logging Service, Performance Logs and Alerts, and Remote Procedure Call (RPC) Locator services use the Network Service account. The Alerter, Plug and Play, Remote Registry Service, Smart Card, SSDP Discovery, TCP/IP NetBIOS Helper Service, Telnet, Uninterruptible Power Supply, and WebClient services use the Local Service account. You should also use the Network Service or Local Service account for backup, antivirus, and other services and applications you install under Windows 2003.

4. Anonymous Accounts Kicked Out of the Everyone Group
In Win2K and NT, the Anonymous account is a member of the Everyone group. The Anonymous account gives limited access to public Web server users without requiring account or password authentication. However, because the Everyone group is often given permissions to files, shares, and other resources, intruders have found ways to exploit this unauthenticated account.

In Windows 2003, Microsoft has removed anonymous accounts from the Everyone group. The only situation in which this change might cause problems for administrators is if a Web server needs to grant increased access to unauthenticated public users so that, for example, the users can update a file or execute an application. In that case, you can manually add the Anonymous account back into the Everyone group (which defeats the purpose of the added protection) or grant limited file or directory permissions to the Anonymous account.

5. Access Limited for Accounts with Blank Passwords
As with all earlier versions, Windows 2003 servers can grant privileges (e.g., ACLs, group membership) to local user accounts that were created on another system. This arrangement relinquishes some degree of control to the remote system. Windows 2003 servers, however, check the authentication tokens and reject access for any account that has a blank password. This authentication check enforces at least a degree of operational security on accounts that aren't centrally administered and ensures that accounts with blank passwords have little authority.

6. IIS Locked Down
Microsoft security engineers use the term attack surface area to refer to the number of opportunities an intruder has to exploit a system, including the system's services, applications, and network protocols. The most important parts of the attack surface are those that are configurable or optional. (For more information about the attack surface area, see "Using Attack Surface Area and Relative Attack Surface Quotient to Identify Attackability," http://www.microsoft.com/windowsserver2003/techinfo/overview/advsec.mspx.)

Windows 2003 comes out of the box with as small an attack surface as possible. For example, consider Microsoft IIS. By default, IIS is active in Win2K, which means that every Win2K server is potentially a Web server and thus at risk. Many intruders have taken advantage of IIS to exploit Win2K.

In Windows 2003, Microsoft has eliminated this part of the attack surface by locking down IIS. Although Windows 2003 comes with IIS, IIS isn't part of the default installation. If you don't need to run IIS on your servers, you don't need to do anything different with Windows 2003—you can just enjoy the extra disk space and memory you'll have in IIS's absence.

If you need a dedicated Web server, you can install IIS as an option. (You can also use Windows Server 2003, Web Edition, which installs and enables IIS by default.) After you install IIS, you'll find that its functions are initially restricted to foil exploit attempts. Under Windows 2003, the IIS Lockdown Wizard, which Microsoft released for Internet Information Services (IIS) 6.0, is applied. The wizard's default configurations aggressively limit connection timeouts and other configurable settings—a dramatic change from earlier IIS releases. In addition, IIS 6.0 can serve only static Web pages by default. You must reconfigure IIS if you want to support dynamic content. During an upgrade from Win2K to Windows 2003, Windows 2003 disables all aspects of IIS.

7. More Services Turned Off by Default
Many services that were enabled by default in Win2K are disabled by default in Windows 2003. Appendix A in the Microsoft article "Windows Server 2003 Security" (http://www.microsoft.com/windowsserver2003/techinfo/overview/secinnovation.mspx) includes a list of those Windows 2003 services that are turned off by default. This list includes such services as Alerter, Human Interface Device Access, Kerberos Key Distribution Center (KDC), and Telnet. These services are also disabled when you upgrade Win2K to Windows 2003. Many of these services are infrequently used but nonetheless constitute a security vulnerability if left enabled because some of these services (e.g., Telnet) are quite powerful. So, you need to determine your current server needs and enable only the necessary services.

8. Restrictions to NTLM Communications
Many Win2K system exploitations in the past 3 years have taken advantage of seemingly innocuous aspects of the OS. Although Microsoft designers once included extra features and functions that supported outmoded operations, they're now taking a hard look at everything that they add. For example, in an effort to maximize backward compatibility with NT and other early OSs, Microsoft designed Win2K to respond to any NT LAN Manager (NTLM)­style NetBIOS communication. However, Windows 2003 ignores NTLM service requests that haven't been issued by an authenticated source. This change will likely have little effect on applications or operations, but you might want to test any of your server applications that use NetBIOS procedure calls.

9. Signed SMB Packets Required for DC Communications
Unlike Win2K, Windows 2003 requires signed Server Message Block (SMB) packets for domain controller (DC) communications. Authentication and other core networking functions use SMB packets extensively. All packets must be signed unless a client dates back to Windows 3.1 or Windows for Workgroups (WFW). Although this new requirement closes an exploitable vulnerability, it likely won't affect your servers' or applications' functionality.

10. Remote Execution Restricted to Administrators
You can use two services to remotely run commands and programs on systems: Rexec and Rcmd. In Win2K, anyone who had authority to log on to a system and ACL permission to execute a file could use these commands. In Windows 2003, only those people with accounts that have local administrative privileges can use these commands. Before you try to use Rexec or Rcmd in a Windows 2003 system, you should verify that your account (or the account with which you launch a script that includes these commands) has the necessary administrative privileges.

Default Protection
Windows 2003 offers many optional features and functions that you can use to secure your system, such as authentication, forest trust relationships, audit collection, and strong file encryption. However, until you get the chance to deploy those features and functions, the 10 changes I've described can protect your system. Windows 2003's new defaults offer at least some protection to those administrators who never configure anything beyond the default settings.