Stick to the Essentials: Configuring Servers Securely
- Stick to the Essentials on the Server Host Machine
- Keep Operating Systems and Applications Software Up-to-Date
More than 99 percent of intrusions result from the exploitation of known vulnerabilities or configuration errors, even though countermeasures and solutions are available. This excerpt from The CERT® Guide to System and Network Security Practices (Addison-Wesley, 2001, ISBN: 020173723X) and the CERT security improvement module Securing Network Servers advises administrators to configure network servers securely through two essential practices: offering only essential services and applying patches on each server host. This excerpt is provided courtesy of the author.
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Vendors sell systems configured so their customers will be eager to buy. Often, systems are general-purpose; that is, fully featured with most of the software enabled for ease of use. They are meant to satisfy everyone's needs and, perhaps, some they didn't realize they had. Such systems frequently contain:
services that are unneeded and often insecurely configured
little or no protection against intruders accessing data objects such as files and directories
ease-of-use features often provided at the expense of security
vulnerabilities that intruders can use to break into systems
System and network administrators are responsible for identifying the tasks that will be performed by any network server and determining the necessary (minimum essential) functions to meet the organization's goals—eliminating those that are unnecessary. In addition, an administrator needs to ensure that vulnerabilities that place critical servers at risk are addressed.
Stick to Essentials on the Server Host Machine
Ideally, each network service should be on a dedicated, single-purpose host. Many servers are configured by default to provide a wider set of services and applications than required to provide a particular network service, so an administrator will likely need to configure the server to eliminate or disable these.
Why This Is important
Offering only the essential network services on a server can enhance network security in several ways:
Other services cannot be used to attack the server, and impair or remove desired network services. Each additional service increases the risk of compromise for all services on that host or for any server trusting that host.
Different services may be administered by different individuals. Isolating services so each host and service has a single administrator minimizes the possibility of conflicts between the administrators (also known as separation of duties—a principle that should underlie an organization's security policies).
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 needless vulnerabilities or service restrictions.
Reducing services also reduces the number of logs and log entries, so analyzing logs to detect unexpected behavior becomes easier.
How To Do It
We recommend using the configuration principle "deny first; then allow." That is, turn off as many services and applications as possible and then selectively turn on only those that are essential. We also suggest installing the most minimal operating system configuration image that meets business requirements, but realize that not all operating systems support doing so.
This practice is most effective if it is performed as part of the initial operating system installation and configuration versus retrofitting an operational server executing in a production environment.
Determine the Functions the Server Will Support
Services enabled on a selected server depend on the functions the server needs to provide. Functions could support the selected network service, other services hosted on this server, or development and maintenance of the operating system and applications. Providing multiple services or combining the role of workstation and server on the same computer results in a less-secure configuration and makes security maintenance more difficult.
Determine the server configuration for the following:
File systems (for example, whether any file services will be used by this host).
System maintenance (for example, whether maintenance will be done via the console, remotely, or both).
Server maintenance. In most cases, all server software maintenance should be done on another host, and the updated files downloaded to this host. Limit the software on the server to what is required to administer the server. Carefully consider the need for compilers, editors, interpreters, shells, scripts, or other programming tools based on the server's use (providing specific services or applications, being used for internal development, and so on). (If programming tools are required, locate them in separate, protected directories. Locate public scripts in a single protected "execute only" directory.)
Network configuration. Consider including a list of trusted hosts and other computers, which will be in communication with the server. This helps protect against DNS spoofing. Be aware that this approach will take more time; information is replicated, and any updates must be performed on each host to keep this information consistent.
Protocols offered (for example, IP [Internet Protocol], IPX [Internetwork Packet Exchange], and AppleTalk).
An administrator may need to configure the server differently, according to the other features provided by the host operating system or environment. For example, certain operating systems provide extensive access control mechanisms that minimize or prevent the possibility of unauthorized access at relatively fine levels of granularity.
Where possible, implement limitations and constraints to ensure a more secure configuration:
Limit the hosts that can access the service. Consider the use of tools such as TCP (Transmission Control Protocol) wrapper.
Limit the users who can access the service.
Configure the service to allow only authenticated connections. The authentication should not rely solely on network data such as IP addresses and DNS names, which can easily be falsified (that is, spoofed), regardless of whether or not the host is trusted.
Limit the degree of access (especially in cases where it would permit a user to change the configuration of network services.)
If applicable, limit the range of facilities and functions offered by the service to those deemed necessary (for example, if files will be shared via FTP, permit only file downloads, and restrict file uploads).
Isolate the service's files (configuration, data files, executable images, and so on) from those of other services and the rest of the system.
Consider using a host-based firewall to eliminate connections to services that have been disabled and subsequently removed. This is another way to ensure that the service remains disabled, even if the supporting files are reinstalled and the service restarted.
Select the More Secure Alternative
On UNIX systems, for example, connectivity for remote system maintenance could be supported using remote shell (RSH) or secure shell (SSH). We recommend disabling all r-services (rpc, rdate, rdist, remsch, rlogin, rpcinfo, rsh, rksh, rup, ruptime, rusers, rwho) due to their inherent vulnerabilities (including use of IP addresses for authentication). Select SSH, which is the more secure alternative.
Use wrapper tools such as TCP wrapper for controlling access to selected services by IP address and to log all connection attempts to those services (such as telnet). Be aware that TCP wrapper does not protect against IP spoofing; however, such connection attempts and successful connections would be logged.
Install Only the Minimal Set of Services and Applications
Either do not install unnecessary services, or turn the services off and remove the corresponding files (source, binary, executable, configuration, and data files) from the server. Be careful with network service programs. Some provide multiple services, and an administrator will have to reconfigure them or disable unnecessary services. For example, Web server software often includes FTP along with HTTP. Disable FTP if file transfers to and from the public Web site are not required. If FTP service is required, severely restrict access to it, and carefully consider how anonymous FTP will be used.
When considering services to enable or disable, administrators typically think of those services that run as processes. For example, these include telnet, FTP, DNS, electronic mail, and Web services. However, most of today's systems also provide services directly from the kernel. An example of such a service is a netmask request. This request is typically broadcast onto the local area network, and all systems seeing this request answer it unless otherwise instructed. The kernel of those answering systems is providing the netmask service, more than likely unbeknownst to the administrator of that server.
Determine what services the kernel provides, and what controls the operating system provides to configure these services. These services are frequently not documented, and are often not controllable. There is no tool that we know of to test for the presence of such services in a manner similar to the way the strobe tool for UNIX systems tests for services running as processes. The best source of information is the system vendor.
Eliminate any Unnecessary Open Network Ports
Eliminate unnecessary TCP and UDP network ports on which a server process may listen for incoming client connections. This reduces the risk of attack using these ports. Open network ports can be identified using the netstat command on UNIX and Windows systems.
Create and Record Cryptographic Checksums
After making all configuration choices, create and record cryptographic checksums or other integrity-checking baseline information for critical system software and its configuration.
Refer to The CERT® Guide to System and Network Security Practices for additional information on the role of checking the integrity of baseline information to support intrusion detection.