Miscellaneous Windows 2000 Security Features | Designing Secure Web-Based Applications for Microsoft Windows 2000 with CDROM

[Previous] [Next]

This section gives overviews of other important aspects of Windows 2000 security; the overviews are not to be considered complete tutorials. The topics covered in the following sections include Encrypting File System (EFS), IP Security (IPSec), the Security Configuration Editor (SCE), and Windows File Protection (WFP).

Encrypting File System

The Windows 2000 Encrypting File System, an integral part of the Windows 2000 file system, NTFS, lets users encrypt files and folders on a computer for added protection. EFS automatically decrypts the file for use and encrypts the file when it is saved. No one can read EFS-encrypted files except the user who encrypted the file or a user, such as an administrator, with an EFS Recovery certificate. EFS's main purpose is to protect files on high-risk devices such as laptops where physical attack is a greater possibility than on a desktop or server computer.

Note that files under the %windir% directory and files with the SYSTEM attribute set cannot be encrypted. You can determine the value of %windir% by typing the following at the command line:

 echo %windir%

You can encrypt files by following these steps:

Right-click the file or folder you want to encrypt, and then click Properties.

Click Advanced, select the Encrypt Contents To Secure Data check box, and then click OK.

You can also use the Cipher.exe tool included with Windows 2000 to display or encrypt files and directories from the command line. For more information about EFS, refer to the online Windows 2000 help and the EFS white paper at http://www.microsoft.com/windows2000/library/howitworks/security/encrypt.asp

CAUTION
Do not encrypt your C:\Temp directory if you use Offline folders, also called client-side caching. Doing so can make Offline folders behave inconsistently.

IP Security

Once you've read Chapter 12, "Securing Against Attack," you'll know that the TCP/IP protocol suite is insecure. There is no authentication, no authorization, no privacy, and no data integrity for IP packets. Because of this, all protocols in the TCP/IP protocol, including ICMP, IGMP, TCP, UDP, and IP packets, can be forged. Fake packets cause havoc on the Web; many denial of service (DoS) attacks rely on malicious use of such packets. IPSec is designed to address many of these issues by protecting IP packets and providing defense against network-based attacks.

Protecting IP packets

IPSec protects IP packets by using cryptography to provide authentication, privacy, replay defense, and data integrity. Authentication, integrity, and antireplay are provided by the Authentication Header (AH) protocol, and privacy is provided by the Encapsulating Security Payload (ESP) protocol. ESP can be used alone or in conjunction with AH.

IP packet authentication

IPSec supports many authentication mechanisms, including Kerberos V5 authentication protocol (requires Active Directory), a public key certificate, or a preshared secret key. The latter requires that you enter a secret phrase or key into the IPSec administration tool on each computer you want to use; this is a simple method for authenticating computers not running Windows 2000, stand-alone computers, or any clients not running the Kerberos V5 authentication protocol. The key is used for authentication only, not for encrypting IP packets.

IP packet integrity and privacy

IPSec can use the MD5 or SHA-1 digest algorithms for message integrity and DES or Triple-DES (also referred to as 3DES) for encryption. IPSec can also be configured to generate new encryption keys after a predetermined amount of time or after a number of bytes have been transmitted or received using IPSec. New keys are derived using the Diffie-Hellman protocol.

NOTE
Windows 2000 includes a graphical tool called IPSecMon.exe to show real-time IPSec security associations. Refer to the online help or Knowledge Base article Q231587 at http://support.microsoft.com/support/kb/articles/Q231/5/87.asp for details about using this tool.

Why use IPSec?

The main purpose of using IPSec is verifying that the server you're communicating with is the server it says it is and, optionally, that all data between the two or more hosts is private and has not been tampered with.

Let's take a moment to look at an example of IPSec in action: you have a server running Microsoft SQL Server that can be accessed only from a Web server in the "demilitarized zone" (DMZ) and from administration servers on an intranet. Figure 3-15 illustrates this scenario.

click to view at full size.

Figure 3-15. A Web-based scenario using IPSec to authenticate connections between computers.

The Demilitarized Zone Explained
A DMZ is the area on a network that lies between the internal network and the Internet. Often a DMZ is implemented between two firewalls or as a small, private network that is connected to one network card in the firewall.

In this example, only the IIS and administration servers can communicate directly with the SQL Server box. Direct access to the SQL Server computer will fail because the attacker must be in the Kerberos domain, must have a trusted certificate, or must know the preshared secret, depending on how IPSec is configured to authenticate other IPSec computers.

NOTE
IPSec does not secure all IP-based protocols. IPSec exempts Internet Key Exchange (or IKE, formally known as ISAKMP/Oakley), Kerberos authentication, and IP multicast and broadcast packets.

Providing defense against network-based attacks

IPSec also provides support for blocking access to protocols ports; this is more often referred to as packet filtering. IPSec implements such filtering by using a series of rules, and each rule determines whether communication can take place between the server and a remote host based on source IP address, destination IP address, port number, and IP protocol.

