Perhaps the single greatest improvement in security over Windows 2000 is not a technology but a procedure. Windows 2000 installed Internet Information Server by default, it installed OS2 and Posix subsystems, and it offered little insight into the implications of installing various services and applications. Windows 2003, on the other hand, introduces the Configure Your Server Wizard. This wizard launches by default when a Windows 2003 server is first built. It asks the installer what the intended role of the server is and makes the appropriate changes on the system. Files are installed, service securities are set, and the administrator can feel comfortable that the system hasn’t installed unnecessary services. This alone eliminates the largest cause of system insecurity—misconfiguration.

One of the new technologies introduced in Windows 2003 is Internet Information Services 6. IIS was redesigned in Windows Server 2003 to further improve security for Web-based transactions. IIS 6 enables you to isolate an individual Web application into a self-contained Web service process. This prevents one application from disrupting other applications running on the same Web server. IIS also provides built-in monitoring capabilities to find, fix and avoid Web application failures. In IIS 6, third-party application code runs in isolated worker processes, which now use the lower-privileged Network Service logon account. Worker process isolation offers the capability to confine a Web site or application to its root directory through Access Control Lists (ACL). This further shields the system from exploits that walk the file system to try to execute scripts or other built-in code.

Windows 2003 has also improved network communication security through the support of strong authentication protocols such as 802.1x (WiFi) and Protected Extensible Authentication Protocol (PEAP). Internet Protocol Security (IPSec) support has been enhanced and further integrated into the operating system to improve LAN and WAN data encryption.

Microsoft introduced the Common Language Runtime (CLR) software engine in Windows Server 2003 to improve reliability and create a safer computing environment. CLR verifies that applications can run without error and checks security permissions to ensure that code does not perform illegal operations. CLR reduces the number of bugs and security holes caused by common programming mistakes. This results in less vulnerability for hackers to exploit.

Another technology introduction in Windows 2003 is the concept of Forest Trusts. Windows Server 2003 supports cross-forest trusts, allowing companies to better integrate with other companies that use the Active Directory. Setting up a cross-forest trust with a partner’s Active Directory enables users to securely access resources without losing the convenience of single sign-on. This feature enables you to use ACL resources with users or groups from the partner’s Active Directory. This technology is a great boon in situations where one company has acquired another. Establishing a cross-forest trust allows the two companies to immediately start sharing resources in a secured manner.

The idea of single sign-on is further improved by the introduction of Credential Manager. This technology provides a secure store for usernames and passwords as well as links to certificates and keys. This enables a consistent single sign-on experience for users. Single sign-on enables users to access resources over the network without having to repeatedly supply their security credentials.

Windows Server 2003 supports Constrained Delegation. Delegation in this context means allowing a service to impersonate a user or computer account to access resources on the network. This new feature in Windows Server 2003 enables you to limit this type of delegation to specific services or resources. For example, a service that uses delegation to access a system on behalf of a user could now be constrained such that it could only impersonate the user to connect to a single specific system and not to other machines or services on the network. This is similar in concept to the ability to limit a user to attaching to a restricted list of systems.

Protocol Transition is a technology that allows a service to convert to a Kerberos-based identity for a user without knowing the user’s password or requiring the user to authenticate via Kerberos. This enables an Internet user to authenticate using a custom authentication method and receive a Windows identity. This technology is now available in Windows 2003. This can be very useful for companies that are planning to heavily leverage Kerberos as a centralized point of authentication for both Windows and Linux systems.

Windows Server 2003 now offers .NET Passport Integration with Active Directory. This enables the use of Passport–based authentication to provide partners and customers with a single sign-on experience to Windows–based resources and applications. By leveraging .NET Passport services, companies can often reduce their cost of managing user IDs and passwords for applications with large numbers of external users. Microsoft has gone to great lengths to ensure that .NET Passport information is stored as securely as possible to foster confidence in the industry and help grow the technology.

