Baseline Server Hardening
Baseline Server Hardening
There are several key requirements you must meet to ensure that the server hardening processes described in this section achieve their security goals:
- The base install of all operating system and post-operating system software comes from a trusted source.
- Servers are only connected to a completely trusted network during the install and hardening processes.
- The base install includes all current service packs and is reasonably current with regard to post-service pack updates.
- After the base install finishes, you must update the target servers.
If you follow these guidelines, you will begin the hardening process on servers that you have updated and built from trustworthy software sources.
Use of Group Policy and Security Templates in Basic Server Hardening
The application of Group Policy objects was covered in Group Policy Templates. The guidelines and templates described in that section will begin the process of basic server hardening. This section describes important security steps and addresses whether Group Policy can automatically implement them. In some cases, you need to customize a security template, using the generic instructions for modifying security templates found in the Group Policy Templates section to implement a recommendation.
Use NTFS Only
The Windows NTFS file system (NTFS) partitions offer access controls and protections that are not available with the file allocation table (FAT), FAT32, or FAT32x file systems. Make sure that you format all partitions on your server using NTFS. If necessary, use the Convert tool to convert your FAT partitions to NTFS.
If you use the Convert tool, it will set the access control lists (ACLs) for the converted drive to Everyone: Full Control. Use the Fixacls.exe tool from the Microsoft Windows Server 2003 Resource Kit to reset the ACLs to values that are more reasonable and recommended in Best Practices for Centralized Management.
Use a Strong Password on the Administrator Account
Windows Server 2003 allows passwords of up to 127 characters. In general, longer passwords are stronger than shorter ones, and passwords with several character types (letters, numbers, punctuation marks, and nonprinting ASCII characters generated by using the ALT key and three-digit key codes on the numeric keypad) are stronger than alphabetic or alphanumeric-only passwords.
For maximum protection, ensure the Administrator account password is at least nine characters long and that it includes at least one punctuation mark or nonprinting ASCII character in the first seven characters. In addition, the Administrator account password should not be synchronized across multiple servers. You should use different passwords on each server to raise the level of security in the workgroup or domain.
Rename the Administrator Account
A very simple yet effective procedure that should be a standard part of the hardening process for all servers is to rename the built-in administrator account.
This account is the primary point for attacks, because if successful, the account provides the attacker with virtually unlimited rights. Rename the account, and create a new user account named Administrator that has not been granted special privileges. You should give this latter account a strong and complex password. You do not need to use this account; it merely serves as a decoy for attack efforts. Do this at the domain and local computer levels.
The best policy is to rename the Administrator account to a unique user name that is different on all servers; this minimizes the potential that somehow an attacker will be successful in determining that this new account is the Administrator account in disguise and also managing to crack its password. Because this account is so central to legitimate management tasks, you may view using unique names on every server as unmanageable in practice. In any case, the password for the disguised Administrator account should be unique and different from the other Administrator accounts in the enterprise.
Disable the Guest Account
By default, the Guest account is disabled on systems running Windows Server 2003. If the Guest account is enabled, you should disable it.
Set Account Lockout Policy
Windows Server 2003 includes an account lockout feature that will disable an account after a number of logon failures specified by an administrator. For maximum security, enable lockout after 3 to 5 failed attempts, reset the count after not less than 30 minutes, and set the lockout duration to Forever (until admin unlocks).
This is a part of Windows Server 2003 policy and is set in the Domain Security Policy tool, which you can find under Administrative Tools on a domain controller. Select Security Settings, then select Account Policies and click Account Lockout Policy. To set lockout duration to Forever, enter a "0." Because this is domain-wide policy, you only have to perform this action once.
For service providers who may want specialized account security, the Windows Server 2003 Resource Kit includes a tool that allows you to adjust some account properties that are not accessible through the normal management tools. This tool, Passprop.exe, allows you to lock out the administrator account using the /adminlockout switch.
Remove All Unnecessary File Shares
Remove all unnecessary file shares on the system to prevent possible information disclosure and to prevent malicious users from using the shares as an entry to the local system.
Set Appropriate ACLs on All Necessary File Shares
By default all users have Full Control permissions on newly created file shares. You should set ACLs on all shares that are required on the system so that users have the appropriate share-level access (for example, Everyone = Read).
Install Antivirus Software and Updates
You should use antivirus software and processes to keep up to date on the latest virus threats. Such protection will only offer value if it is both possible to install and execute code on the target computer; and the protection technology is able to detect and neutralize such efforts. Nevertheless, the ongoing discovery of system shortfalls - such as buffer overruns and the like - that allow a hostile entity to run rogue bits on a computer certainly makes a case for the use of antivirus software.
The Hosted Messaging and Collaboration test result data has not included the potential impact of third-party virus scanning tools. The Hosted Messaging and Collaboration team performed all scalability and procedural testing without the installation of third-party virus scanning tools.
For more information on security viruses is available at the List of antivirus software vendors.
The Security Configuration Wizard Roles provided as part of the solution offer baseline security for your hosting environment. Guidance on applying more stringent policies is available from Microsoft in the Windows 2003 Security Guide and the Windows Server 2003 SP1 documentation.