8.3 Before opening the doors: hardening

A process sometimes used in the UNIX and Linux community is hardening. A "hardened" system is presumed to be impervious to any currently known attacks, exposures, or vulnerabilities. Every system, Linux or otherwise, should be hardened before being placed on any active LAN. Hardening is not a one-time task. Depending on the level of acceptable risk, triggers must be identified to ensure that the system configuration is revisited as needed. The security policy should contain criteria that trigger a reassessment of the configuration. For example, if a new Internet worm is identified and is known to attack the e-mail server, the security policy must be checked, and systems must be updated and rehardened.

Develop a patch policy

System hardening includes making sure that the latest software patches are applied to the system, especially if they are security-related or apply to any of the security or system management products that are critical to the solution. Once all the patches are installed, the mechanisms into and out of the solution must be evaluated with regards to the solution. This makes it necessary to have a patch policy within the security policy.

Get rid of the extra fat

Only those mechanisms required by the solution should remain active. For example, if the work that needs to be done is Web serving and the system will be managed remotely through SSH, it would be prudent to turn off the telnet and mail daemons (among others), because they are not part of the solution and could provide intruders unnecessary routes of attack.

Most standard Linux distributions include features and services to enable a wide scope of functionality and value usually far more then you need and want on a typical Linux server deployment. Many of the latest Linux distribution releases provide warnings if you attempt to install a service that poses a security risk, such as telnet. We highly recommend that you pay attention to these warnings. Validate that the services running are critical for the function of the Linux server you are configuring.

Related information is in the SANS/FBI list (http://www.sans.org/top20/), including one of the top general vulnerabilities, "Default Install of Operating System and Applications."

Remove unused accounts

Removing insecure user accounts is also part of the hardening process. Some system images are provided with well-known accounts and passwords. Some application install processes leave behind accounts that are well-known and vulnerable. Unnecessary user accounts should be removed, and default or weak passwords should be reset to strong passwords. User authority to access system or application code should be limited as well.

For z/VM, consider including these issues in your security policy:

• After installing a new z/VM system, remember to change the default logon and minidisk passwords for all users in the system directory.

• Do not give virtual machines more authority than they require.

8.3.1 Managing hardening

The hardening of a system must be linked with the management of that system. Every time the kernel is patched or upgraded, or a new application is installed or modified, the state of the system with regard to hardening must be reviewed. This integral step can be performed by any number of scripts available in the Open Source community or from service organizations skilled in this area. For example, scripts are available from Bastille at http://www.bastille-linux.org/. These scripts are yet another example of how Open Source code helps Linux be more secure.

In some scenarios, once an image is hardened it can be used as the starting point for cloning new images as needed. This cloning capability is easily implemented and its value is realized when z/VM manages the images.

The early broad-brush approach to enabling many popular network services, such as telnet or FTP, has left many systems vulnerable. The traditional zSeries customer would rather enable function as needed, and the Linux trend is shifting in this direction.

8.3.2 Tools for managing security on z/VM: DirMaint and RACF

Software products exist that can be used to further enhance the integrity and security of a z/VM system. Two of those products from IBM are optional features of z/VM Version 4 called IBM Directory Maintenance for z/VM (DirMaint) and IBM Resource Access Control Facility for z/VM (RACF).

DirMaint provides a safe, efficient, and user-friendly way to maintain the z/VM system directory. Through its command line or full-screen interface, you can quickly and easily add, modify, or delete users from the system directory. See 23.3.1, "DirMaint" for more details. In any z/VM installation where large numbers of virtual servers are being deployed, DirMaint is useful.

RACF is an external security manager. It provides comprehensive security capabilities that extend the standard security implemented by the base z/VM product. RACF controls user access to the VM system, checks authorization for use of both system and virtual machine resources, and audits the use of those resources. Like DirMaint, RACF is packaged as a priced feature of z/VM Version 4 and is pre-installed on the system installation media. See 23.3.2, "RACF" for more details.