Although Windows 2000 supported encrypted folders, Windows Server 2003 now allows offline files and folders to be encrypted using EFS as well. Offline Files, or client-side caching, was introduced in Windows 2000 and allows mobile users to work with a local copy of a file while disconnected from the network. When the user reconnects to the server, the system reconciles the changes with the older versions of the documents on the server. This allows files to continue to be protected when cached locally on a mobile computer.

Stronger encryption technologies for EFS are available in Windows 2003. Windows Server 2003 now supports encryption for EFS that is stronger than the default Data Encryption Standard (DESX) algorithm. By default EFS will use the Advanced Encryption Standard (AES-256) for all encrypted files. Clients can also use Federal Information Processing Standards (FIPS) 140-1 compliant algorithms, such as the 3DES algorithm, which is also included with Windows XP Professional.

The concept of Transport Layer Security (TLS) is that conversations between networked devices should be held in a manner such that any other device that might have intercepted the communications will be unable to use the information. TLS, which is similar to SSL, is based on an x.509 certificate which must be published from a trusted Certificate Authority (CA). TLS can do the following:

To use TLS for client/server communication, the following steps are used:

By default TLS will accept any cipher; this can be locked down further by GPO to limit the cipher choices through modification of the following Registry key:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNEL Ciphers

You will find multiple cipher choices listed and can enable or disable them as appropriate.

The TLS Handshake Protocol involves the following steps:

Older implementations of Small Message Block (SMB) communications were susceptible to what is known as a man-in-the-middle attack. A man-in-the-middle attack occurs when an attacker masquerading as one of the legitimate parties inserts messages into the communications channel. This allows the attacker to send its own credentials and causes the other host to accept its connection. By placing a digital signature into each SMB, which is verified by both the server and the client, there is a mutual authentication that verifies the validity of both the server and the client. If this security setting is enabled on a server, the clients must support digital signing of communications or they will be unable to communicate with the server.

This can be configured in the Default Domain Controller Security Settings under Security Settings/Local Policies/Security Options/Microsoft Network Server: Digitally Sign Communications (always)—Enabled.

Not surprisingly, certificate-based technologies require access to certificates. Specifically, certificates that have been issued by a trusted Certificate Authority. Companies have the option of using an external trusted Certificate Authority such as Verisign, SecureNet, or Globalsign. One advantage of using one of these external Certificate Authorities is that Internet Explorer comes preloaded with these as trusted root authorities. This means that clients won’t have to contact those root CAs and prompt the user to accept the certificate. The other option is for a company to establish its own Certificate Authority. This could be a root CA or an Enterprise CA that was built based on a certificate provided by another Root CA.

If a company is going to issue its own certificates, client machines can be preloaded with the certificate via GPO settings. For example, if a company will be using digital certificates in their intranet, they might push a server certificate to the clients to define the server as an Intermediate Certification Authority. To push a certificate to clients, do the following:

The Wizard will inform you that you are about to install a certificate claiming to be from a particular source. If this information is valid, select “yes”. The Wizard will inform you that the certificate was successfully installed.

Installing certificate services in Windows Server 2003 requires taking a Windows 2003 server and adding the Certificate Services component on the server. The process of adding Certificate Services to a Windows 2003 is as follows:

Network security is essentially useless if the servers involved aren’t physically secured. Computers don’t know the difference between a local break-in and a legitimate password recovery. Although security information is stored in the Active Directory, the Active Directory still consists of a database stored on servers. This information is laid out in a specific structure and a person with physical access to a hard drive that contains an NTDS.DIT file, a sector editor, and sufficient knowledge can compromise the security database.

Servers should always be located in locked data centers. Access to these data centers should be limited and audited. Security logs [%systemroot%System32configSecEvent.Evt] should be duplicated in a separate location to prevent tampering. Applications like Microsoft Operations Manager, which centralize management of event logs, are useful for this task. Implementation of a syslog server will also work well for this.

