Server-Level Security - Deploying Physical Security
(Page 2 of 7 )
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 into 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 login 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 may be wise to utilize these mechanisms to secure a server environment.
Restricting Login Access All servers should be configured to allow only administrators to physically log in 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 logins. To restrict login access, follow these steps:
Choose Start, All Programs, Administrative Tools, Local Security Policy.
In the left pane, navigate to Security Settings\Local Policies\User Rights Assignment.
Double-click Allow Log On Locally.
Remove any users or groups that do not need access to the server, as illustrated in Figure 12.1. (Keep in mind that, on Web servers, the IUSR_SERVERNAME account will need to have log on locally access to properly display Web pages.) Click OK when finished.
Note - If you replace Local Security Policy in the restriction lockdown instructions in step 1 with Domain Security Policy, you will be able to carry out these same instructions on a Windows Server 2003 domain controller.
Note - A Group Policy set on 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 setting up these types of Group Policies, refer to Chapter 21, "Windows Server 2003 Group Policies."
Using the Run As 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 out, any persons passing by can muck around with the network infrastructure as they please.
Figure 12.1
Restricting login access.
For this reason, it is wise to consider a login strategy that incorporates the Run As command that is embedded in Windows Server 2003. Essentially, this means that all users, including IT staff, log in with restricted, standard User accounts. When administrative functionality is required, IT support personnel can invoke the tool or executable by using the Run As command, which effectively gives that tool the administrative capabilities of the account that were designated by Run As. If an administrator leaves a workstation console without logging out, 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:
Navigate to (but do not select) Start, All Programs, Administrative Tools, Computer Management.
Right-click Computer Management in the program list and then choose Run As.
In the Run As dialog box, shown in Figure 12.2, choose the credentials under which you want to run the program and click OK.
Note - A command-line version of the Run As tool allows for the same type of functionality. For example, the following syntax opens the command-prompt window with administrator access:
runas /user:DOMAINNAME\administrator cmd
Figure 12.2
Using the Run As command.
In addition to the manual method of using Run As, an administrator's desktop can be configured to have each shortcut automatically prompt for the proper credentials upon entering an administrative tool. For example, the Active Directory Users and Computers MMC snap-in can be set to permanently prompt for alternate credentials by following these steps:
Choose Start, All Programs, Administrative Tools.
Right-click Computer Management and choose Properties.
Click the Advanced button.
Check the Run with Different Credentials box, as shown in Figure 12.3, and click OK twice to save the settings.
Figure 12.3
Running a shortcut with alternate credentials.
Note - Ironically, administrative access is sometimes required to be able to change some of the shortcut properties. Consequently, you might need to log in as a user with higher privileges to set up the shortcuts on other users' profiles.
Using Smartcards for Login Access The ultimate in secured infrastructures utilize so-called smartcards for login access; these smartcards are fully supported in Windows Server 2003. A smartcard is a credit card–sized piece of plastic with an encrypted microchip embedded within. Each user is assigned a unique smartcard and an associated PIN. Logging in to a workstation is as straightforward as inserting the smartcard into a smartcard 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 each smartcard be removed after logging in to a console. In this scenario, users insert into the smartcard reader a smartcard that is physically attached to their person via a chain or string. After entering their PIN, they log in and perform all necessary functions. Upon leaving, they simply remove the smartcard from the reader, which automatically logs them off the workstation. In this scenario, it is nearly impossible for users to forget to log out because they must physically detach themselves from the computer to leave.
Securing Wireless Networks Wire 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 LAN via a laptop computer and a standard 8s02.11b wireless card. The standard security employed by wireless networks, 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 2003 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 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) 2000/2004 offer advanced configurations, such as Web proxying and DMZ configuration, as well. Proper setup and configuration of a firewall in between a Windows Server 2003 network and the Internet are a must.
Note - Installing ISA Server 2000 on Windows Server 2003 is technically possible but can be difficult. The installation will complete (with several error messages), but it is important to apply ISA Service Pack 1 immediately after installation on a Windows Server 2003 system. On the other hand, the newest version, ISA Server 2004, natively supports installation on Windows Server 2003.
Next: Hardening Server Security >>
More MS SQL Server Articles
More By Sams Publishing
|
 This article is excerpted from chapter 12 of MS Windows Server 2003 Unleashed 2nd edition, written by Rand Morimoto (Sams, 2004; ISBN: 0672326671). Check it out at your favorite bookstore. Buy this book now.
|
|
