Securing Servers: Standards and Best Practices

Securing Servers: Standards and Best Practices

When it comes to securing enterprise domain controllers and member servers in the enterprise, there are several considerations. Physical security plays a large role. The doors to the server room (or whatever room is being used to house the server) should be locked at all times by some means. Whether it's by key, smart card, or combination lock, the door should be locked and access to the room should be limited to those who need it. If someone needs access who does not normally have it, you can issue a temporary badge to the room or have someone with access to the room escort the person in and stay there until he or she leaves the room. When servers are installed in server racks in rooms with doors that close and lock, keeping them locked should be a standard practice, with the keys left in the charge of the responsible person.

Notes from the Field: Can You Be Too Secure?

In a nutshell , no. Many times I have been accused of being overzealous about mentioning security in the IT environment, but whenever possible, I try to bring the topic into the real world so that others see it the way I do.

"Lock server cabinets and the server room doorsisn't that overkill? It takes some extra time to relock things, especially server cabinet doors; it's just easier to leave them unlocked when the outer door to the room itself locks."

I respond by asking people if they have a garage for their cars or use a steering wheel lock, such as The Club, to secure their cars . They usually answer yes. When they do, I ask the following questions:

"Isn't locking your car doors inside your locked garage at home overkill? Doesn't putting The Club on your steering wheel take a little extra time? Why do it? The car doors are locked."

"It often deters someone who is considering the action" is the typical reply. I usually don't talk right away after this reply because my point often sinks in without any further effort from me.

One word of caution about locking up server cabinet doors: Make sure the doors have proper vents (that is, slotted doors), and make sure the servers are not susceptible to overheating . Just because the room is 68 degrees with a relative humidity of 50% doesn't mean that servers #5 and #6 in rack 12 are operating at that temperature.

Remember : With the doors closed, servers stacked in the rack with four to six drives spinning at 10,000RPM to 15,000RPM inside each system, and dual redundant power supplies engaged, the servers are throwing off quite a bit of heat. The systems in the center are insulated to a degree, but you often find that the center and upper systems catch all the rising heat, especially in an enclosed rack.

When it comes to securing domain controllers, ask why someone needs to log on locally at the console. This question is valid for many member servers as well. There should be a valid business reason (and proper change control) for working locally on a domain controller or any server system when most work can be done remotely with remote tools.

This brings me to my next pointlimiting administrative access. Very few people should have Domain Administrator access, and even fewer should have Enterprise administrator permissions. Domain Administrator access should be limited to a select few people who need that level of access control over the domain. These users should also be trained and instructed (if they are not fully aware already) on the use of these domainwide unrestricted accounts.

They should not log in with administrative access to perform day-to-day work on their desktop systems and on servers except when necessary. More often than not, logging in on a daily basis with a standard user account (or perhaps a power user or server operator account) is usually good enough.

When additional rights are necessary, administrators can always run the Run As service to be authenticated to the services they need to access with their administrator account.

Power users on local systems can, by default, install programs that do not modify operating system files or install system services. They can also create and manage local user accounts and groups, stop and start system services, and modify resources on systems through the Control Panel.

Server operators can log on interactively to domain controllers and create and delete shared resources. They also have permissions to start and stop some domainwide services, back up and restore data, format disk drives, and shut down the system.

The RUNAS command enables you to run EXE and MMC programs as another user. In this way, you can run the program at a higher level of privilege than your current settings allow. The Run As service requires the Secondary Logon service to be running on the local system. To start the Run As service for Control Panel programs, you still need to hold the Shift key down, right-click the shortcut you want to run, and choose Run As. For other Start menu icons and actual EXEs from within Windows Explorer, you just need to right-click them to get RUNAS to appear on the shortcut menu. You can also issue the command from the Run dialog box or at a command prompt.

When providing Domain Administrator access, users should be given their own accounts so that if necessary, administrative actions can be traced back to the specific user. If everyone used the default Administrator account, there would be no way to know who performed a certain action because it could have been anyone with that account access. Best practices dictate that the default Administrator account should be renamed ; use a complex password and limit access to that password for emergencies only.

Enterprise Administrator accounts should be handed out even more sparingly because they have Full Control permissions over all domains in the enterprise. They too should be assigned to just those users who need this level of access and protected even more rigorously.

Many white papers and KnowledgeBase articles state that Windows Server 2003 is "secure out of the box." I would counter that it is "more secure out of the box" because the only system that's truly secure is one that is "never taken out of the box." There have been great strides to make Windows Server 2003 as secure out of the box as possible. These efforts have brought the server operating system light years ahead of Windows NT Server 4 and Windows 2000 Server.