Access to secured data centers should require multiple forms of authentication. For example, rather than just rely on a badge reader, the lock might consist of a combination of a badge reader and a PIN code that must be entered. This way, theft of a badge would not be enough to compromise the data center.

A smartcard is a portable programmable device containing an integrated circuit that stores and processes information. Smartcards traditionally take the form of a device the size of a credit card that is placed into a reader but they can also be USB-based devices or integrated into employee badges. Windows 2003 and Windows XP have native support for smartcards as an authentication method. Smartcards are combined with a PIN, which can be thought of as a password, to provide two-factor authentication. Physical possession of the smartcard and knowledge of the PIN must be combined to successfully authenticate.

To use a smartcard, a domain user must have a smart card certificate. The administrator must prepare a Certificate Authority (CA) to issue smart card certificates before the CA can issue them. The CA needs both the Smart Card Logon and Enrollment Agent certificate templates installed. If smart card certificates for secure e-mail messages are to be used, the administrator must also install the Smart Card User certificate template.

To configure a Windows-based Enterprise CA to Issue Smart Card Certificates, follow these steps:

Biometrics refers to unique biological information that can be used to determine the identity of a user. This, combined with a name/password authentication, provides a two-factor authentication that cannot be duplicated. Thumbprints, bone density, and retinal patterns are all commonly used with biometric security.

Third-party biometric solutions leverage proprietary authentication mechanisms to work in tandem with existing authentication protocols in network operating systems. Technologies like retinal scanners are usually standalone devices whereas items like fingerprint readers can integrate into the user’s keyboard.

The Security Configuration and Analysis tool, which is available in Windows 2003 from the MMC Snap-in, is designed to read specific security information from a server and compare it to a template file. This enables you to create standard templates and see whether servers in their environment conform to those settings.

To perform an analysis of a system, do the following:

The system will display all local security settings and show the template recommendation from the database. By comparing local settings to a standard template created by the administrator, settings can be made consistent without steamrollering any required local security settings.

Groups such as the National Security Agency or the National Institute of Standards and Technology have built what they consider to be secure templates for such roles as Domain Controller, Web Server, Application Server, and others. By using these templates as a starting point, you can build customized templates that take NIST or NSA guidelines into account. This makes it much easier to build a secure template as these groups specialized in knowing and understanding computer security.

The event log is an excellent way to track activity on a server. The local security policy allows you to enable or disable various auditing events, which are explained in the following list:

The Microsoft Baseline Security Analyzer is a tool designed to determine which critical security updates are currently applied to a system. MBSA performs this task by referring to an XML (Extensible Markup Language) file called mssecure.xml. This file is continuously updated by Microsoft to account for all current critical fixes. By leveraging the HFNetChk tool technology MBSA is able to audit the target system against the current list of fixes. This XML file holds information about which security updates are available for particular Microsoft products beyond just the operating system. This file holds the names and titles of security bulletins as well as detailed information about product-specific security updates, including the following:

One of the most valuable methods for checking the security of a server is through the use of a vulnerability scanner. Vulnerability scanners are based on a constantly updated database of known security flaws in operating systems and applications. The scanner attaches to the target system on various ports and sends requests to the system. Based on the responses, the scanner checks its database to determine whether the conditions for an exploit exist on the system. These potential exploits are then compiled into a report and are presented to the administrator. Most vulnerability scanners have the option to do intrusive testing as well. Great care should be taken when performing intrusive testing. Intrusive testing is the only way to truly validate the results of the vulnerability testing. For example, a report item might list that a particular script is marked as executable via the Web services and that it could be exploited to cause the Web server to crash if it is passed a parameter containing a nonstandard character. You might believe that this is a false positive because you have assigned NTFS permissions to the script to only allow a single account to access the script; that account is one that you control and it can never send a nonstandard character. The only way to be sure would be to have the scanner attempt to exploit that apparent flaw. This would need to be done during a maintenance window in case the exploit succeeded. Only after performing this validation could you be certain that the vulnerability was not actually present.

