How to Secure Your Web Server Operating System

Securing the Web Server Operating System

Protecting a Web server from compromise involves hardening the underlying Operating System (OS), the Web server application, and the network to prevent malicious entities from directly attacking the Web server. The first step in securing a Web server is hardening the underlying OS.

All commonly available Web servers operate on a general-purpose OS. Many security issues can be avoided if the OSs underlying the Web servers are configured appropriately.

Default hardware and software configurations are typically set by manufacturers to emphasize features, functions, and ease of use, at the expense of security.

Because manufacturers are unaware of each organization’s security needs, each Web server administrator must configure new servers to reflect their organization’s security requirements and reconfigure them as those requirements change.

The practices recommended here are designed to help Web server administrators configure and deploy Web servers that satisfy their organizations’ security requirements.

Web server administrators managing existing Web servers should confirm that their systems address the issues discussed.

The techniques for hardening different OSs vary greatly; therefore, this section includes the generic procedures common in securing most OSs.

Security configuration guides and checklists for many OSs are publicly available; these documents typically contain recommendations for settings that improve the default level of security, and they may also contain step-by-step instructions for securing systems.

In addition, many organizations maintain their own guidelines specific to their requirements. Some automated tools also exist for hardening OSs, and their use is strongly recommended.

Five basic steps are necessary to maintain basic OS security:

• Planning the installation and deployment of the host OS and other components for the Web server
• Patching and updating the host OS as required
• Hardening and configuring the host OS to address security adequately
• Installing and configuring additional security controls, if needed
• Testing the host OS to ensure that the previous four steps adequately addressed all security issues.

Patch and Upgrade the Web Server Operating System

Once an OS is installed, applying needed patches or upgrades to correct for known vulnerabilities is essential. Any known vulnerabilities an OS has should be corrected before using it to host a Web server or otherwise exposing it to untrusted users.

To adequately detect and correct these vulnerabilities, Web server administrators should do the following:

• Create, document, and implement a patching process.
• Identify vulnerabilities and applicable patches.
• Mitigate vulnerabilities temporarily if needed and if feasible (until patches are available, tested, and installed).
• Install permanent fixes (commonly called patches, hotfixes, service packs, or updates).

Administrators should ensure that Web servers, particularly new ones, are adequately protected during the patching process. For example, a Web server that is not fully patched or not configured securely could be compromised by threats if it is publicly accessible while it is being patched. When preparing new Web servers for deployment, administrators should do either of the following:

• Keep the servers disconnected from networks or connect them only to an isolated “build” network until all patches have been transferred to the servers through out-of-band means (e.g., CDs) and installed, and the other configuration steps have been performed.
• Place the servers on a virtual local area network (VLAN) or other network segment that severely restricts what actions the hosts on it can perform and what communications can reach the hosts—only allowing those events that are necessary for patching and configuring the hosts. Do not transfer the hosts to regular network segments until all the configuration steps listed above have been performed.

Administrators should generally not apply patches to Web servers without first testing them on another identically configured system because patches can inadvertently cause unexpected problems with proper system operation. Although administrators can configure Web servers to download patches automatically, the servers should not be configured to install them automatically so that they can first be tested.

Remove or Disable Unnecessary Services and Applications

Ideally, a Web server should be on a dedicated, single-purpose host. When configuring the OS, disable everything except that which is expressly permitted—that is, disable all services and applications, reenable only those required by the Web server, and then remove the unneeded services and applications.

If possible, install the minimal OS configuration and then add or remove services and applications as needed. Choose the “minimal installation” option, if available, to minimize the effort required in removing unnecessary services. Furthermore, many uninstall scripts or programs are far from perfect in completely removing all components of a service; therefore, it is always better not to install unnecessary services.

Some common types of services and applications that should usually be disabled if not required include the following:

• File and printer sharing services (e.g., Windows Network Basic Input/Output System [NetBIOS] file and printer sharing, Network File System [NFS], File Transfer Protocol [FTP])
• Wireless networking services
• Remote control and remote access programs, particularly those that do not strongly encrypt their communications (e.g., Telnet)
• Directory services (e.g., Lightweight Directory Access Protocol [LDAP], Kerberos, Network Information System [NIS])
• Email services (e.g., Simple Mail Transfer Protocol [SMTP])
• Language compilers and libraries
• System development tools
• System and network management tools and utilities, including Simple Network Management Protocol (SNMP).

Removing unnecessary services and applications is preferable to simply disabling them through configuration settings because attacks that attempt to alter settings and activate a disabled service cannot succeed when the functional components are completely removed. Disabled services could also be enabled inadvertently through human error.