On the one hand, over half of the system services installed by default under the basic Windows Server 2003 installation are not enabled for automatic startup (instead, they're set to Manual) or are outright disabled. Most network services are not enabled until an administrator explicitly does so. With all these advances in default settings, it is still up to system administrators to have (or get) the required level of training and acquire the necessary level of knowledge to keep systems secure.

As mentioned earlier, there are a few steps you can take to limit system controls. In addition to limiting services on systems to only those who need them, you can, for example, take steps to allow only necessary traffic on your networks.

From an external to internal perspective, there is no need to allow certain port traffic through your firewall at the network's perimeter if this type of access is not necessary. You might use FTP (port 20 and 21) to push data from one segregated subnet to another on the WAN, but if you never cross the firewall to the public network (in or out), there is no need to have that port open full time. If organizational needs required opening this port, however, you could enable change controls to make the necessary configuration changes and then close the ports when they're no longer needed. Table 2.6 explains some of the more commonly used default Transmission Control Protocol (TCP) ports.

Table 2.6. Commonly Used TCP Ports

Port Number	Use
7	ECHO
18	Message Send Protocol (MSP)
20	FTP - Data
21	FTP - Control
22	SSH Remote Login Protocol
23	Telnet
25	Simple Mail Transfer Protocol (SMTP)
29	MSG ICP
37	Time
42	Host Name Server (Nameserv)
43	WhoIs
49	Login Host Protocol (Login)
53	Domain Name System (DNS)
69	Trivial File Transfer Protocol (TFTP)
70	Gopher Services
79	Finger
80	HTTP
103	X.400 Standard
108	SNA Gateway Access Server
109	POP2
110	POP3
115	Simple File Transfer Protocol (SFTP)
118	SQL Services
119	Newsgroup (NNTP)
137	NetBIOS Name Service
139	NetBIOS Datagram Service
143	Internet Message Access Protocol (IMAP)
150	NetBIOS Session Service
156	SQL Server
161	Simple Network Management Protocol (SNMP)
179	Border Gateway Protocol (BGP)
190	Gateway Access Control Protocol (GACP)
194	Internet Relay Chat (IRC)
197	Directory Location Service (DLS)
389	Lightweight Directory Access Protocol (LDAP)
396	Novell NetWare over IP
443	HTTPS
444	Simple Network Paging Protocol (SNPP)
445	Microsoft-DS
458	Apple QuickTime
563	SNEWS
569	MSN
1080	Socks

If there is no reason to allow this port traffic, the outside firewalls should deny it. This is especially critical for demilitarized zone (DMZ) systems that Internet users access; you should have those firewalls finely tuned to only the necessary traffic, and you might want to consider blocking the ports on the servers themselves .

One method to stop traffic to specific servers is by using Internet Connection Firewall (ICF). For example, if you have an FTP server in the DMZ next to an IIS server, the FTP server could be subjected to port 80 attacks because the firewall allows that traffic to pass through to connect to the IIS server. If port 80 is open on the FTP server (it would be by default), the system could be compromised on that allowed port. You can configure ICF on the server to deny that traffic. To do that, follow these steps:

1. Open the Properties dialog box of your local area connection.

2. In the Advanced tab, select the check box in the Internet Connection Firewall section (see Figure 2.17). After selecting this option, the grayed out Settings button is available.

   Figure 2.17. You can enable ICF in the Advanced tab of the Local Area Network Connection Properties dialog box.

   

3. Click the Settings button and, in the Services tab of the Advanced Settings dialog box (see Figure 2.18), configure the services you want to have access to the local system by selecting the corresponding check boxes. (By default, after ICF is enabled, no traffic is allowed to pass inward to the system.)

   Figure 2.18. You can configure services to allow inbound traffic via the Services tab of the Advanced Settings dialog box.

   

4. If a service or TCP port is not listed but required, you can add it by clicking the Add button and supplying the TCP port number, service name, and any other pertinent information.

ICF also enables you to set logging information on system attempts and Internet Control Message Protocol (ICMP) traffic behavior. Network cards on servers can also be configured to allow only specific traffic.

If you are concerned that ICF could be defeated, you can configure the TCP/IP protocol bound to the specific network card to allow only specific traffic. To do this, follow these steps:

1. Select the General tab in the Local Area Connection Properties dialog box.

2. Select Internet Protocol (TCP/IP) and click the Properties button (see Figure 2.19) to open the Internet Protocol Properties dialog box.

   Figure 2.19. You can configure TCP/IP filtering by selecting TCP/IP in the list and clicking the Properties button.

   

3. The Internet Protocol Properties dialog box has only the General tab. Click the Properties button to open the Advanced TCP/IP Settings dialog box. Select the Options tab and click TCP/IP Filtering (see Figure 2.20).

   Figure 2.20. You configure TCP/IP filtering via the TCP/IP Filtering dialog box.

   

4. As you can see in the TCP/IP Filtering dialog box, by default, all traffic is permitted. To configure an adapter to permit only specific TCP and/or UDP traffic based on port number, select the Permit Only radio button above TCP Ports or UDP Ports (or both). You can also select the Enable TCP/IP Filtering (All Adapters) check box to enable these settings on all installed network adapters in the system that are bound to TCP/IP.

In discussions of local firewalling, ICF is often a main point of contention . You should be aware of the "old school" method of port filtering in the TCP/IP Filtering dialog box outlined in this section.

Note that limiting the IIS server to ports 80 and 443 or the SMTP server to port 25 traffic means that domain services, such as LDAP and DNS registration, are not available to these systems because they are blocking all but those listed allowed ports. Also, a port 80 attack using a known vulnerability on an unpatched Web server will be successful because Web traffic rides port 80, as do certain attacks.