23.2 General security considerations

This section discusses what to consider before applying patches and other security considerations. For more information on patches and hardening than we can provide here, see http://www.ibm.com/servers/security/planner.

23.2.1 Linux patch policy considerations

A typical Linux security attack is based on vulnerabilities in commonly used Open Source software, such as BIND, Sendmail, NFS, and "r"-programs such as rexec, rsh, and rcp. One of the main advantages of Open Source software is the speed at which security vulnerabilities are identified and patched. Because of this, it is important to develop a strategy for upgrading critical server software components. This strategy should include the following processes:

• Subscribing to security-related mailing lists. This includes a vendor's security update mailing list (for example, Red Hat, SuSE, or TurboLinux), as well as security advisory mailing lists from your local incident response team. These mailing lists are typically low-volume and provide invaluable information for system and security administrators.

• Retrieving of the latest patch list from your vendor and retrieving of any recommended security patches not included with your system. Some Linux distributions provide tools (such as SuSE YaST and RedHat Up2Date) for automatically checking the packages on a local system with the latest recommended security patches. Some patches may re-enable default configurations, so it is important to go through this checklist after installing any new patches or packages. Patches for software applications not supplied by the operating system vendor should be obtained directly from the software vendor's Web site.

• Ensuring that software patches and packages are downloaded from a reliable source only (for example, directly from the vendor or a trusted mirror site). Patches are often provided with check sums or PGP signatures to ensure that the patch has not been tampered with once the fix is posted.

• Verifying the cryptographic digital signature of any signed downloaded files to ensure integrity. Never use a file whose signature does not match its contents. Pretty Good Privacy (PGP) (http://www.pgpi.org) and GNU Privacy Guard (GnuPG) (http://www.gnupg.org) can be used for encryption and authentication and are commonly used by many Open Source software developers to provide digital signatures. To learn how to use GnuPG to verify digital signatures, see: http://www.dewinter.com/gnupg_howto/english/.

• Verifying the md5 checksum, when possible, of any downloaded patches with a utility such as md5 or md5sum. Md5sum is a standard utility on all major distributions and is very straightforward to use (md5sum -c md5-file will check the integrity of the md5 file). For example, Red Hat includes an md5 file in the same directory as its distribution ISO images. The file contains md5 entries for each file in that directory, which can be used to verify authenticity. For example, ftp://ftp.redhat.com/pub/redhat/redhat-7.2-en/iso/i386/.

• Using the -K or -checksig options if you are using RPM as your package management system. These options to the rpm command verify the cryptographic signature of the package.

23.2.2 Security considerations at the device driver level

This section discusses security considerations when using network attachment cards.

In a typical low-end server farm environment, for example, each server has a network attachment card that ideally should be plugged into a router with firewall capabilities. This allows you to securely control traffic that flows through the cards to the servers, as shown in Figure 23-1.

Figure 23-1. Controlling traffic through a card

One of the cards in widespread use on zSeries is the Open Systems Adapter (OSA) card. The OSA card is an adapter for network attachment. The card has several ports that Linux guests can connect to.

Whereas you could connect each Linux guest on the mainframe to its own OSA card, the OSA cards are designed for sharing. Therefore, you can connect several Linux guests to one such card. Security has to be provided with firewall images that control the data flow between Linux guests and between the Linux guests and external network, as shown in Figure 23-2.

Figure 23-2. OSA cards connect Linux images to an external network