Eliminating or disabling unnecessary services enhances the security of a Web server in several ways:

• Other services cannot be compromised and used to attack the host or impair the services of the Web server. Each service added to a host increases the risk of compromise for that host because each service is another possible avenue of access for an attacker. Less is more secure in this case.
• Other services may have defects or may be incompatible with the Web server itself. By disabling or removing them, they should not affect the Web server and should potentially improve its availability.
• The host can be configured to better suit the requirements of the particular service. Different services might require different hardware and software configurations, which could lead to unnecessary vulnerabilities or negatively affect performance.
• By reducing services, the number of logs and log entries is reduced; therefore, detecting unexpected behavior becomes easier.

Organizations should determine the services to be enabled on a Web server. Services in addition to the Web server service that might be installed include database access protocols, file transfer protocols, and remote administration services. These services may be required in certain instances, but they may increase the risks to the server.

Whether the risks outweigh the benefits is a decision for each organization to make.

Configure Operating System User Authentication

For Web servers, the authorized users who can configure the OS are limited to a small number of designated Web server administrators and Webmasters. The users who can access the public Web server, however, may range from unrestricted to restricted subsets of the Internet community.

To enforce policy restrictions, if required, the Web server administrator should configure the OS to authenticate a prospective user by requiring proof that the user is authorized for such access. Even though a Web server may allow unauthenticated access to most of its services, administrative and other types of specialized access should be limited to specific individuals and groups.

Enabling authentication by the host computer involves configuring parts of the OS, firmware, and applications on the server, such as the software that implements a network service.

Although not normally the case for public Web servers, in special situations, such as high-value/high-risk sites, organizations may also use authentication hardware, such as tokens or one-time password devices.

Use of authentication mechanisms where authentication information is reusable (e.g., passwords) and transmitted in the clear over a network is strongly discouraged because the information can be intercepted and used by an attacker to masquerade as an authorized user.

To ensure the appropriate user authentication is in place, take the following steps:

• Remove or Disable Unneeded Default Accounts and Groups — The default configuration of the OS often includes guest accounts (with and without passwords), administrator or root level accounts, and accounts associated with local and network services. The names and passwords for those accounts are well known. Remove or disable unnecessary accounts to eliminate their use by attackers, including guest accounts on computers containing sensitive information. If there is no requirement to retain a guest account or group, severely restrict access to it and change the password in accordance with the organizational password policy.

For default accounts that need to be retained, change the names (where possible and particularly for administrator or root level accounts) and passwords to be consistent with the organizational password policy. Default account names and passwords are commonly known in the attacker community.

• Disable Non-Interactive Accounts — Disable accounts (and the associated passwords) that need to exist but do not require an interactive login. For Unix systems, disable the login shell or provide a login shell with NULL functionality (e.g., /bin/false).
• Create the User Groups — Assign users to the appropriate groups. Then assign rights to the groups, as documented in the deployment plan. This approach is preferable to assigning rights to individual users, which becomes unwieldy with large numbers of users.
• Create the User Accounts — The deployment plan identifies who will be authorized to use each computer and its services. Create only the necessary accounts. Permit the use of shared accounts only when no viable alternatives exist.
• Check the Organization’s Password Policy - Set account passwords appropriately. This policy should address the following: ** Length** — a minimum length for passwords. Specify a minimum length of at least eight characters, preferably twelve.

• Complexity — the mix of characters required. Require passwords to contain both uppercase and lowercase letters and at least one nonalphabetic character, and to not be a “dictionary” word.
• Aging — how long a password may remain unchanged. Require users to change their passwords periodically. Administrator or root level passwords should be changed every 30 to 120 days. The period for user-level passwords should be determined by the enforced length and complexity of the password combined with the sensitivity of the information protected. When considering the appropriate aging duration, the exposure level of user passwords should also be taken into account. Consideration should also be given to enforcing a minimum aging duration to prevent users from rapidly cycling through password changes to clear out their password history and bypass reuse restrictions.
• Reuse — whether a password may be reused. Some users try to defeat a password aging requirement by changing the password to one they have used previously. If possible, ensure that users cannot change their passwords by merely appending characters to the beginning or end of their original passwords (e.g., original password was “mysecret” and is changed to “1mysecret” or “mysecret1”).
• Authority — who is allowed to change or reset passwords and what sort of proof is required before initiating any changes.
• Password Security — how passwords should be secured, such as not storing passwords unencrypted on the mail server, and requiring administrators to use different passwords for their email administration accounts than their other administration accounts.

