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.
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
environment. It is unwise to place mission-critical servers at the feet
of administrators or in 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 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 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.
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.
|
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 permanently 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 2,
and click OK twice to save the settings.
|
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 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 individual can simply pull
up in the parking lot and access an organization’s local area network
(LAN) via a laptop computer and a standard wireless card. The standard
security employed by wireless networks, Wireless Encryption Protocol
(WEP), is effectively worthless because it can be cracked in several
minutes.
Controlling the network
ports and securing network switches are part of the securing strategy.
For organizations with wireless networks, more stringent precautions
must be taken. Deployment of wireless networks using the 802.1x protocol
vastly increases the security of the mechanism. Microsoft uses 802.1x
to secure its vast wireless network, and Windows Server 2008 R2 fully
supports the protocol.
For those organizations
without the time or resources to deploy 802.1x, the simple step of
placing wireless access points outside the firewall and requiring
virtual private network (VPN) access through the firewall can
effectively secure the wireless network. Even if trespassers were to
break the WEP key, they would be connected only to an orphaned network,
with no place to go.
Firewall Security
Deployment of an
enterprise firewall configuration is a must in any environment that is
connected to the Internet. Servers or workstations directly connected to
the Internet are prime candidates for hacking. Modern firewall
implementations such as Microsoft’s Internet Security and Acceleration
(ISA) 2006 offer advanced configurations, such as web proxying and
demilitarized zone (DMZ) configuration, as well. Proper setup and
configuration of a firewall in between a Windows Server 2008 R2 network
and the Internet are a must.
