Patching your systems is absolutely crucial in this day of complex software. Patching allows distribution vendors and open source contributors to correct deficiencies found in software or to update software with the latest features. In this chapter, we will discuss how to patch your software both with a graphical user interface and at the command line, the basics of creating a change management process, and monitoring your patch process.
Updating your software is a basic, yet important phase of your security program. A vast majority of successful attacks occur on systems that have not been properly patched or updated. The simple act of patching your systems can significantly increase your security posture or at a minimum prevent unskilled attackers or those looking to compromise easily attacked machines. The distributions used in this book let you update your software in a more convenient way than was the norm previously. Many distributions provide a means of updating software in a centralized, easy-to-use manner, including the two distributions of focus for this book, Red Hat Enterprise Linux Advanced Server 3 and SUSE SLES8.
SUSE provides Yet Another Setup Tool (YaST), which contains a module for updating software called YOU (YaST Online Update). This tool can be used both from the command line and from a graphical user interface. The graphical tool is extremely easy to use, but may not be an option for those who want to run updates from a cronjob, who only have shell access, or for those who do not have X installed. We will discuss both the graphical and nongraphical versions in this section.
To start online update in graphical mode, select Start System YaST2 If you are not logged in as root, you will be asked for your root password as shown in Figure 13-1.
To get to the online update module, select the Online Update icon as shown in Figure 13-2. After selecting Online Update, you will see the main YaST Online Update screen as shown in Figure 13-3.
On this screen, you have a few options to choose from. In the choice of update mode, you can choose Automatic Update, which downloads and installs all patches and installs them with no user intervention. The other option is to choose Manual Update, which allows you to view the updates you are installing to determine dependencies and relevance to your system. The next section of this screen allows you to choose your installation source, which by default is the SUSE servers. If you have another source for your updates, you can select it here. Later in this chapter we will discuss setting up a local patch server, where this section would come into use. For our example, we chose Manual Update, left the default installation source, and clicked Next , at which point you will see the screen shown here:
This information can be obtained using your SUSE registration web site. Go to https ://portal.SUSE.com/. You need to create a login name and password. Then you will be taken to the SUSE portal homepage. On the left side of the page, you will see a Manage Registrations link under the My SUSE link. Click that and then click on Activate Product, where you can enter your registration code. You then enter the user login and password you entered at the portal (don t use the registration code, as is implied , use your registration user ID). You will also want to unselect the Keep Registration Data checkbox. This is a security weakness, as your user ID and password will show up in plaintext the next time they come up (giving your login credentials to anyone with access to the machine). After entering your login data, you will see that the server is gathering information, as shown here, after which you will see the screen shown in Figure 13-4.
You can now select the packages you want to install after you view the description to determine if it will work in your environment. After selecting the updates you want to install, click Next and you will see a screen similar to that shown in Figure 13-5 showing the packages you selected are being retrieved (but not yet installed).
After the packages have been retrieved, the installation procedures begin as shown in Figure 13-6. During installation of some packages, you may receive instructions on procedures to follow after the patch is installed, as shown here. Make note of any instructions and follow the instructions after you have completed the total patch procedure.
When the installation has completed, you will see the Installation Successful window as shown here. Click OK to finish installing patches. After clicking OK you will see the installation wrap-up screen as shown in Figure 13-7.
When this is complete, you can click Finish to end the update. To be absolutely certain that all the patches have installed and that there are no new patches to install, run through the process one more time.
There will be instances when you cannot update a machine due to not having a GUI installed on the system or when you want to update automatically via a cronjob. To download patches from the first system listed in your /etc/suseservers file (YaST2 uses this file to indicate where to get the updates from) use the following command:
/sbin/yast2 online_update .auto.get
You can also specify patch groups as shown in Table 13-1.
Patch Groups | Description |
---|---|
Document | Information about servers or patches |
Optional | Minor patches |
Recommended | SUSE recommended patches |
Security | Security- related patches |
yast2 | YaST2-related patches |
If you want to download security patches for later installation, use the following command:
/sbin/yast2 online_update .auto.get security
To research the patch and what it does, you can go to /var/lib/YaST2/you/i386/update/SUSE-SLES/8/patches and open the files contained in this directory in your favorite text editor. Up to this point you have only downloaded the patches.
To install the patches, use the .auto.install option:
/sbin/yast2 online_update .auto.install
The preceding command installs all available patches. You can use the same options as .auto.update . Also note that you can use .auto.get alone to download all relevant patches and then use .auto.install to install only the security patches. The logfiles for these updates are located in /var/log/YaST2/ for later viewing. These commands can be added to a cronjob to be automated if appropriate with a crontab entry similar to this:
* 2 * * * /sbin/yast2 online_update .auto.get security * 3 * * * /sbin/yast2 online_update .auto.install security
Red Hat provides an easy-to-use update tool with its distribution, called up2date . With this tool you can automatically patch and install the latest software available. An additional added benefit of Red Hat s software management tools is the ability to manage many servers from the Red Hat network web site. This is one online update tool that is very robust, allowing management of many servers from one location.
The easiest way to start the Red Hat Update Agent is to double-click on the exclamation mark in the lower-right side of the screen, or you can open a console window and type up2date .
Click Forward, where you will see the terms of service that you must read and accept before continuing, as shown in Figure 13-8.
If you need to configure the RHN update tool for proxy use, you will see a screen for you to put in proxy information as shown in Figure 13-9.
After the proxy configuration screen, you will see a Configuration Complete window, at which point you can click Apply.
If your system has not been registered yet, you will receive the warning shown in Figure 13-10 (you may have to double-click the RHN Tool indicator or type up2date in a shell window).
At this point, you need to provide the root login, as patching and installing software using this tool requires root privileges.
Now you are taken to a configuration screen, where you may enter any special configuration options your organization requires (see Figure 13-11). The defaults should be fine in the majority of instances.
Red Hat provides a GPG key to validate that the files you download and install are truly coming from Red Hat and not another untrusted source. The screen you will be presented with to approve importing Red Hat s public key is shown here. Click Yes to import and continue.
Next you will see the Red Hat Update Agent welcome screen. You may have to double-click the icon in the bottom right of the screen (which could be either an exclamation point or a question mark) or type up2date to bring this screen up if it doesn t show by itself.
Select Forward to go the screen shown in Figure 13-12. If you have a previous account with Red Hat, you can use the http://rhn.red hat.com/ account information in the Use Existing Account segment. If you don t, fill in the information to create a new account.
The final step in the initial update configuration is to register your system with the Red Hat Network. Figure 13-13 shows an example of this screen. Note that you can exclude information if you are concerned with privacy. In the screen shown, no information about the hardware is sent except the Red Hat Linux version and the hostname (profile name).
To send the information to Red Hat, click Forward in the Send Profile Information to Red Hat Network screen.
At this point, your system is ready to collect specific information about the software installed (see Figure 13-14). This information allows Red Hat to customize the list of updates that are presented to the user for updating.
After the registration is complete, you can now begin updating your system. The screen shown in Figure 13-15 is the one you see in all future occurrences of double-clicking the RHN Update icon or when you type up2date on the command line. Click Forward.
You are presented with a listing of the channels your system is subscribed to as well as checkboxes to select which channels you are updating, as shown in Figure 13-16.
The next screen is a listing of the available packages you can update via the Red Hat Network. In Figure 13-17 you can see that there are many packages that need to be updated. In the Package Information window you can determine what the package is for, and the View Advisory button will provide further information on the update. Click Forward after you have determined the patches you want to apply to your system. The system will solve any interdependencies or conflicts.
Heads Up | In Linux, there are many packages that depend upon each other to work properly, and removing them can cause many problems, as discussed in Chapter 4. If any problems are discovered , a screen similar to Figure 13-18 will pop up. If no package issues are found, you will not see this screen. |
At this point, all packages that were selected will be retrieved from Red Hat (see Figure 13-19). This may take a significant amount of time depending on how many updates are being installed and the speed of your Internet connection.
After the packages have been retrieved, the installation process will begin, as shown in Figure 13-20.
After all packages have been successfully installed, you will be shown an overview of what changes occurred, as shown in Figure 13-21.
You will not always be able to use the graphical interface or you may want to automate the process of patching. To do this in Red Hat Linux, you can use up2date from the command line. One of the great benefits of this is you can update software, resolve dependencies, and install new software with a tool that is easy to use and administer. The more interesting options are listed in Table 13-2.
Option | Description |
---|---|
--configure | Use this option to configure the up2date agent. |
--d | Download packages only (for later installation). |
--dry-run | Show the packages available and dependencies. |
-f | Force package installation, overriding all previous instructions. |
-I | Install. |
-l | List packages updated or for download and/or installation. |
--nox | Do not try to display the GUI. |
--showall | Show all packages available from currently subscribed channels (including those |
-u | Update all currently installed packages. |
To have up2date update the system from the command line, type the following command ( --nox is not always required, but it is better to be safe and add it):
up2date -u --nox
The output is as follows :
[root@linux2 root]# up2date -u --nox Fetching package list for channel: rhel-i386-as-3... ######################################## Fetching Obsoletes list for channel: rhel-i386-as-3... Fetching rpm headers... ######################################## Name Version Rel ------------------------------------------------- mozilla 1.4.2 3.0.2 i386 mozilla-nspr 1.4.2 3.0.2 i386 Testing package set / solving RPM inter-dependencies... ######################################## mozilla-1.4.2-3.0.2.i386.rp ########################## Done. mozilla-nspr-1.4.2-3.0.2.i3 ########################## Done. mozilla-nss-1.4.2-3.0.2.i38 ########################## Done. Preparing ########################################### [100%] Installing... 1:mozilla-nspr ######################################### [100%] 2:mozilla-nss ######################################### [100%] 3:mozilla ######################################### [100%] The following packages were added to your selection to satisfy dependencies: Name Version Release -------------------------------------------------------------- mozilla-nss 1.4.2 3.0.2
This shows that mozilla was updated and some software that wasn t installed was installed to solve a dependency problem (last four lines). The information shown in the text output is similar to that shown in the graphical version, just in a more condensed, automated format.
If you only want to download patches or packages, but not install them, you can use --download . This allows you to determine what patches you want to apply in order to maintain maximum availability.
To have automatic updates run via a cronjob, you can put an entry in your crontab similar to
* 2 * * * /usr/sbin/up2date -u --nox
To view what changes were made to the system by up2date , you can view the logfile at /var/log/up2date, which provides any information you need.
Using the --download option allows you to test your patches individually instead of doing a group install. This facilitates testing and incremental patching over a period of time, preventing loss of availability due to software incompatibilities and dependency conflicts.
A central patch server allows you to consolidate all the patches for your systems onto one system that will directly connect to the external (vendor) patch server and allow the other client machines. By creating a central patch server, you can deploy security patches across your organization s systems in a fast, reliable manner, with minimal interaction with individual machines. Red Hat Enterprise Linux AS 3.0 and SLES8 provide commercial offerings that can provide a vendor supported means of patching your server. Red Hat Enterprise Linux AS 3.0 provides both RHN Satellite Server or RHN Proxy Server. The RHN Proxy Server collects all the configuration information from the managed machines and allows caching of updates to a local server (reducing bandwidth costs). The RHN Proxy Server model is recommended for small Red Hat server deployments. RHN Satellite Server retains all server information on the local network and allows for greater granularity in configuration options, and this model is preferred for larger or more security-minded organizations. More information from Red Hat on these two options is available at http://www.redhat.com/software/rhn/architecture/. SUSE provides a commercial central patch module for their products, although information on SUSE s web site is difficult to obtain. You will need to consult your salesperson for further information on the product and features. The desktop products provided by the distributions have easy central patch servers that can be modified to support server products. Since these alternative methods of patching are not necessarily supported, we won t go into great detail, but we can lead you in the right direction.
One nonsupported method is to create an NFS mount on a server that will download the patches and maintain them. Export the directory that holds the patches as read-only to the specific machines that are allowed to access the server. Note that you will have to enable the download and save patches on Red Hat and SUSE in the patch utilities provided by the distributions. You can then point your client machines to be patched to the NFS server and directory that holds the patches. Allowing NFS creates security issues of its own and is not the most desirable method of patching.
There are also a few packages available that allow you to patch systems with simple scripts. Here are a few of the programs that can assist in creating your central patch server:
http://susefaq. sourceforge .net/howto/you_local.html Discusses creating a central SUSE YOU server as well as patch CD-ROMs.
http://linux.duke.edu/projects/yum/ YellowDog Updater Modified, discusses how to create a Red Hat central patch server. Primarily geared toward Fedora and workstation-level machines.
http://current.tigris.org / Red Hat Network central patch management replacement.
Note that these are not supported and require some adjusting of the default configurations of the operating system, which could lead to problems or failed patch installations. Be sure to consult your vendor for more information on their central patch management offerings.
Before deploying your Linux servers, you must consider the patching requirements and costs associated with the commercial products, as patching has become a crucial requirement for all Linux deployments.