Windows Server 2008 R2 Unleashed (88 page)

fairly or unfairly, to be an oxymoron. High-profile vulnera-

bilities and viruses that were exploited in the legacy

. Using Windows Server Update

Windows NT 4.0 and Windows 2000 Server operating

Services

systems often made organizations wary of the security, or

lack of security, that was built in to Microsoft technologies.

In direct response to this criticism, security since the devel-

opment of Windows Server 2003 has become the major, if

not the most important, priority for the development team.

ptg

Windows Server 2008 R2 continues this trend, with

improvements in functionality such as Server Core and a

built-in intelligent firewall.

This chapter focuses on the server-side security mechanisms

in Windows Server 2008 R2. Improved features such as the

intelligent integrated firewall are explained in detail.

Particular emphasis is placed on the importance of keeping

servers up to date with security patches through such utili-

ties as Windows Server Update Services, a major improve-

ment to Windows security. In addition, file-level security,

physical security, and other critical server security consider-

ations are presented.

Defining Windows Server 2008 R2

Security

Security on the server level is one of the most important

considerations for a network environment. Servers in an

infrastructure not only handle critical network services, such

as domain name system (DNS), Dynamic Host Configuration

Protocol (DHCP), directory lookups, and authentication, but

420

CHAPTER 13

Server-Level Security

they also serve as a central location for most, if not all, critical files in an organization’s

network. Subsequently, it is important to establish a server-level security plan and to gain a

full understanding of the security capabilities of Windows Server 2008 R2.

Outlining Microsoft’s Trustworthy Computing Initiative

On the heels of several high-profile viruses and security holes, Bill Gates developed what

became known as the Trustworthy Computing initiative. The basics of the initiative boiled

down to an increased emphasis on security in all Microsoft technologies. Every line of

code in Windows Server was combed for potential vulnerabilities, and the emphasis was

shifted from new functionality to security. What the initiative means to users of Microsoft

technology is the fact that security has become a major priority for Microsoft, and

Windows Server 2008 R2 is the third major server release after Windows Server 2003 that

uses this concept.

Common Language Runtime

All Microsoft code is verified through a process called common language runtime. It

processes application code and automatically checks for security holes that can be caused

by mistakes in programming. In addition, it scrutinizes security credentials that are used

ptg

by specific pieces of code, making sure that they perform only those actions that they are

supposed to. Through these techniques, the common language runtime effectively reduces

the overall threat posed to Windows Server 2008 R2 by limiting the potential for exploita-

tions and vulnerabilities.

Understanding the Layered Approach to Server Security

Security works best when it is applied in layers. It is much more difficult to rob a house,

for example, if a thief not only has to break through the front door, but also has to fend

off an attack dog and disable a home security system. The same concept applies to server

security: Multiple layers of security should be applied so that the difficulty in hacking into

a system becomes exponentially greater.

Windows Server 2008 R2 seamlessly handles many of the security layers that are required,

utilizing Kerberos authentication, NTFS file security, and built-in security tools to provide

for a great deal of security right out of the box. Additional security components require

that you understand their functionality and install and configure their components.

Windows Server 2008 R2 makes the addition of extra layers of security a possibility, and

positions organizations for increased security without sacrificing functionality.

Deploying Physical Security

One of the most overlooked but perhaps most critical components of server security is the

actual physical security of the server itself. The most secure, unbreakable web server is

powerless if a malicious user can simply unplug it. Worse yet, someone logging on to a

critical file server could potentially copy critical data or sabotage the machine directly.

Deploying Physical Security

421

Physical security is a must for any organization because it is the most common cause of

security breaches. Despite this fact, many organizations have loose levels, or no levels, of

physical security for their mission-critical servers. An understanding of what is required to

secure the physical and logon access to a server is, consequently, a must.

Restricting Physical Access

Servers should be physically secured behind locked doors, in a controlled-access environ-

ment. It is unwise to place mission-critical servers at the feet of administrators or in

13

similar, unsecure locations. Rather, a dedicated server room or server closet that is locked

at all times is the most ideal environment for the purposes of server security.

Most hardware manufacturers also include mechanisms for locking out some or all of the

components of a server. Depending on the other layers of security deployed, it might be

wise to utilize these mechanisms to secure a server environment.

Restricting Logon Access

All servers should be configured to allow only administrators to physically log on to the

