Securing Servers: Standards and Best PracticesWhen 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.
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
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:
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:
|