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.

======================
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 root@foo.example.com:/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