We've started maintaining a few FreeBSD systems, so I wrote up a document on keeping them up-to-date with kernel, system and package updates using the ports system. It's a fairly generic document, it assumes that some packages have already been installed, and is aimed at an audience that already has some administrative experience. If it's helpful, feel free to comment.
comments powered by Disqus
====================== FreeBSD SECURITY GUIDE ====================== INTRODUCTION This guide is intended as a supplement to the FreeBSD handbook. It contains an outline of useful security procedures from the handbook as well as the operation of several applications that make it easier to keep your FreeBSD system up-to-date with the latest software versions and security updates. These instructions are written for the FreeBSD 5 branch. If you're using a different branch, these instructions will be somewhat different. Please refer to your local copy of the handbook. The complete copy of the handbook is available at: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ or locally installed on FreeBSD systems in: /usr/share/doc/en/books/handbook FINDING OUT ABOUT UPDATES There are three main parts of FreeBSD that can require security updates: the kernel, the base system, and individual ports in the ports collection. Announcements for kernel and base system updates are usually the most severe and will require a system reboot. For kernel and base system updates, the FreeBSD organization sends out security announcements. They do not send out announcements for most port updates, however there are pieces of software, such as portmanager, which makes checking for port updates very easy. Checking for port updates will be covered in the "Keeping Ports Up-To-Date" section of this document. If you use an RSS reader, or use an RSS aggregator service like bloglines.com, you can subscribe to the security announcement RSS feed at: http://www.freebsd.org/security/advisories.rdf Another easy way to hear about the latest updates and security announcements is through the FreeBSD-announce mailing list. It is a low volume list consisting mostly of security announcements and version release announcements. It also occasionally announces other "significant" FreeBSD events, such as conventions, calls for papers, changes in the organization, etc. To subscribe visit: http://lists.freebsd.org/mailman/listinfo/freebsd-announce Bugtraq also covers FreeBSD security announcements. It is a high volume mailing list, but you can browse through the archives at: http://www.securityfocus.com/archive/1 FreeBSD.org also maintains an archive of security announcements at: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/ Announcements are named like this: FreeBSD-SA-05:01.telnet.asc. The 05 refers to the year, the 01 refers to the announcement number within the year, and the text immediately following indicates which subsystem the vulnerability affects. KEEPING YOUR SOURCE UP-TO-DATE WITH CVSUP cvsup is a great utility for keeping your sources up-to-date. If you have not already configured cvsup, please see the instructions at: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html Before performing security updates, you may want to make sure that the source is up to date. For recent kernel and system updates, this is especially important, because the patch usually isn't applied to the source until the announcement is made. To make sure that your source is up-to-date, run: cvsup -L0 /usr/local/etc/cvsup/cvsupfile Your cvsup configuration file may be located in a different location. Please use the correct cvsup configuration file location in the line above. SECURITY UPDATES REQUIRING A KERNEL BUILD There are two main ways to rebuild a kernel on FreeBSD systems. Due to its improved ease of use, this document will only be covering the "new" way. For more information on the "traditional" way, please refer to the handbook, section "8.3 Building and Installing a Custom Kernel" (kernelconfig-building.html). If you're doing an update that also requires rebuilding the base system (i.e. applying several updates at once), you can skip this separate build process; rebuilding the kernel is a required step in rebuilding the base system. In this case, skip to the "Base System Updates Requiring a Buildworld" section below. The first step to rebuilding your kernel is to update your system source. If you have not already done so since the announcement came out, please update your source with the steps in the "Keeping Your Source Up-To-Date With Cvsup" section above. The next step is to determine the name of your kernel configuration. Kernel configuration files for iX86 base processors should reside in /usr/src/sys/i386/conf/. Knowing the name of the kernel configuration file you are using is important for the following steps. If you don't know the name of your custom kernel, the output of uname -a should help identify which file to use. For example, the following 'uname -a' output: FreeBSD foo.example.com 5.3-RELEASE-p6 FreeBSD 5.3-RELEASE-p6 #0: Tue Mar 29 11:27:21 MST 2005 firstname.lastname@example.org:/usr/obj/usr/src/sys/FOO i386 would indicate a kernel configuration name of FOO (from /usr/obj/usr/src/sys/FOO). We will be using this example custom kernel configuration file for the steps below. Please substitute it with your kernel configuration name on your system. If you're using the default GENERIC kernel, you can use GENERIC instead of FOO, or just leave off the KERNCONF option altogether. Once you have determined your kernel configuration name, change to the source directory and start the build. cd /usr/src make buildkernel KERNCONF=FOO make installkernel KERNCONF=FOO This is a great time to create a backup copy of your old kernel directory if you like to keep multiple versions of the kernel available for booting. cd /boot cp -R kernel.old kernel-`uname -r` Reboot into your new kernel: shutdown -r now Once you have verified that everything seems to be working correctly (top is a good way of ensuring that the kernel symbols match those in the base system), remove the temporary build files. rm -rf /usr/obj/* If all went well, you should be running the most recent kernel version. Congratulations! You can verify your kernel version by running uname -r BASE SYSTEM UPDATES REQUIRING A BUILDWORLD The first step to rebuilding your base system is to update your system source. If you have not already done so since the last announcement came out, please update your source with the steps in the "Keeping Your Source Up-To-Date With Cvsup" section above. Next, look over /usr/src/UPDATING for any notes or preinstallation steps that need to be completed before building or installing the new base system. It's a good idea to take a snapshot of the /etc directory in case something goes wrong with the mergemaster process described below. tar cjvf /root/snapshot-etc-`date '+%Y%m%d'`.tar.bz2 /etc This example stores the snapshot in the /root directory. You can store it wherever it makes sense to do so on your system. Ready to begin? Change to the source directory and start the build. cd /usr/src make buildworld If you have a custom kernel, you'll use the name in the following kernel steps. We'll be using the example FOO below. Please substitute it with the proper kernel configuration name on your system, or if you're using the GENERIC kernel, you can leave off the KERNCONF option. The name should match your configuration file in /usr/src/sys/i386/conf. If you're having problems determining your kernel configuration name, there is more information in the "Security Updates Requiring A Kernel Build" section above. make buildkernel KERNCONF=FOO make installkernel KERNCONF=FOO This is a great time to create a backup copy of your old kernel directory if you like to keep multiple versions of the kernel available for booting. cd /boot cp -R kernel.old kernel-`uname -r` cd /usr/src The following steps are best done in single user mode, but can be done in multiuser if necessary (or if console access is not available). If the system does not experience many interactive user logins, this is less of an issue. Be prepared to answer some questions during the mergemaster steps. You'll probably want to keep your /etc/passwd, /etc/master.passwd, and /etc/groups files at least, press (d) to delete the temporary copy that mergemaster wants to install and keep your existing version. Most of the other files can be installed from the temp directory (i). mergemaster -p make installworld mergemaster Reboot into the new base system and kernel. shutdown -r now Once you have verified that everything seems to be working correctly (top is a good way of ensuring that the kernel matches the symbols in the base system), remove the temporary build files. cd /usr/obj Some of the files will have special immutable file permissions set so that they can not be removed via the normal means. To remove the immutable flag and files in /usr/obj, run: chflags -R noschg /usr/obj/ rm -rf /usr/obj/* If all went well, you should be running the most recent base system and kernel version. Congratulations! KEEPING PORTS UP-TO-DATE While there are some binary packages available for FreeBSD, there hasn't been a large community effort to assemble large collections of up-to-date binary packages. The most common way to keep the software packages up-to-date is by building from source. However, FreeBSD has a number of utilities that make installing and upgrading packages from source, at least those in the ports collection, really easy. For more information on using binary packages, see the man pages for pkg_fetch and pkg_add and Section 4.4, "Using the Packages System", of the handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/packages-using.html Whenever you are about to update a set of ports, it's a good idea to have your source files completely up-to-date. If you have not done so recently, please update your source with the steps in the "Keeping Your Source Up-To-Date With Cvsup" section above. One of the easiest packages for keeping ports up to date is portmanager. Portmanager will update only the ports with updates available, or those that have been built with a package that is being updated (perl libraries, for example), and it handles the package dependencies properly. To see which installed ports have available updates, run portmanager -s | grep OLD Record any of the packages listed that are running as daemons on your system, because they will not automatically be restarted after the update is completed. Also, if portmanager itself needs an update, it may be necessary to perform the update in two different steps. It is a good idea to begin any long compile inside of a screen session, so that you can interrupt the login session without interrupting the build and save on network usage by switching to a different vty, or disconnecting the session. After starting screen, begin the update with portmanager -u If you're performing the update on a multiuser system, or one where you are worried about the performance impact, you can run the update at a lower priority with /usr/bin/nice -n20 portmanager -u It will likely take a while before portmanager finishes and reports if it completed successfully, or if it needs to run again. As part of its build process, portmanager creates binary packages and stores them in /usr/ports/packages/All/ If you are updating multiple systems with a similar configuration you can copy the binary package among your systems and use pkg_deinstall and pkg_add to update the new packages. On rare occasions, a package has problems building from source and will error out part of the way through a build. Portmanager will stop, and won't upgrade any other packages if this happens. This would be a show-stopper, but there are other utilities to try. First, gather the name of the package that's causing the problem. Portmanager should have reported which package failed. Gather the package name (we'll be using fortune-mod-bofh as an example), and use portupgrade to upgrade the failing package. portupgrade fortune-mod-bofh If the build is still dying because of an error, the next step is to use the ports collection to do a more manual install. First, you'll have to find the directory that contains the port. The following find command can be used to identify the source directory: find /usr/ports/ -type d -name fortune-mod-bofh In this case, the directory was /usr/ports/misc/fortune-mod-bofh. Change into the directory and run make make deinstall make reinstall make clean If it still fails, it will probably do so at the first `make` command. If so, stop there. Trouble-shooting a malfunctioning Makefile is beyond the scope of this document, and if this comes up, you will probably need to get help from a programmer familiar with the Make process. COMMAND SUMMARY This is a quick summary of commands used above. CVS source update: cvsup -L0 /usr/local/etc/cvsup/cvsupfile Kernel: cd /usr/src make buildkernel KERNCONF=FOO make installkernel KERNCONF=FOO cd /boot cp -R kernel.old kernel-`uname -r` shutdown -r now rm -rf /usr/obj/* Base System: tar cjvf /root/snapshot-etc-`date '+%Y%m%d'`.tar.bz2 /etc cd /usr/src make buildworld make buildkernel KERNCONF=FOO make installkernel KERNCONF=FOO cd /boot cp -R kernel.old kernel-`uname -r` cd /usr/src mergemaster -p make installworld mergemaster shutdown -r now chflags -R noschg /usr/obj/ rm -rf /usr/obj/* Ports: portmanager -s | grep OLD screen portmanager -u