S 4.105 Initial measures after a Unix standard installation

Initiation responsibility: Head of IT Section, IT Security Management

Implementation responsibility: Administrator

Most Unix systems do not satisfy the system security requirements after a standard installation. Often too many sensitive services and configurations are activated by the vendors or else these are provided with access rights which are not sufficiently restrictive.

This section is intended to show by way of example how to make the system secure following a standard installation.

• Prior to installation the administrator should be given appropriate training, especially as regards the security aspects. This should include informing him of all the potential security weaknesses of the IT system (see also S 2.35 Obtaining information on security weaknesses of the system). Subscribing to appropriate mailing lists should also be covered.

• After the installation has been completed, the System Administrator's account should be assigned a good password (see S 2.11 Provisions governing the use of passwords).

• A review should be made of which services are running on the IT system. It is possible to check this e.g. by entering the command netstat -a | grep listen. Services which are not needed should be disabled or removed (see S 5.72 Deactivation of unnecessary network services).

• If the system does not function as a mail server, the mail daemon should be deactivated as a network service. If mail is to be delivered locally on the system, sendmail can be started with the option -q15 or as a cron process:

1 * * * * /usr/sbin/sendmail -q 2>&1 >/dev/null

The mail queue is emptied at regular intervals and the mail is delivered locally.

• The latest version of the vendor's sendmail should be installed (see also S 4.107 Use of vendor resources and S 5.19 Use of the sendmail security mechanisms). Alternatively, public domain mail programs such as a qmail can be used. The version number of the installed version of sendmail can be identified with the command telnet localhost 25.

• After the standard installation, the security patches provided by the vendor should be installed (see also S 4.107 Use of vendor resources). It is extremely important then to check that no unnecessary services have been activated as a result of the patch installation.

• The file systems should be imported or exported only to the necessary extent. Care must be taken to ensure that file systems are not exported in such a way that anyone can write to them.

• If there is no alternative to using NIS, then NIS+ should be used as additional security mechanisms are incorporated into this.

• If it is necessary that tftp is available, then the system should be started with the option s in order to prevent every file in the system being copyable (see also S 5.21 Secure use of telnet, ftp, tftp and rexec and S 5.72 Deactivation of unnecessary network services).

• The inetd logging function should be enabled with t so as to ensure that every attempt to establish a connection is logged (cf. S 5.72 Deactivation of unnecessary network services). It is helpful to install the public domain tool xinetd or TCP Wrapper. With these tools it is possible amongst other things to log all connection attempts promptly, and before the daemon addressed has been started via inetd.

• Log files should be examined on a daily or weekly basis. Analysis programs such as swatch, logdaemon or logsurfer should be installed in order to have the data processed and interpreted semi-automatically (cf. S 2.64 Checking the log files).

• Security checks using USEIT, COPS, Tripwire or Tiger should be carried out at regular intervals.

• It is important that rshd, rlogind, rexecd are deactivated as well as all the other unnecessary services (cf. S 5.72 Deactivation of unnecessary network services). To convert RPC program numbers to port addresses, most vendors supply the program rpcbind. If the daemon portmapper is available for the existing platform, then it should be used either as an addition or as a replacement.

All clients which use these services should be non-executable for normal users. Any other authentication procedures which are based on host names should be completely removed.

• Telnet should be replaced by ssh. With ssh it is possible to have a strongly encrypted and authenticated interactive connection between two systems. ssh should be viewed as a substitute for telnet, rsh, rlogin and rcp. It also enables X-Windows traffic to be passed securely (see also S 5.64 Secure shell).

• Xauth is to preferable to xhost - "xhost +" should never be used (see also S 4.9 Use of the security mechanisms of X-Windows).

• All entries which are not required should be removed from the configuration file /etc/inetd.conf (see S 5.72 Deactivation of unnecessary network services).

• The configuration file /etc/syslog.conf must be modified so as to activate the log functions (see S 4.106 Activation of system logging).

• A list of all world-writable files and directories can be created with 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 with the installation status.

• Either Tripwire or USEIT should be installed before the system goes live in order to obtain a checksum summary of the installed system on commencing actual operation. The summary created should be stored on a write protected data medium.

• To ensure that malicious generation of log data cannot bring the Unix system to a halt, /var should be a large partition.

All changes carried out should be carefully documented and be agreed among all the system administrators. This documentation can be in paper form or in a file that is maintained on the system concerned. However, it must be possible for the documentation to be inspected and updated at any time (see also S 2.34 Documentation on changes made to an existing IT system).

Additional controls:

• What services are enabled on the IT system?

• Have all the available security patches been installed in the correct manner?

• Are all changes documented promptly and agreed among all the system administrators?

• Are all changes made to the operating system configuration documented and easy to follow after a new installation?