console. By default, such use is restricted on domain controllers, but other servers such as

ptg

file servers, utility servers, and the like must specifically forbid these types of logons. To

restrict logon access, follow these steps:

1. Click Start, All Programs, Administrative Tools, Local Security Policy.

2. In the node pane, navigate to Security Settings, Local Policies, User Rights

Assignment.

3. Double-click Allow Log On Locally.

4. Remove any users or groups that do not need access to the server, as illustrated in

Figure 13.1. (Keep in mind that, on web servers, the IUSR_SERVERNAME account

needs to have Log On Locally access to properly display web pages.) Click OK when

you are finished.

NOTE

If you replace Local Security Policy in the restriction lockdown instructions in step 1

with the Domain Controllers Security Policy, you will be able to carry out these same

instructions on a Windows Server 2008 R2 domain controller.

NOTE

A group policy set at an OU level can be applied to all servers, simplifying this task and

negating the need to perform it manually on every server. For more information on set-

ting up these types of group policies, refer to Chapter 27, “Group Policy Management

for Network Clients.”

422

CHAPTER 13

Server-Level Security

FIGURE 13.1

Restricting logon access.

ptg

Using the Run As Administrator Command for Administrative Access

Logging off administrators after using any and all workstations and servers on a network is

often the most difficult and tedious security precaution. If an administrator forgets, or

simply steps away from a workstation temporarily without logging off, any persons

passing by can muck around with the network infrastructure as they please.

For this reason, it is wise to consider a logon strategy that incorporates the Run As

Administrator command that is embedded in Windows Server 2008 R2. Essentially, this

means that all users, including IT staff, log on with restricted, standard user accounts.

When administrative functionality is required, IT support personnel can invoke the tool

or executable by using the Run As Administrator command, which effectively gives that

tool administrative capabilities. If an administrator leaves a workstation console without

logging off, the situation is not critical because the console will not grant a passerby full

administrator access to the network.

The following example illustrates how to invoke the Computer Management MMC snap-

in using the Run As command from the GUI interface:

1. Navigate to (but do not select) Start, All Programs, Administrative Tools, Computer

Management.

2. Hold down the Shift key, right-click Computer Management in the program list, and

then choose Run As Different User.

3. In the Run As dialog box, choose the credentials under which you want to run the

program, and click OK.

Deploying Physical Security

423

In addition to the manual method of using Run As, an administrator’s desktop can be

configured to have each shortcut automatically run as a computer administrator. For

example, the Active Directory Users and Computers MMC snap-in can be set to perma-

nently run with elevated privileges by following these steps:

1. Click Start, All Programs, Administrative Tools.

2. Right-click Computer Management and choose Properties.

3. On the Shortcut tab, click the Advanced button.

4. Check the Run As Administrator check box, as shown in Figure 13.2, and click OK

twice to save the settings.

13

ptg

FIGURE 13.2

Running a shortcut with Administrator privileges.

NOTE

Ironically, administrative access is sometimes required to be able to change some of

the shortcut properties. Consequently, you might need to log on as a user with higher

privileges to set up the shortcuts on other users’ profiles.

Using Smart Cards for Logon Access

The ultimate in secured infrastructures utilize so-called smart cards for logon access; these

smart cards are fully supported in Windows Server 2008 R2. A smart card can exist in

multiple forms, commonly as a credit card-sized piece of plastic with an encrypted

microchip embedded within or as a USB key. Each user is assigned a unique smart card

and an associated PIN. Logging on to a workstation is as straightforward as inserting the

smart card into a smart card reader and entering in the PIN, which can be a combination

of numbers and letters, similar to a password.

Security can be raised even higher by stipulating that when the smart card is removed, the

user is automatically logged off the console. In this scenario, users insert into the smart

card reader a smart card that is physically attached to their person via a chain or string.

After entering their PIN, they log on and perform all necessary functions. Upon leaving,

they simply remove the smart card from the reader, which automatically logs them off the

424

CHAPTER 13

Server-Level Security

workstation. In this scenario, it is nearly impossible for users to forget to log off because

they must physically detach themselves from the computer to leave.

Securing Wireless Networks

Wireless security has always been an issue, but recent trends toward wireless networks

have made it even more so. Most organizations are shocked to see what kind of damage

can be done to a network simply by a person being able to connect via a network port.

The addition of wireless networks makes access even easier; for example, an unsavory indi-