For example, say you want to disallow all traffic except HTTP traffic to the network card with IP address 172.12.99.61. Setting up this policy is simple:

Set a rule that allows all TCP traffic to and from port 80, from any IP address to IP address 172.12.99.61.

Disallow all other traffic.

These two rules will enforce the policy defined.

NOTE
IPSec is not a replacement for a dedicated firewall because IPSec does not support the ability to perform low-level packet inspection such as the IP or TCP flags or Internet Control Message Protocol (ICMP) subcodes.

IPSec from the command line

The Microsoft Windows 2000 Server Resource Kit includes a tool that makes it easy to deploy IPSec policy from scripts. The tool, IPSecPol.exe, configures IPSec policy in Active Directory and in a local or remote server's Registry.

One area where the tool shines is setting up packet filtering policy. For example, the following code will lock all ports except the HTTP port, port 80:

 IPSecPol \\exair1 -w REG -p "Web" -o IPSecPol \\exair1 -x -w REG -p "Web" -r "BlockAll" -n BLOCK -f 0+* IPSecPol \\exair1 -x -w REG -p "Web" -r "OkHTTP" -n PASS -f 0:80+*::TCP IPSecPol \\exair1 -x -w REG -p "Web" -r "OkICMP" -n PASS  -f 0+*::ICMP

This code needs a little explaining, because there are no port-blocking examples in the resource kit documentation.

The first line removes the IPSec policy named Web and deletes any associated filters and filter actions. The next three lines block all IP traffic other than HTTP traffic and ICMP traffic, based on the syntax in Table 3-6.

Table 3-6. IPSecPol command line syntax.

Argument	Comments
IPSecPol	The tool name.
\\exair1	The name of a remote server to configure. The local machine is assumed if this option is missing.
-x	Activate the policy.
-w REG	Write the data to the registry. The other option is to write the data in Active Directory, but in this example the computers are not in a domain and therefore have no Active Directory access.
-p "Web"	The name of the policy.
-r "BlockAll" and -r "OkHTTP" and -r "OkICMP"	Policies are made of rules—in this case, the "Web" policy is made of three rules, "BlockAll", "OkHTTP", and "OkICMP".
-n BLOCK -f 0+, -n PASS -f 0:80+::TCP, and -n PASS -f 0+*::ICMP	These rules set negotiation policy—in this case, the first blocks access to and from all ports and protocols, the second passes (that is, allows) access to port 80, and the last allows all ICMP traffic (for example, ICMP echo, or ping). -f means a filter list. 0 means my IP address(es) or all the IP addresses assigned to this computer. 0:80 means my address(es) using port 80 (HTTP port). + means create two filters, one for inbound traffic and the other for outbound traffic. * means all ports. *::TCP means all IP addresses, on any port using TCP. (The port is not included between the two : characters.)

The format of the -f argument is as follows:

 SourceAddr:SourcePort+DestinationAddr:DestinationPort:Protocol

It doesn't matter in what order you list the rules because the IPSec engine will order the rules such that the most specific rules are first and the most general are last.

For further information about IPSec, refer to the IP Security white paper at

http://www.microsoft.com/windows2000/library/howitworks/security/ip_security.asp

and the step-by-step guide to IPSec at

http://www.microsoft.com/windows2000/library/planning/security/ipsecsteps.asp

Security Configuration Editor

Because it can be time-consuming and difficult to set up, configure, enforce, and maintain distributed security environments, management errors are one of the prime causes of security problems in any network or internetwork. The SCE toolset is designed to alleviate this situation by providing an easy-to-use and consistent set of tools for security administration. Not only can the SCE deploy security policy, it can also audit that policy to verify that nothing has changed. The only audit tool available in Windows NT is the Event Viewer, but it's not designed to verify the security policy of Windows NT servers.

Security policy is created using the Security Template tool and then applied to a computer using the Security Configuration And Analysis tool. The latter tool can also analyze a system and verify that it complies with the security policy defined in the template.

Security templates allow you to configure the following security categories:

Account policies: password, account policy, and Kerberos policy

Local policies: audit policy, User Rights assignment, and security options

Event logs: event log policy

Restricted groups: Restricted group membership

System services: security and startup policy

Registry: Registry security settings

File system: file access and audit security

The default installation of Windows 2000 Server includes the templates in Table 3-7.

Table 3-7. Default security templates.

