Good system administrators make clear distinctions between stable "production" systems and volatile "research and development" (r&d) systems. One big difference is that on production systems, you don't add or remove software arbitrarily. Therefore, you may not feel comfortable applying every update for every software package on your production system as soon as they're announced.
That's probably prudent in many cases, but let me offer a few guidelines:
• Apply any update addressing a "remote root" vulnerability that could lead to remote users gaining administrative access to the system.
• If the system supports interactive/shell use by more than a few users (e.g., via Telnet, ssh, etc.), then apply any update addressing an "escalation of local privileges" vulnerability that could allow an unprivileged user to increase their level of privilege. • If the system doesn't support interactive/shell use except by one or two administrators, then you can probably postpone updates that address "escalation of privilege" bugfixes. • A nonsecurity-related update may be safely skipped, unless, of course, that update is
intended to fix some source of system instability. (Attackers often intentionally induce instability in the execution of more complex attacks.)
In my experience, it's relatively rare for a Linux package update to affect system stability negatively. The only exception to this is kernel updates: new major versions are nearly always unstable until the fourth or fifth minor revision (e.g., avoid kernel Version X.Y.0: wait for Version X.Y.4 or X.Y.5).
3.1.2.2 Whither X-based updates?
In subsequent sections of this chapter, I'll describe methods of updating packages in Red Hat, SuSE, and Debian systems. Each of these distributions supports both automated and manual means of updating packages, ranging from simple commands such as rpm -Uvh ./mynewrpm-2.0.3.rpm (which works in all rpm-based distributions: Red Hat, SuSE, etc.) to sophisticated graphical tools such as yast2 (SuSE only).
Given that earlier in this chapter I recommended against installing the X Window System on your bastion hosts, it may seem contradictory for me to cover X-based update utilities. There are two good reasons to do so, however:
• For whatever reason, you may decide that you can't live without X on one or more of your bastion hosts.
• Just because you don't run X on a bastion host doesn't mean you can't run an X-based update tool on an internal host, from which you can upload the updated packages to your bastion hosts via a less glamorous tool such as scp (see Chapter 4).
3.1.2.3 How to be notified of and obtain security updates: Red Hat
If you run Red Hat 6.2 or later, the officially recommended method for obtaining and installing updates and bug/security fixes (errata in Red Hat's parlance) is to register with the Red Hat Network and then either schedule automatic updates on the Red Hat Network web site or perform them manually using the command up2date. While all official Red Hat packages may also be downloaded anonymously via FTP and HTTP, Red Hat Network registration is necessary to both schedule automatic notifications and downloads from Red Hat and use up2date.
At first glance, the security of this arrangement is problematic: Red Hat encourages you to remotely store a list with Red Hat of the names and versions of all your system's packages and hardware. This list is
transferred via HTTPS and can only be perused by you and the fine professionals at Red Hat. In my opinion, however, the truly security conscious should avoid providing essential system details to strangers.
There is a way around this. If you can live without automatically scheduled updates and customized update lists from Red Hat, you can still use up2date to generate system-specific update lists locally (rather than have them pushed to you by Red Hat). You can then download and install the relevant updates
automatically, having registered no more than your email address and system version/architecture with Red Hat Network.
First, to register with the Red Hat Network, execute the command rhn_register . (If you aren’t running X, then use the --noxflag, e.g., rhn_register --nox.) In rhn_register’s Step 2 screen (Step 1 is simply a license click-though dialogue), you’ll be prompted for a username, password, and email address: all three are required. You will then be prompted to provide as little or as much contact information as you care to disclose, but all of it is optional.
In Step 3 (system profile: hardware), you should enter a profile name, but I recommend you uncheck the box next to "Include information about hardware and network." Similarly, in the screen after that, I recommend you uncheck the box next to "Include RPM packages installed on this system in my System Profile." By deselecting these two options, you will prevent your system’s hardware, network, and software-package information from being sent to and stored at Red Hat.
Now, when you click the "Next" button to send your profile, nothing but your Red Hat Network username/password and your email address will be registered. You can now use up2date without worrying quite so much about who possesses intimate details about your system.
Note there’s one more useful Red Hat Network feature you’ll subsequently miss: automatic, customized security emails. Therefore, be sure to subscribe to the Redhat-Watch-list mailing list using the online form at https://listman.redhat.com. This way, you’ll receive emails concerning all Red Hat bug and security notices (i.e., for all software packages in all supported versions of Red Hat), but since only official Red Hat notices may be posted to the list, you needn’t worry about Red Hat swamping you with email. If you’re worried anyhow, a "daily digest" format is available (in which all the day’s postings are sent to you in a single message).
Once you’ve registered with the Red Hat Network via rhn_register (regardless of whether you opt to send hardware/package info), you can run up2date. First, you need to configure up2date, but this task has its own command, up2date-config(Figure 3-1). By default, both up2date and up2date- config use X-Windows; but like rhn_register, both support the --noxflag if you prefer to run them from a text console.
Figure 3-1. up2date-config
up2date-config is fairly self-explanatory, and you should need to run it only once (though you may run it at any time). A couple of settings, though, are worth noting. First is whether up2date should verify each package’s cryptographic signature with gpg. I highly recommend you use this feature (it’s selected by
default), as it reduces the odds that up2date will install any package that has been corrupted or "trojaned" by a clever web site hacker.
Also, if you’re downloading updates to a central host from which you plan to "push" (upload) them to other systems, you’ll definitely want to select the option "After installation, keep binary packages on disk" and define a "Package storage directory." You may or may not want to select "Do not install packages after retrieval." The equivalents of these settings in up2date’s ncurses mode (up2date-config --nox) are keepAfterInstall, storageDir, and retrieveOnly, respectively.
Truth be told, I’m leery of relying on automated update tools very much, even up2date (convenient though it is). Web and FTP sites are hacked all the time, and sooner or later a Linux distributor’s site will be compromised and important packages replaced with Trojaned versions.
Therefore, if you use up2date, it’s essential you use its gpg functionality as described earlier. One of the great strengths of the rpm package format is its support of embedded digital signatures, but these do you no good unless you verify them (or allow up2date to verify them for you).
The command to check an rpm package’s signature manually is rpm -- checksig /path/packagename.rpm. Note that both this command and up2date require you to have the package gnupg installed.
Now you can run up2date. up2date will use information stored locally by rhn_register to authenticate your machine to the Red Hat Network, after which it will download a list of (the names/versions of) updates released since the last time you ran up2date. If you specified any packages to skip in
up2date-config, up2date won’t bother checking for updates to those packages. Figure 3-2 shows a screen from a file server of mine on which I run custom kernels and therefore don’t care to download kernel- related rpms.
Figure 3-2. Red Hat’s up2date: skipping unwanted updates
After installing Red Hat, registering with the Red Hat Network, configuring up2date and running it for the first time to make your system completely current, you can take a brief break from updating. That break should last, however, no longer than it takes to receive a new security advisory email from Redhat-Watch that’s relevant to your system.