Securing Windows NT/2000 Servers for the Internet

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The use of Windows systems as Internet servers presents security challenges. In contrast to most internal systems, systems connected to the Internet are directly exposed to security attacks from both unsophisticated and highly skilled attackers. The typical Windows NT 4.0 (and, more recently, Windows 2000) installation makes a Windows server an easy target for such attacks. Securing the Windows NT or the Windows 2000 operating system for Internet use is a complex task. The purpose of this book is to offer a strategy for making your Windows-based server configuration as secure as possible. This strategy has two basic parts:

Secure or " harden" any Windows server that will be exposed to potential attacks from the Internet so it is as secure as it possibly can be. An exposed system of this kind is typically known as a bastion host .
Provide extra security protection for such exposed systems by installing an additional network — typically known as a perimeter network — that separates the outside network (usually the Internet) from your organization's internal networks.

Later chapters of this book describe specifically how to harden your Windows NT or Windows 2000 system so it can function on your perimeter network as a secure bastion host. Before I present the step-by-step security details, this chapter sets the scene by describing briefly the security threats your system will face, the architecture of the Windows NT and Windows 2000 operating systems, and the recommended placement of Windows servers on your perimeter network.

An Internet server faces many different kinds of threats. The most common include:

Intrusion: An intrusion occurs when an unauthorized person gains access to your system. These days, intrusions most often result in web page defacement: an attacker alters the contents of your web site. Such attacks are growing in popularity. Attrition (

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

An Internet server faces many different kinds of threats. The most common include:

Intrusion: An intrusion occurs when an unauthorized person gains access to your system. These days, intrusions most often result in web page defacement: an attacker alters the contents of your web site. Such attacks are growing in popularity. Attrition ( http://www.attrition.org/mirror/attrition/ ) maintains a daily updated list of defaced web sites. The current record is 56 reported defacements in one day (November 21, 1999). About 60% of the defacements recorded at Attrition between October 1999 and April 2000 have occurred on Windows NT systems.
Denial of service: The goal of a denial of service (DOS) attack is to sabotage operation by consuming all of your computing resources (CPU time, network bandwidth, etc.). This effectively stops authorized users from using the system.
Information theft: This type of attack occurs when an unauthorized person obtains private information. The most popular targets are login/password information, credit card information, and software source code.

Many intrusions are made possible by improperly configured software. Looking at a concrete example may help underscore this point. Recently, the Apache web server site ( http://www.apache.org/ ) was hacked. In this particular case, the attackers uploaded a PHP script to a world-writeable FTP directory. The web server root directory was the same as the FTP server root directory. This allowed the attackers to launch Unix commands using the uploaded script. They uploaded and executed a shell binary that bound to a high port and enabled them to initiate a connection to that port. The attackers now had interactive shell access on the system. The next step was to gain root access. This was accomplished by using a database process that was running as root to indirectly create a

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Building and maintaining a secure site on the Internet includes many more tasks than simply installing your operating system, however securely you may do so. Overall security is a combination of secure software and careful human planning and administration. You will need to be concerned with all of the following tasks:

Planning

Securing an Internet site must be a carefully planned and coordinated process. It's not just a matter of clicking on screens and working it out as you go. Figure out the goals and tactics ahead of time, and then implement security, step-by-step. It's also important to understand that you need one encompassing plan that includes all aspects of the process, rather than several small and uncoordinated planning efforts.

Policies

In order to achieve a high level of security, you need policies that define the main aspects of running an Internet site. This is not a book on policies, but keep in mind that before you start building a secure system, you need to have the appropriate policies in place. Start by reading the Site Security Handbook (RFC 2196); it's an excellent introduction to this topic.

Access control

Access control protects systems from unauthorized use; there are several different types:

Physical access control: Physical access control is often overlooked, but it's an extremely important outer level of protection. Large organizations often have big computer rooms that are both bomb-proof and earthquake-proof, which is good. In many cases, however, pretty much everyone in the organization has access to these rooms, which makes it possible for anyone in the building to sabotage operations.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This section provides a very basic summary of the architecture of Windows NT and Windows 2000 systems. You'll need at least this background information for understanding the instructions in subsequent chapters. For more detailed information, see a good Windows operating system book. I particularly recommend Inside Windows NT, Third Edition by James D. Murray (O'Reilly & Associates, 1999).

In the discussion that follows, most of the details are the same for Windows NT and Windows 2000. If there is an architectural difference, I will note it.

Windows NT is a multithreaded, micro-kernel-based operating system. The term micro-kernel implies that the kernel component is very small, and provides only basic functions such as thread dispatching and hardware exception handling. Hardware-specific code is kept in a separate layer called the Hardware Abstraction Layer (HAL). The HAL simplifies porting of the operating system to new processor architectures like the IA-64.

The core operating system code runs in privileged processor mode. This mode is also known as protected mode (when referring to the CPU), or kernel mode (when referring to a process or thread). Protected mode provides direct access to system memory and other hardware. Applications run in a nonprivileged processor mode known as user mode and have no direct hardware access. Applications have to use the system calls — the API (Application Programming Interface) — in the underlying operating system to perform tasks such as reading or writing to memory or to the screen.

The basic Windows NT architecture is shown in Figure 1.9.

Figure 1.9: The Windows NT architecture

Operating system services are kept in discrete subsystems, some running in user mode and others in kernel mode. There are several kernel mode subsystems in Windows NT. They provide NT's native functionality for user mode subsystems through

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Features like discretionary access control, security auditing, and memory protection place the Windows NT core operating system on par (or better) with many Unix systems in terms of local host security. So why do many people claim that Windows is less secure than Unix?

The problem is not really Windows itself; rather it's the services and applications built on top of the operating system that are the weakest links.

The following sections describe some fundamental principles of secure system design, as well as examine how some of Windows NT/2000's services and applications stack up to these principles.

A very important principle is that of least privilege. The least privilege philosophy dictates that an application should be designed to run only with the privilege level it needs to execute properly—and no more.

Consider the following question: what privilege level do you need to grant to a web server application? The simplified answer is that the application needs the right to read the data files it serves. Now, take a look at the Internet Information Server's (IIS) WWW service. By design, it has to run as Local System, the highest privilege level in Windows. IIS does run the actual worker threads with lower rights, but if an attacker manages to break IIS before the security context switch is made, he'll be able to do anything, including deleting filesystems, starting up a back door, and so on—you get the idea!

Microsoft designed IIS in this way to be able to integrate the web server with the NT security architecture. There's not much specific security code in IIS; instead, it uses the same access control mechanisms as any other NT process would. The IIS authentication mechanisms use the NT account database. Access to individual files and directories is controlled by NTFS DACLs, just like on a file server. To achieve this level of functionality, IIS needs to be able to start a process or a thread in the security context of the connecting user, and to call the required Win32 APIs it needs to run at very high privilege level.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You will find references to various types of encryption methods and algorithms throughout this book. This section is a very brief summary of some of the terms and algorithms relevant to discussions in later chapters. For more detailed information on this complex topic, consult a good cryptography reference.

With public key cryptography, each party has a key-pair consisting of a private key and a public key. The public key is published while the private key is kept secret. Data encrypted with the public keys can only be decrypted using the private key and vice versa. Public key cryptography can also be used for authentication (through the use of digital signatures).

An important advantage of public key cryptography is that there are less complicated key distribution problems. All parties that want to be able to communicate using public key cryptography need to publish their public key in some kind of directory. When Alice wants to send an encrypted message to Bob, she uses Bob's public key to encrypt the data. Alice can also digitally sign a message by encrypting it with her private key. Bob can then decrypt the message using his private key and verify Alice's signature by decrypting using her public key.

The main disadvantage is that public key cryptography is slow compared to symmetric key cryptography.

Two common public key systems are:

Rivest-Shamir-Adleman (RSA): The RSA cryptosystem is the most widely used public key cryptosystem. It's designed for doing both digital signatures and data encryption. RSA is used in Internet standards and drafts like IPSec, S/MIME, and TLS (the successor to SSL). RSA was patented in the U.S. until September 20, 2000.
Digital Signature Algorithm (DSA): The Digital Signature Algorithm is an unpatented alternative to RSA. DSA was intended for performing digital signatures only, but it can be adapted for encryption as well. DSA is described in the Digital Signature Standard (DSS). DSA was designed by the National Security Agency (NSA) based on the ElGamal algorithm, which is unpatented.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter explains how to build a secure Windows NT bastion host by modifying the default Windows NT configuration. The configuration changes and procedures I explain focus on Windows NT 4.0, but most of it is also applicable to Windows 2000. Chapter 3, focuses on differences in Windows 2000.

If you carefully apply the changes suggested in this chapter, you should be able to build a very secure Windows server. However, there are several caveats.

First, remember that a chain is only as strong as its weakest link. If you follow the configuration steps in this chapter, your operating system will be quite secure. However, every application installed will also have to be configured with extreme caution—especially applications that require high privileges to run properly.

Second, note that if you secure your Windows NT server as described in this chapter, you'll no longer be able to perform remote administration via NetBIOS-based tools such as Server Manager and Event Viewer. You won't even be able to copy files to the system over the network anymore. However, there's no need to panic! In Chapter 4, I teach you how to build a new and more secure remote management foundation for your bastion host.

Third, the methodology presented in these chapters primarily targets small to medium-sized perimeters with up to 50 or so Windows NT hosts. If you have plans to build a perimeter with more than 50 to 75 hosts, consider the dual-homed approach shown in Figure 1.13, and skip the RPC/NetBIOS/SMB-related steps presented in this chapter.

The following steps are required to build a bastion host:

Install a minimal operating system and the latest service pack.
Install the applications you plan to run on the host.
Reapply the service pack and install the latest security patches.
Remove or disable unneeded components from the operating system.
Harden the remaining operating system components.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This section describes special procedures for securely installing the Windows NT operating system, additional software, service packs, and hotfixes on a bastion host.

The installation and configuration changes I describe in this chapter can break applications and even force reinstallation of the server. Don't apply these changes to a production system without first testing everything on an identical system. I suggest setting up a test environment to become familiar with all the steps before even thinking of applying them to "live" systems.

Follow these steps when installing the Windows NT operating system:

Start with a clean system. Make sure all old data is removed from the disks before continuing.
Do not, under any circumstances, allow the system to be connected to a public network during the installation and configuration. If there must be a network connection, make sure it's on an isolated trusted network segment. This is to ensure that the system can be trusted after the installation and configuration. It would be very embarrassing if the system was hacked before it was actually put in production!
Do not have a dual boot configuration. It's not a good idea to have any other operating systems installed on the bastion host.
Install the U.S. English version of Windows NT. Microsoft always releases critical security fixes to the U.S. version first (since it has the largest installed base). You don't want to be in a situation in which attackers can break into your system by exploiting a security hole that is a couple of months old.
Use only the NT File System (NTFS) as your filesystem. Do not use FAT. NTFS is a journaled filesystem. It uses log and checkpoint information, much as a database management system (DBMS) does, to ensure the consistency of the filesystem in the event of a system crash or a power failure. NTFS also supports two types of access control lists:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In NT 4.0 Service Pack 4, Microsoft released a tool called the Security Configuration Editor (SCE). You can also download the tool from ftp://ftp.microsoft.com/. The SCE is installed by default in Windows 2000.

The Security Configuration Editor is a MMC (Microsoft Management Console) snap-in (an add-on component) that makes it possible to edit many of the security settings discussed in this chapter using a friendly GUI (shown in Figure 2.1). With the SCE, you can make templates that you can apply on another server. The templates can be applied using either the GUI or the command line.

Figure 2.1: The Security Configuration Editor MMC snap-in

If you have built a template and want to apply the changes without installing SCE on a host, copy the template file, as well as the secedit.exe, scedll.dll, and esent.dll files to a floppy disk. The secedit.exe executable is the command-line interface to the core SCE functions stored in scedll.dll. SCE uses an Indexed Sequential Access Method (ISAM) database engine, previously called "Jet," to store its settings and results. This database engine is referred to as the Extensible Storage Engine (ESE). The esent.dll provides this functionality.

Insert the floppy in the target system and run the following command:

C:\> secedit /configure /cfg bastion.inf /db %TEMP%\secedit.sdb /verbose 
    /log %TEMP%\scelog.txt

Review the log file and then delete the files in %TEMP% to remove any security-related information.

You can also audit a system at any time by running the SCE in analyze mode. The analyze process can run from the GUI or from the command line using the following command:

C:\> secedit /analyze /cfg bastion.inf /db %TEMP%\secedit.sdb /verbose 
    /log %TEMP%\scelog.txt

The analysis produces a report that shows the differences between the template and the actual configuration.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

After installing the operating system, any applications, the latest service pack, and all relevant hotfixes, the next step is to ensure that the bastion host has rudimentary security in place. This involves some GUI-based configuration steps that remove unneeded or possibly unsafe components from the operating system.

A Windows NT network service is software that provides some kind of network-based service. The Computer Browser, SNMP (Simple Network Management Protocol), and Server services are examples of network services.

By default, Windows NT installs five network services:

Remote Procedure Call (RPC) configuration: Enables RPC programs to call components on other computers over the network.
NetBIOS interface: Responsible for resolving names, establishing connections, and supporting reliable data transfer between computers running NetBIOS applications.
Computer Browser: Provides users with the ability to browse the Network Neighborhood for shares and printers.
Server: This service is the SMB/CIFS Server. It consists of two parts: the user mode interface (services.exe), which controls the behavior of the kernel mode driver, and the driver (srv.sys), which is responsible for printer and file sharing to CIFS clients, such as the Workstation service. This service relies on the NetBIOS interface.
Workstation: This service is the SMB/CIFS client software. Like the Server service, the Workstation service also consists of two parts: the user mode interface (

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The steps performed so far have used the standard administrative tools in Windows NT. Now it's time to work on some more advanced tasks to further enhance the security of your system. These tasks include:

Encrypting the password database
Editing the registry
Disabling unnecessary files

If an attacker gets hold of a system backup or an emergency repair disk, he could use a tool such as L0phtCrack to run a dictionary attack or a brute force attack on the Systems Account Manager (SAM) database. However, if the password hashes in the database are encrypted, these attacks will be unsuccessful.

In NT 4.0 Service Pack 3, Microsoft introduced a facility for encrypting the password hashes stored in the SAM database. This facility protects the database from offline password cracking attempts. To implement this encryption feature, run the following command:

C:\> syskey

Running syskey brings up the dialog box shown in Figure 2.5. Note that enabling password encryption is a one-way operation—once it is enabled, it cannot be disabled.

Figure 2.5: The syskey command encryption dialog box

When you enable encryption, the system creates a random 128-bit encryption key. This is used to encrypt the password hash entries in the SAM database in the registry (HKLM\SAM). The encryption key is protected with another key, called the system key . In the Account Database Key screen (shown in Figure 2.6), choose one of these options:

Password Startup: Specify a startup password here. Later on, this password must be entered at system boot time in order to gain access to the SAM database. The system key is derived from the startup password; it is the startup password's MD5 hash (see Cryptographic Hashes and Windows NT later in this section).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A policy is a set of rules governing how to use a system. Typically, a security officer decides upon the policy, the administrator implements it, and the operating system enforces it. Policies are administered using the Policies menu in the Windows NT User Manager.

In Windows NT, there are three basic types of policies:

Account policies: These control the characteristics of user accounts. Examples are the minimum length of a password in the system, and how long a user can keep a password before being required to change it.
Audit policies: These control what events will be logged in the system. Examples are logons and logoffs, and file and object accesses.
User rights policies: These control what rights individual users or groups of users have. Examples are the right to access the computer or the ability to back up files.

This section focuses on account policies and user rights policies. Audit policies are discussed in Chapter 6.

The account policy controls various characteristics of user accounts on the system — for example, the types of passwords that users can supply. The account policy information is stored in the Systems Account Manager (SAM) database, not in the Local Security Authority (LSA) policy database. Edit the account policy (shown in Figure 2.11) using the User Manager (go to Policies → Account).

Figure 2.11: The Account Policy dialog box

I recommend the account policy settings listed in Table 2.6.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Internet Protocol (IP) is the language of the Internet. All computers on the Internet exchange data using TCP/IP. The current versions of TCP, UDP, and the IP protocol (Version 4) all became Internet standards in 1981.

An issue with TCP/IP is it offers no form of security such as authentication, encryption, or data integrity. There are many methods of attacking the existing TCP/IP protocol suite. These attacks include:

Connection hijacking: This occurs when an attacker takes over an existing session. It is, for example, possible for an attacker to take over a Telnet session after a user has logged in. The attacker has to be able to listen to any packets exchanged between the server and the client, and forge packets to launch this attack. There is a good paper on connection hijacking available at http://www.insecure.org/stf/iphijack.txt.
Data insertion: A stealth attack similar to connection hijacking. The goal is to insert data into an existing session to run commands to break into or to sabotage the target system.
Denial of service: The purpose of a denial of service attack is to make a site unavailable to normal users. Flooding the network connection of a server with connection attempts may achieve this.
Man-in-the-middle: An attack that tricks a client into believing that it's talking to the real destination server. In fact, it's talking to another system (controlled by the attacker) that is, in turn, talking to the real destination server. This attack is often launched by creating a fake cache entry in a DNS server.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Many system administrators have a set of favorite tools and scripts they copy to the hosts they administer. If you have some tools that you just can't live without, copy them to a directory of their own (such as c:\admintools), create a new group called Admintools, and allow only members of that group access to this directory. Consider encrypting the directory with PGP-disk or a similar tool. Since Local System is a member of the Administrators group, it's important that you don't add the built-in Administrators group to any new groups you create.

You also need to reset permissions on the standard Windows NT administrative tools in the system32 directory. I recommend setting the DACL on the files listed in Table 2.8 to Admintools:F (Full Control) only.

Table 2.8: Administrative Tools and Utilities
Filename	Description
`arp.exe`	Used to display and modify the ARP cache
`at.exe`	Used to submit jobs to the Schedule service
`cacls.exe`	Used to modify DACLs on files
`cscript.exe`	Windows Script Host (if installed)
`cmd.exe`	Command interpreter

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Setting permissions on operating system objects such as files, directories, and registry keys provides a fine-grained access control mechanism. In Windows NT, access to objects is controlled by Discretionary Access Control Lists (DACLs). Each object in the operating system includes a DACL. Consider Example 2.2.

Example 2.2. A Sample DACL

stevesk: No Access
Administrators: Write, Execute
Users: Read

The DACL shown in Example 2.2 grants any member of the Administrators group Write and Execute permission. Members of the Users group have Read access. Permissions are cumulative. If a user is a member of both Users and Administrators, his effective access will be Read, Write, and Execute (the combined permissions of his user and the groups of which he's a member). The user stevesk's effective permission is "No Access," regardless of which groups of which he is a member. This is because No Access overrides all other permissions.

The Windows NT File System (NTFS) supports the permissions shown in Table 2.9.

Table 2.9: The NTFS Permissions
NTFS Permission	File	Folder
Read (R)	Display the contents of a file and other data such as the owner and permissions.	Display the contents of a folder and other data such as the owner and permissions.
Write (W)	Modify the file.	Add files and folders to the folder.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter describes the differences between Windows NT and Windows 2000 that you need to be aware of when you build your Windows 2000 bastion host. The chapter isn't a self-contained description of building a bastion host. I assume here that you've read Chapter 2, and I focus only on the differences between the two systems, particularly the new network features in Windows 2000.

This chapter also contains an introduction to the IPSec implementation in Windows 2000. IPSec can be used to build virtual private networks (VPNs) for remote access to company internal information. It can also be used to establish secure extranets with business partners over the Internet. The IPSec gateway will then be a part of your perimeter network and should be configured as a bastion host.

IPSec can also be used to control access to your Windows 2000 systems in a more sophisticated manner than the TCP/IP IP Security feature covered in Chapter 2.

Even though Windows 2000 is a major rewrite of the NT 4.0 code base, very little of the rewritten code actually affects our work on the bastion host. The hardening process is performed in almost exactly the same way on the two systems. Once you master the NT 4.0 process, you should be able to build a Windows 2000 bastion host too.

The following sections describe the few differences you need to know about.

The installation process on Windows 2000 is started in the usual way. Follow these steps:

Accept the defaults until you get to the Network Settings dialog box.
In the Network Settings dialog box, click "Custom" and deselect everything but "Client for Microsoft Networks" and TCP/IP. Uncheck (unbind) "Client for Microsoft Networks" from all interfaces, as shown in Figure 3.1. The reason that you must keep the client software is that the NT/LanMan Security Support Provider (NTLM SSP) is a part of this client software. If you want to run the Internet Information Server (IIS), you must have the NTLM SSP installed; otherwise, IIS will not start. If you don't plan to run IIS, you can choose to uninstall the "Client for Microsoft Networks."

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Even though Windows 2000 is a major rewrite of the NT 4.0 code base, very little of the rewritten code actually affects our work on the bastion host. The hardening process is performed in almost exactly the same way on the two systems. Once you master the NT 4.0 process, you should be able to build a Windows 2000 bastion host too.

The following sections describe the few differences you need to know about.

The installation process on Windows 2000 is started in the usual way. Follow these steps:

Accept the defaults until you get to the Network Settings dialog box.
In the Network Settings dialog box, click "Custom" and deselect everything but "Client for Microsoft Networks" and TCP/IP. Uncheck (unbind) "Client for Microsoft Networks" from all interfaces, as shown in Figure 3.1. The reason that you must keep the client software is that the NT/LanMan Security Support Provider (NTLM SSP) is a part of this client software. If you want to run the Internet Information Server (IIS), you must have the NTLM SSP installed; otherwise, IIS will not start. If you don't plan to run IIS, you can choose to uninstall the "Client for Microsoft Networks."
Disable NetBIOS over TCP/IP in the TCP/IP Properties dialog box.

Figure 3.1: The Windows 2000 configuration and bindings for a network card

Bindings are controlled by checking or unchecking services or protocols in the network connection dialog box (one per interface).

Microsoft has abandoned the FTP download method for service packs and hotfixes for Windows 2000. Instead, they distribute product updates through their Windows 2000 web site (

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Windows 2000 provides support for the protocols available through the IPSec ( IP Security) standards. IPSec supplies a standards framework for securing IP traffic. You may want to deploy IPSec on a bastion host — for example, in a network used for external "extranet" communication with business partners.

IPSec can also be used within a perimeter — for example, between a management station and a bastion host running Windows 2000 Terminal Services to achieve stronger authentication on the host level (and also, optionally, to achieve an extra layer of encryption). The IPSec policy agent in Windows 2000 can also be used to control non-IPSec traffic.

This section provides a brief overview of the IPSec implementation in Windows 2000, although it doesn't by any means discuss all the configuration issues with IPSec.

IPSec provides an authenticated, secure channel using the following protocols:

Authentication using the Internet Key Exchange Protocol (IKE, specified in RFC 2409)
Integrity protection using the Authentication Header (AH, specified in RFC 2402)
Encryption using the Encapsulating Security Payload (ESP, specified in RFC 2406) between two hosts

Section 3.2.1.1: Message integrity and anti-replay

The Authentication Header (AH) contains a cryptographic checksum on the entire datagram. The AH is inserted after the original IP header in the IPSec datagram, as shown in Figure 3.5. AH offers both data integrity and replay protection (the receiver tracks datagrams using a 64-bit counter).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

If you've carefully followed the installation and configuration steps outlined in Chapter 2, and Chapter 3, your bastion host is now quite secure. However, there is no way of administering it remotely!

NT's standard remote administration tools such as Event Viewer and Server Manager are based on RPC using NetBIOS. The problem with NetBIOS (as I discussed in Chapter 1) is that it's considered unacceptably unsecure in perimeter networks. Hence, we must find alternative tools for administering and monitoring the Windows NT host.

The basic requirements for any new remote management tools are:

Authentication: Both user and source IP address authentication are required to restrict unauthorized access to the servers. IP address authentication means access to certain services can be allowed or rejected based on the IP address of the client.
Encryption: Since we are performing administrative tasks, such as adding users and changing passwords, all sessions must be encrypted.
Ability to use the Windows NT GUI tools: It's not possible to perform all administration tasks using the command prompt. Hence, we need some kind of remote graphics console.
Ability to transfer files from and to the remote system: It's often important to be able to transfer files to your bastion hosts in a simple way.

This chapter presents three different solutions for remote management of Windows NT/Windows 2000 servers:

Symantec pcAnywhere v9.x: A very popular commercial software package that works on both Windows NT 4.0 and Windows 2000 systems.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Symantec's pcAnywhere product has become the de facto standard remote console solution on Windows NT. It has many features and good security options (128-bit RC4 encryption using the MS CryptoAPI and host IP address authentication), and it's relatively easy to configure and use. It also includes an excellent file transfer client. A sample pcAnywhere session is shown in Figure 4.1.

Figure 4.1: A sample pcAnywhere session

pcAnywhere uses one well-known TCP port (tcp/5631) for remote sessions. Another well-known port (udp/5632) is used to query the status of remote hosts. You only need to allow tcp/5631 from your management clients to your bastion hosts through your firewalls.

A pcAnywhere license costs about $170 if you buy it online from Symantec.

This section explains the special configuration steps you must perform when installing pcAnywhere 9.x on a bastion host:

Start the installation.
Use the custom installation method and deselect the two optional components, shown in Figure 4.2.

Figure 4.2: The pcAnywhere Custom Setup dialog box

Reboot the system when prompted to do so.
When the system has rebooted, log on and click on the "Symantec pcAnywhere" shortcut on the Start menu.
pcAnywhere runs a Setup wizard the first time it starts. Cancel the wizard and delete all items in the "Be a Host PC" view, as shown in Figure 4.3.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

If you run a site with Windows 2000 systems, you might want to use the built-in Terminal Services (TS) in Windows 2000 (Server versions only) for remote administration.

Terminal Services is based on Microsoft's Remote Desktop Protocol (RDP). RDP is a Microsoft proprietary protocol. Terminal Services does not provide built-in support for file transfer (see Section 4.2.2 later in this chapter). RDP uses only one port (tcp/3389), which is good. Also, TS remote administration supports two concurrent remote users.

pcAnywhere cannot run on a Windows 2000 Server that has Terminal Services configured.

If you want to use Terminal Services for remote administration, you can always combine it with IPSec (transport mode) to add an additional layer of security.

Follow these steps to set up Terminal Services on a bastion host:

Install the Terminal Services component by clicking Add/Remove Programs in the Control Panel, and then clicking Add/Remove Windows Components. There's no need to install the Terminal Services Licensing service when using the remote administration mode. The Windows Components dialog box is shown in Figure 4.8.

Figure 4.8: The Windows Components dialog box

Configure Terminal Services to use the remote administration mode.

Terminal Services can run in either remote administration mode or application server mode. To set up a dedicated application server with Terminal Services, separate licenses are needed. The remote administration feature is included in the Windows 2000 Server license. In this case, I chose to configure the Terminal Services for remote administration as shown in Figure 4.9.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This section describes the third remote administration solution—one that is based on a variety of freely available components.

The Secure Shell (SSH) is a suite of programs that allows a user to log on to, or execute commands on, another computer over the network. SSH also allows copying files from and to a remote host. This is all done in a secure manner — hence the name Secure Shell. SSH is intended as a replacement for the notoriously unsecure Berkeley "r" commands: rlogin , rsh/remsh , and rcp.

There are SSH implementations available for many platforms. These implementations allow, for example, accessing the Windows NT command prompt from a computer running Unix or vice versa. They even allow getting a remote Windows NT graphics console with mouse and keyboard in a secure manner from a Unix box; I describe this later, in Section 4.3.6."

SSH was developed by Tatu Ylönen. Originally it was free software, but after Version 1.2.12 the license was made more restrictive. The current reference implementations of SSH can't be used for commercial use without getting a license from Datafellows (http://www.datafellows.com/ ). Another problem with the reference implementations is that they use patented algorithms like IDEA and the RSA cryptosystem (but note that RSA's U.S. patent expired on September 20, 2000); see Section 1.5 in Chapter 1 for a summary of cryptographic algorithms commonly used in Windows NT systems.

A Swedish programmer, Björn Grönvall, started to fix bugs in the last free 1.2.12 release of SSH in late 1999. He called this effort OSSH. The OpenBSD team became aware of OSSH and started a project called OpenSSH based on Grönvall's work. The first release of OpenSSH (http://www.openssh.com/ ) was available for OpenBSD 2.6 only two months later. Other groups have become interested in OpenSSH and have started porting it to other operating systems. OpenSSH for Windows NT/2000 is available from the Franken Archives FTP site (

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Backups are a very important part of any computer operation. Don't neglect them! This chapter discusses the special procedures to follow when backing up a bastion host. It also provides an introduction to the built-in backup software in Windows NT and Windows 2000.

The most important general principles of backup and recovery are:

Always create a "golden image" of your systems before bringing them online (see Section 5.3 later in this chapter).

You may be forced to build separate backup networks for performance reasons; be careful not to short-circuit your firewall architecture with these networks.

Store backups in a fireproof safe at another physical location.

Be sure to test restore procedures at regular intervals.

Your organization probably already has a backup policy in place that defines how backups and restores should be handled. Such a backup policy should at least contain answers to the following questions:

Who is responsible for making backups of your data?
How often should backups be performed?
Where should the backup media be stored?
Who is authorized to restore data to a system?

If you already have a general backup policy for your site, you must decide whether it fits the needs of the bastion hosts in the perimeter network. If the general policy doesn't fit, you need to define a special backup policy for the systems in the perimeter network.

Backups can be performed using either a local storage device or a remote storage device. The backup method you choose depends upon your needs and your environment. In a small environment, local backups might be the best solution. If you have a larger number of hosts, you may prefer to use remote backups to centralize management and data storage.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter

Table of Contents

Section 3.2.1.1: Message integrity and anti-replay