Name	Comments
basicdc	This template contains basic security settings for Windows 2000 domain controllers. It requires that you set the DSDIT, DSLOG, and SYSVOL environment variables. The target computer must be in a domain in order for this template to work. This template does not modify the User Rights or the Restricted groups.
basicsv	This template applies basic security settings for computers running Windows 2000 Server. It does not modify the User Rights or the Restricted groups.
basicwk	This template applies basic security settings for computers running Windows 2000 Professional. It does not modify the User Rights or the Restricted groups.
compatws	This template applies default permissions to the Users group so that legacy applications are more likely to run. It assumes you've done a clean install of the operating system and the registry ACLs to an NTFS partition. The template relaxes ACLs for members of the Users group and empties the Power Users group.
DC Security	This template applies default security settings for domain controllers.
hisecdc	This template assumes you've done a clean-install of the operating system and the Registry ACLs to an NTFS partition. The template includes SecureDC settings (see below) with Windows 2000-only enhancements. It empties the Power Users group.
hisecws	This template offers increased security settings over those of the securews template. It restricts Power User and Terminal Server ACLs and empties the Power Users group.
notssid	This template removes the Terminal Server User SID from Windows 2000 Server. It sets no other policy.
ocfiless	This template contains file security settings for optionally installed components on machines running Windows 2000 Server. Because all the files defined in this template are optional, many of the files might not be installed. This template is used if you install an optional Windows 2000 component after initial setup to make sure that the ACLs on the newly installed files are secure.
ocfilesw	This template contains file security settings for optionally installed components on machines running Windows 2000 Professional. Because all the files defined in this template are optional, many of the files might not be installed. This template is used if you install an optional Windows 2000 component after initial setup to make sure that the ACLs on the newly installed files are secure.
securedc	This template assumes you've done a clean-install of the operating system and the registry ACLs to an NTFS partition. The template provides higher security settings than those in the basicdc and the DC Security template.
securews	This template assumes you've done a clean-install of the operating system and the registry ACLs to an NTFS partition. The template provides higher security settings than those in the basicwk template and empties Power Users group.
setup security	This template contains "out of box" default security settings

Security Configuration Editor deployment process

Designing and deploying security policy is straightforward using the SCE toolset. If you want to modify an existing security policy, use the Security Templates tool. (There's no need to use this tool if you want to use an existing template.) You can load the Security Templates tool by following these steps:

Start Mmc.exe.

Choose Add/Remove Snap-in from the Console menu.

Click Add.

Select Security Templates.

Click Add, click Close, and click OK.

To use the SCE, first load the Security Configuration And Analysis tool by following the steps below:

Start Mmc.exe.

Choose Add/Remove Snap-in from the Console menu.

Click Add.

Select Security Configuration And Analysis.

Click Add, click Close, and click OK.

Now create an SCE database. SCE databases are used to track changes made to a computer and to allow you to audit against those settings. Create the database by following these steps:

Right-click the Security Configuration And Analysis tool.

Choose Open Database from the context menu.

Enter the name of the database, and click Open.

Select the name of the security template you want to use.

Now right-click the Security Configuration And Analysis tool and do the following:

Choose Analyze Computer Now from the context menu.

Enter the name of a file to write progress information to. The default file location is \Documents and Settings\<user>\Local Settings\Temp\delta.log.

Click OK.

Wait a moment while the tool analyzes your system, as shown in Figure 3-16. At this stage, the tool is comparing the system security with that defined in the template.

Figure 3-16. The Security Configuration Editor analyzing a computer.

You can browse the results when the analysis phase is complete, as shown in Figure 3-17, to see which settings do not comply with the policy you've defined.

click to view at full size.

Figure 3-17. Reviewing Security Configuration Editor results after an analysis.

If you're happy with the settings, right-click the Security Configuration And Analysis tool again and choose Configure Computer Now from the context menu.

NOTE
Security policy can also be deployed as part of Windows 2000 Group Policy by extending the Group Policy Editor. Group Policy is propagated to computers in a domain or organizational unit and applied to the computers. This configuration information is applied to affected computers regularly to ensure that they comply with corporate policy.

You can also analyze and configure a system by using the SecEdit.exe command line tool. Refer to the Windows 2000 online help and to the Security Configuration Editor Toolset white paper at http://www.microsoft.com/windows2000/library/howitworks/security/sctoolset.asp for further details on this command.

Windows File Protection

Windows File Protection is a new feature of Windows 2000 designed to help make the operating system more stable. Technically, it's not a security feature, but it does offer the ability to detect when system files have been modified, possibly by an attacker.

All SYS, DLL, EXE, and OCX files that ship on the Windows 2000 CD are protected, as are the Micros.ttf, Tahoma.ttf, and Tahomabd.ttf TrueType fonts. If WFP detects that a system file has changed, it will silently replace the updated file with a copy of the file from the system32\dllcache directory or from the Windows 2000 installation CD.

Windows 2000 also includes a tool called System File Checker, Sfc.exe, that allows an administrator to scan all protected files to verify that they are valid versions. As this tool operates, it displays a status window and writes any file discrepancy information to the event log.

WFP knows which system files are valid and which are not through a mechanism called driver signing. All Windows 2000 files are hashed and then signed by Microsoft. The signed data is held in catalog files (not in the drivers themselves) in the System32\CatRoot directory. Each catalog file contains the signatures of valid system files. For example, the NT5IIS.CAT file stores all the signatures for the files that make up IIS 5. Double-clicking this file will display the signature information.

You can verify system file signatures at any stage by using the SigVerif.exe tool. After the tool runs, it will display a list of files that have either no signature or an invalid signature. Any file listed by the tool should be viewed with caution. Virtually all files shipped with Windows 2000 are signed; a very small number are not.