• Configure Computers to Prevent Password Guessing - It is relatively easy for an unauthorized user to try to gain access to a computer by using automated software tools that attempt all passwords. If the OS provides the capability, configure it to increase the period between login attempts with each unsuccessful attempt. If that is not possible, the alternative is to deny login after a limited number of failed attempts (e.g., three). Typically, the account is “locked out” for a period of time (such as 30 minutes) or until a user with appropriate authority reactivates it.

The choice to deny login is another situation that requires the Web server administrator to make a decision that balances security and convenience. Implementing this recommendation can help prevent some kinds of attacks, but it can also allow an attacker to use failed login attempts to prevent user access, resulting in a DoS condition. The risk of DoS from account lockout is much greater if an attacker knows or can surmise a pattern to your naming convention that allows them to guess account names.

Failed network login attempts should not prevent an authorized user or administrator from logging in at the console. Note that all failed login attempts, whether via the network or console, should be logged. If remote administration is not to be implemented, disable the ability for the administrator or root level accounts to log in from the network.

• Install and Configure Other Security Mechanisms to Strengthen Authentication — If the information on the Web server requires it, consider using other authentication mechanisms such as biometrics, smart cards, client/server certificates, or one-time password systems. They can be more expensive and difficult to implement, but they may be justified in some circumstances. When such authentication mechanisms and devices are used, the organization’s policy should be changed accordingly, if necessary. Some organizational policies may already require the use of strong authentication mechanisms.

Attackers using network sniffers can easily capture passwords passed across a network in clear text. However, passwords are economical and appropriate if properly protected while in transit. Organizations should implement authentication and encryption technologies, such as Secure Sockets Layer (SSL)/Transport Layer Security (TLS), Secure Shell (SSH), or virtual private networking (VPN), to protect passwords during transmission. Requiring user-friendly server authentication to be used with encryption technologies reduces the likelihood of successful man-in-the-middle and spoofing attacks.

Configure Resource Controls Appropriately

All commonly used modern server OSs provide the capability to specify access privileges individually for files, directories, devices, and other computational resources. By carefully setting access controls and denying personnel unauthorized access, the Web server administrator can reduce intentional and unintentional security breaches. For example, denying read access to files and directories helps to protect confidentiality of information, and denying unnecessary write (modify) access can help maintain the integrity of information.

Limiting the execution privilege of most system-related tools to authorized system administrators can prevent users from making configuration changes that could reduce security. It also can restrict the attacker’s ability to use those tools to attack the system or other systems on the network.

Install and Configure Additional Security Controls

Operating systems often do not include all of the security controls necessary to secure the OS, services, and applications adequately. In such cases, administrators need to select, install, and configure additional software to provide the missing controls. Commonly needed controls include the following:

• Anti-malware software, such as antivirus software, anti-spyware software, and rootkit detectors, to protect the local OS from malware and to detect and eradicate any infections that occur. Examples of when anti-malware software would be helpful include a Web administrator bringing infected media to the Web server and a network service worm contacting the server and infecting it.
• Host-based intrusion detection and prevention software, to detect attacks performed against the Web server, including DoS attacks. See host-based intrusion detection and prevention software.
• Host-based firewalls, to protect the server from unauthorized access.
• Patch management software to ensure that vulnerabilities are addressed promptly. Patch management software can be used only to apply patches or also to identify new vulnerabilities in the Web server’s OSs, services, and applications.

Some Web server administrators also install one or more forms of host-based intrusion detection or intrusion prevention software on their servers. For example, file integrity checking software can identify changes to critical system files.

When planning security controls, Web server administrators should consider the resources that the security controls will consume. A server’s performance could degrade if it does not have enough memory and processing capacity for the controls.

Security Testing the web Server Operating System

Periodic security testing of the OS is a vital way to identify vulnerabilities and to ensure that the existing security precautions are effective. Common methods for testing OSs include vulnerability scanning and penetration testing. Vulnerability scanning usually entails using an automated vulnerability scanner to scan a host or group of hosts on a network for application, network, and OS vulnerabilities. Penetration testing is a testing process designed to compromise a network using the tools and methodologies of an attacker. It involves iteratively identifying and exploiting the weakest areas of the network to gain access to the remainder of the network, eventually compromising the overall security of the network.

Vulnerability scanning should be conducted periodically, at least weekly to monthly, and penetration testing should be conducted at least annually. Both of these testing techniques are also applicable to testing Web server applications.

Testing generally should not be performed on the production Web server itself. Testing for patches and changes to the system should be performed on a separate system; this same testing environment should be used to perform security testing of the Web server.

Checklist for Securing the Web Server Operating System

Click image to print