Some popular vulnerability scanners are as follows:

Windows 2003 possesses built-in mechanisms to audit file system access. This enables you to see who is accessing or attempting to access specific files and when the access occurs. This type of auditing is only supported on NTFS drives. To audit this type of access, you must first enable the Object Access Auditing. This feature can be enabled via the Default Domain Security Settings, under Local Policies/Audit Policy/ Audit Object Access. As shown in Figure 1.5, set this to audit both Success and Failure in order to track both types of events. Follow these steps to audit access of a particular file or folder:

Figure 1.5. Setting the security auditing function.

Way back in Windows NT 3.1 Microsoft introduced the NT File System (NTFS). NTFS was a great breakthrough over the FAT file system in many areas. Support for larger drives, support for nonstandard block allocation sizes, and the ability to define security on a file or folder level all gave NTFS a big advantage over FAT. The ability to secure files and folders individually via NTFS permissions is the basis of Windows 2003 as a securable file server.

Windows 2003 has made great strides in the area of default system NTFS permission on the file system. Windows no longer defaults to having the everyone group listed for all resources. Instead, it defaults to allowing authenticated users the ability to read and list files and folders. By default, Windows 2003 will allow authenticated users to bypass traverse checking. This works hand in hand with the upgrades to client operating systems like Windows 2000 Professional and Windows XP Professional that now allow drives to be mapped at a point below the share point. So although a share might exist that looks like \Serverusers$ with departmental directories with hundreds of user directories below them, a user can now be mapped directly to his own directory without having to share the user directory explicitly and without having to grant the user rights to anything other then his own directory. Although the user might not be able to read or list the departmental directories it is unnecessary if the goal is only to give him access to his own home directory. This greatly simplifies the application of NTFS permissions.

One of the most important ways to keep a network secured is to ensure that users are not granted membership to groups that provide more rights than they really need. Similarly it is critical not to fall into the trap of simply making all administrators domain administrators just to ensure that they have sufficient rights to perform their daily duties. Windows 2003 has continued to make great strides in the area of granularity when it comes to assigning rights to administrators.

The area of group membership that is often overlooked by administrators is the local administrative groups on member servers and on workstations. Because these groups aren’t centrally managed, it is easy to forget that they are out there. Administrators often add user’s domain accounts into their local administrator group so that they can work on installing a new software package but often forget to remove that membership after the project is finished. This results in a number of users having elevated rights on their own workstations. This puts them at risk of unwittingly installing spyware or other applications that could put the network at risk.

One way to control membership of these local groups is through the application of Group Policy Objects. By defining the Administrators group as a Restricted Group you can define what accounts are allowed to be present in that group. If a local administrator adds an additional account the change will not be persistent. This enables you to easily control group memberships across the network. This parameter is found in Computer Configuration/Windows Settings/Security Settings/ Restricted Groups. Simply add the group you want to restrict and add the members that are allowed to be present.

Operating system files are the lifeblood of the operating system. Corruptions or deletions of these files can quickly cripple a server. Aside from application of security patches, there is no reason for an administrator to need write access to system files. Having the ability to do so only makes the administrator a threat to the stability of the system. Accidental file deletion or renaming through either operator error or malicious scripts can be prevented by locking down access to the system files. Allow the Administrator account to retain Full Control of the files in the %systemroot% directory but don’t allow general administrative groups to have rights to these files. Discourage administrators from logging on to systems as Administrator. Instead have them use their normal account and use the “run as” feature if they need to run a program with elevated rights.

One of the biggest concerns with Web servers is making sure that secure conversations are not intercepted via packet sniffing. Because the Internet is a pretty nebulous cloud with questionable security it is up to you to ensure that end-to-end communications with end users are secure. One of the most common ways to do this is with Secure Socket Layer communications. SSL runs above TCP/IP and below HTTP. SSL performs three primary functions:

