S 4.237 Secure basic configuration of IT systems

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

The basic settings implemented by the manufacturer or distributor of an operating system are usually not optimised for security, but for easy installation and start-up, as well as often for every user being able to access the highest possible number of features of the operating system as easily as possible. When using IT systems (regardless of whether as client or server) in government agencies or companies, this is often undesirable.

For this reason, the first step when specifying the basic configuration must be to examine the basic settings and if necessary adapt these to reflect the corresponding specifications in the security policy. The basic configuration naturally depends quite a lot on the operating system used. Therefore, the operating system-specific modules contain corresponding, detailed safeguards.

The goals of secure basic configuration should include the following

• the system must be protected against "simple" attacks from the network,
• no normal user must gain access to sensitive data not designed for his/her eyes by pure curiousness or even by accident,
• no normal user must be able to cause severe damage to the system or data of other users when working normally with the system due to pure operating errors or recklessness ("Let's see what happens if I delete this file?"), and
• the effects of minor errors must be limited as far as possible even for the work of system administrators.

The settings that should be checked and adapted within the framework of the basic configuration particularly refer to the following areas:

• Settings for system administrators
  
  The identifiers system administrators use for working should be protected in particular. For example, this refers to the settings for the user environment, such as
• Search paths for programs and files,
• environmental variables, and
• configuration of certain programs.
  
  These settings should be checked and changed accordingly, if necessary. Furthermore, the settings for the user directories of system administrators should be selected in such a way that normal users cannot access these directories.
• Settings for the system directories and files
  
  Within the framework of the basic configuration, it must be checked whether the authorisations for system directories and files correspond to the specifications of the security policy. On a server, relatively restrictive settings should be selected for the authorisations of the system directories and files.
• Settings for user accounts
  
  Within the framework of the basic configuration, it should be checked which default settings are applicable to user accounts. The settings must possibly be adapted in accordance with the security policy. This mainly refers to the same parameters as for system administrator accounts, but different settings may make sense for normal users.
• Cleaning up the user database
  
  Often, a larger number of user accounts is created for the default installation of an operating system than required for operation. Therefore, it should be checked within the framework of the basic configuration which user accounts are actually needed. User accounts not required should either be deleted or at least disabled in such a way that the corresponding account cannot be used for logging into the system.
• Checking the services
  
  The default installation of an operating system often comprises a host of programs and services normally not required that may constitute a source of security gaps for this very reason. This applies in particular to network services. Upon installation, it should therefore be checked which services are installed and which are enabled on the system. Services not required should be disabled or uninstalled entirely.
  
  Checking for running services can be performed locally using the features of the installed operating system on the one hand, and for network services from the outside using a port scan from another system on the other hand. By combining both methods, it can largely be ruled out that the system offers even more undesired network services.
• Settings for accessing the network
  
  Within the framework of the basic configuration, the settings for accessing the network, as well as important external services should also be made and documented. For example, this refers to (unless already performed during installation):
• Assignment of the IP address and configuration of the basic network parameters or configuration of the access to a server automatically distributing network settings, for example using a DHCP (Dynamic Host Configuration Protocol). However, using DHCP is not recommended for servers.
• Configuration of the access to a DNS server and possibly other name services;
• Configuration of the access to shared file systems, databases, or other external services.
• Additional protection through a local packet filter
  
  Servers and clients with high protection requirements should be protected with a local packet filter or a personal firewall in addition to the protection provided by the organisation-wide security gateways or packet filters segmenting the internal network. Corresponding functionalities are provided by virtually all state-of-the-art operating systems.
  
  Within the framework of the basic configuration, corresponding protection should be implemented by means of a local packet filter at least for servers with high protection requirements. Protection with the help of a local packet filter is also recommended for servers with normal protection requirements. If required, a "more liberal" configuration may be selected in this case.
  
  For clients, using a local packet filter or a personal firewall is recommended if these are characterised by high or very high protection requirements regarding confidentiality or integrity.
  
  More detailed information regarding the configuration of a local packet filter can be found in S 4.238 Use of local packet filters and regarding a personal firewall in S 5.91 Use of personal firewalls for clients .
• Disabling call home functions
  
  Some operating systems and applications send information, for example regarding occurred errors or the system configuration, directly to the manufacturer so that the manufacturer can adapt the product to the needs of the users in the future. For this, a data connection is established to the servers of the manufacturer using data networks such as the internet. Such a form of data transmission may be critical, first and foremost if the users are not informed about the frequency and the contents of the data transmitted.
  
  In general, this often undesired exchange of information should be prevented. Information as to whether and how information is to be transmitted can normally be found in the license agreements of the used software.
  
  Many applications provide for the option of disabling this call home function. This function should only be enabled in justified exceptional cases. Upon updates, it should be checked whether the call home function remains disabled.
  
  The connection establishment with the manufacturer may also be prevented by local packet filters or the central security gateway (firewall). For example, the data connections could be rejected based on the destination addresses or the port numbers. In this, it must be observed that taking into consideration all applications is complex and automatic update functions often are not available any more, if required.
• Deactivation of any unneeded interfaces
  
  Within the framework of the basic configuration, all existing or possible retrofit interfaces are normally enabled. Often, not all of these interfaces are required, which is why those not needed should be removed or disabled. Some of these interfaces may also entail potential security problems that must be counteracted with the help of appropriate organisational or technical security safeguards. Interfaces, the use of which should be controlled, include Bluetooth, WLAN, Firewire, eSATA (external SATA hard disk connection), and IrDA (Infrared Data Association), for example. The things to be taken into consideration in so doing can be found in the corresponding safeguards.
• Directory-based execution control
  
  Regarding current operating systems, directory- or partition-based execution control is possible. Here, the execution rights for all files in a directory and all subdirectories are prevented. For example, this may be achieved with the help of corresponding group policies with "software restriction policies" on Windows-based operating systems. On Linux systems, the hard disk can be partitioned expediently and integrated with appropriate mount options "ro" (read only) and "noexec" (no execute). Furthermore, there are tools defining file-related authorisations in the operating system for high protection requirements.
  
  The directory- or partition-based execution control ensures the following, if configured appropriately:
• Users are not allowed to start any programs from directories they have write access to;
• Users are not allowed to write to directories they are allowed to start applications from.
  
  This makes it more difficult for the users to execute a program file they downloaded from the internet or copied from a USB stick.
• Monitoring
  
  In order to be able to react to critical system events, these may be monitored by the monitoring feature. For this, status information is usually retrieved from a central IT system the events are evaluated on. The interface required in order to retrieve the system events from the IT system may also often be used to change system settings of the operating system, however, e.g. via SNMP (Simple Network Management Protocol). If such a modification is not desired, these features should be disabled.
• Protection against buffer overflows
  
  In order to protect operating system and application against possible buffer overflows, the corresponding storage protection mechanisms should be enabled, if these are supported by the used hardware (CPU) and the operating system. For example, Executable Space Protection (ESP) can be used to prevent programs from being executed from inadmissible areas of the cache.
• Creation of an integrity database
  
  Upon completion of the basic configuration, it is recommended to create an integrity database with the help of a corresponding tool. For some operating systems, corresponding programs already are part of the scope of a default installation. The integrity database should not be stored to the system itself, but to a write-protected data medium (for example CD-R) or another, particularly protected system. If it is suspected that the system has been compromised, the generated checksums can be used in order to identify files that were modified by an attacker. During the regular checks of the system's integrity (see also S 4.93 Regular integrity checking), this database serves as a reference for a defined, secure condition of the system.

The settings checked within the framework of the basic configuration process should be documented, as well as whether they were changed, and if so, how they were changed. The documentation must be drawn up in such a way that someone other than the actual administrator, who does not have any previous knowledge of the system, will be able to understand what has been done based on the documentation. Ideally, it should be possible to restore the system with the help of the system documentation only.

Review questions:

• Is a secure basic configuration of all used IT systems performed in accordance with the specifications of the security policy?
• Have unneeded user accounts, services, and interfaces been disabled or removed?