S 4.105 Initial measures after a Unix standard installation

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

For most Unix systems, a default installation does not meet the requirements for secure operation of the system. Here, the manufacturers often enable too many security-critical services and configurations and/or grant them rights that are too wide-ranging.

The following overview is intended to generically demonstrate how a default installation can be protected:

• The administrators must be trained accordingly before performing the installation, especially in terms of security aspects. During training, the administrators should obtain information on all potential security gaps of the operating system used and the applications installed on it (see also S 2.35 Obtaining information on security weaknesses of the system). For this, it may also make sense to subscribe to the corresponding mailing lists.
• Upon completion of the installation, the administrator identifiers should be protected with strong passwords (see S 2.11 Provisions governing the use of passwords) or two-factor authentication should be integrated.
• It should be examined which services are executed on the IT system. This can be checked using the netstat -a | grep LISTS command, for example. Unneeded services should be disabled or removed (see S 5.72 Deactivation of unnecessary network services).
• If the system is not operated as an email server, the mail daemon should be disabled as a network service. If email will be delivered locally on the system, then sendmail can be started with the option -q15 or as a cron process:
  1****/usr/sbin/sentmail_-q 2>&1 >/dev/null
  
  
  The mail queue is emptied at regular intervals and email is delivered locally.
• The most recent version of sendmail should be installed (see also S 4.107 Use of vendor resources and S 5.19 Use of the sendmail security mechanisms). Mail programs in the public domain such as qmail may also be used as an alternative. The sendmail version currently running can be queried using the command telnet localhost 25.
• Upon completion of default installation, all security patches available from the manufacturer should be installed (see also S 4.107 Use of vendor resources). Thereafter, it is absolutely necessary to check if any unneeded services were enabled during the installation of the patch.
• The file systems should be imported and exported as restrictively as possible. It must be ensured that file systems are not exported so that all users have write access to them.
• If there are no alternatives to using NIS, NIS+ should be used, since it provides advanced security mechanisms.
• If tftp must be made available, it should be started with the -s option so that it is not possible to copy every file of the system (see also S 5.21 Secure use of the telnet, ftp, tftp, and rexec and S 5.72 Deactivation of unnecessary network services).
• The logging function of inetd should be enabled with the -t option so that every attempt to establish a connection is logged (see S 5.72 Deactivation of unnecessary network services). It also helps to install the public domain tool xinetd or TCP Wrapper. With these tools, it is possible, amongst other things, to log all attempts to establish a connection quickly before the daemon requested is started via inetd.
• Log files should be examined daily and/or weekly. Analysis programs such as swatch, logdaemon, or logsurfer should be installed to analyse the log files semi-automatically (see S 2.64 Checking the log files).
• Security checks should be performed regularly using programs for integrity checking or audit tools, for example.
  In addition to all other unneeded services, rshd, rlogind, and rexecd absolutely must be disabled (see S 5.72 Deactivation of unnecessary network services). Most manufacturers supply the rpcbind program with their software to convert RPC program numbers to port addresses. The portmapper daemon should be used as a supplement or a replacement if it is available for the platform in use.
  
  Normal users should not be able to execute any clients using these services. Other authentication procedures based on the host name should be completely removed.
• Telnet should be replaced by ssh. With ssh, it is possible to establish an authenticated interactive connection between two systems that uses strong encryption. The ssh shell is intended to be a replacement for telnet, rsh, rlogin, and rcp. It also enables X Windows data to be transmitted securely (see also S 5.64 Secure Shell).
• Xauth should be preferred over xhost - and "xhost +" should never be used (see also S 4.9 Use of the security mechanisms of X Windows).
• All unneeded entries in the configuration file /etc/inetd.conf should be deleted (see S 5.72 Deactivation of unnecessary network services).
• The configuration file /etc/syslog.conf must be modified in order to enable the logging functions (see S 4.106 Activation of system logging).
• A list of all globally writeable files and directories can be generated using the following commands:
  • - find / -type f -perm -22 -exec ls -l {} \;
    - find / -type d -perm -22 -exec ls -ld {} \;
• The results should be compared regularly to the list generated directly after installation.
• Before commissioning, a program for integrity checking should be installed. Before starting live operation, a checksum overview of the critical system areas of the installed system should be drawn up. The overview generated should be stored on a write-protected data medium.
• The /var directory should be located on a large partition so that a deliberate attempt to generate log data will not bring the Unix system to a standstill.

All changes made should be documented carefully, and a change should only be made after all system administrators agree to the change. This documentation can be in paper form or stored in a file on the corresponding system. It should be possible, though, to read and update the documentation at any time (see also S 2.34 Documentation on changes made to an existing IT system).

Review questions:

• Are checksums of critical system areas generated and stored before starting live operation in order to secure the integrity of the IT system?
• Are logging functions enabled to an appropriate extent?
• Are existing options and system settings used to increase the level of security?
• Has it been ensured that file systems can only be imported and/or exported restrictively (e.g. exported in a way that they cannot be written by all users)?
• Are verifications being performed that only the required services remain enabled upon changes (e.g. installation of updates and patches)?
• Have all available security patches been installed before commissioning?
• Have the services of the IT system been reduced to the required extent?