Web servers are especially vulnerable to attack by hackers and griefers. By their very nature Web servers are often open to anonymous access and are located in lightly secured networks. Web servers are very popular targets and as such, vulnerabilities are regularly found in Web services. In order for you to secure systems against these vulnerabilities, you must be aware of them. The easiest way to do this is to scan the Web servers for vulnerabilities regularly.

Many companies offer services specifically designed to regularly scan Web servers for other companies and provide them with reports on discovered vulnerabilities. This is an excellent option for companies that lack the resources or expertise to perform these scans in-house.

Keeping up with patches is absolutely critical for the security of Web servers. The vast majority of the critical fixes produced for Windows are based on flaws discovered on Web servers. This isn’t so much because Web services are inherently insecure but because there are so many Windows-based Web servers on the Internet; they can’t help but provide a tempting target for hackers. Microsoft has entire teams of engineers and software developers that are dedicated to solving these vulnerabilities as soon as they are discovered. Their job is to get these hotfixes out to administrators. The easiest way to manage these patches is with the Software Update Service. The SUS server allows you to point all of your Web servers to a single server for downloading patches. You need only to check the logs on the SUS server to see if new patches are available. You can test these patches in a lab environment and then approve a patch for distribution. At that point, the Web servers that are configured to point to the SUS server will automatically install the patches and optionally reboot themselves.

Windows 2003 IIS (version 6.0) surpasses its predecessor by integrating many of the features of the old IIS Lockdown Tool. The IIS Lockdown Tool worked by disabling unnecessary features within IIS based on the planned role of the server. This served to reduce the potential points of attack available to hackers. This was layered with URLScan, a utility that intercepted input from client machines and ran it through an internal check to determine if it was trying to send malicious data such as out-of-band characters or scripts. By default, IIS 6 installs with just the features needed to fill its defined role. It is able to specify exactly what ISAPI and CGI code is allowed to run on the server and has default behaviors for handling HTTP verbs and headers that are designed to execute WebDAV. IIS 6 maintains a UrlScan.ini file with a specific section for DenyUrlSequences. This replaces some of the features of URLScan. Similarly IIS 6 has a mechanism for limiting the length of fields and requests. This plugs many of the older IIS vulnerabilities. If these settings are too restrictive for a specific Web application, the parameters can be modified via Registry settings:

Although URLScan 2.5 will run on IIS 6, most administrators will find it unnecessary because most of the security features in IIS 6 are better than those in URLScan 2.5. URLScan 2.5 is highly recommended for use with older IIS 5.0 servers.

Windows 2000, 2003, and XP all support EFS. They are capable of generating their own key pair for EFS if a domain level certificate is unavailable to them. EFS on a machine that does not belong to a domain has a number of differences than a machine that is a domain member. For example, Windows 2000 has a default setting that allows any local Administrator account to decrypt any user’s encrypted files on that machine. This makes machines vulnerable to sector editor attacks as the local password store can be compromised. Windows XP and Windows Server 2003 do not have this behavior.

If a user encrypts a file and loses the certificate store of both the user and the local DRA, it will be impossible to decrypt the files. Similarly, due to the lack of a central key database for non-domain EFS users, a user could intentionally delete the DRA certificate and the certificate store and render the files unrecoverable.

When using EFS in a non–Active Directory environment, some key best practices should be followed to simplify management and improve local security:

One of the easiest traps to fall into with Encrypted File System (EFS) is to allow users to enable EFS on their own machine without access to a domain wide recovery agent. Clients will create their own key pair and administrators might not have the capability to recovery encrypted files if the user loses the local key pair. Active Directory allows you to prevent users from enabling EFS until such time that a proper CA has been put in place to enable managed EFS on the clients. The easiest way to do this is via GPMC: