3.3. FreeBSD Hardening: Your First Steps

As you know by now, you can't just "turn on" security. System security is like a collection of switches and knobs that you must constantly adjust. Many of these controls were introduced in Chapter 2. Deciding which switches to flip and which knobs to turn will depend a great deal on your environment: security policies and procedures imposed upon you, your own security requirements, the nature of the data on the system, and the administrative overhead you are willing or required to tolerate. This section provides numerous suggestions to improve the security of your freshly installed FreeBSD system. Some steps are more important than others, and in a lot of cases, this too varies between environments.

3.3.1. Step 1: Configure sudo

We'll make this step brief since we cover sudo extensively in the next chapter. For now, all you need to do is ensure that the user account you created has fairly liberal rights when it comes to running privileged commands through sudo. In order to configure sudo to allow your account to execute any command as root, edit the sudoers(5) file by running visudo(8) without arguments while logged in as root. Append the following line to the file:

username  ALL = ALL 

Where of course username is the account you created for yourself during the install process. That's it! Save the file, log out, and log back in under your regular account. In order to run privileged commands from here on out, just prepend sudo to the command you'd ordinarily run as root. The first time you use sudo, it will tell you about the power you hold and ask for your (not root's!) password. Thereafter, it will periodically prompt for your password to make sure you are you.

3.3.2. Step 2: Turn Off Unnecessary Services

Your server is likely to provide one or two critical services to a local network or to visitors from the Internet. Other supporting services may also be running like sshd(8) for remote administration. All other services that listen on a network interface can be disabled. There is where knowing about preexisting vulnerabilities come in handy. With this in mind, it is a reasonable precautionary step to disable these services also.

If you've just installed FreeBSD 5.x, opted to not configure inetd during the install, and chose to enable sshd, you're in great shape. The only services you'll have listening on a newly installed 5.x system are sendmail accessible only on the loopback interface, and sshd. If you did enable inetd, make sure you edit /etc/inetd.conf and comment out all unneeded components.

If you've just installed FreeBSD 4.x, the state of your system will vary depending on the security profile you chose. If you selected the extreme security profile, you will not have any remotely accessible services enabled and your first step is complete.

A FreeBSD 4.x system configured with a medium security profile will have a variety of running processes listening on several externally accessible ports. If your network card is not plugged in, that's not much of a problem but you are going to be online sooner or later. Sooner, really, because your second step in this process is updating your system to the latest security branch (for more information about tracking branches, see Chapter 4). So turn off those services by adjusting rc.conf(5) as appropriate, and plug in. If you didn't configure your network at all during the install, do so after these services are disabled.

FreeBSD has a handy utility called sockstat to assist you in determining what services are listening on what port. Use the command sockstat -l to list all listening services. If you want to limit the results to only IPv4 interfaces, run sockstat -4l. For more information, see the sockstat(1) manpage.

3.3.3. Step 3: Update Your System

A freshly installed system is rarely up to date. Chances are good that development has continued since you acquired your software, and numerous bugs (both security and otherwise) have been found and fixed. As we've mentioned before, make sure you're subscribed to the security notifications list, and have checked the security page on the FreeBSD web site for known vulnerabilities. In any case, it's time for your first system update.

3.3.3.1 Getting the latest sources

Once you have connectivity and are reasonably assured that your system cannot be compromised by a remote attacker, it is time to cvsup your system sources, and rebuild. But wait, in a fit of paranoia you did not install the cvsup package as part of the FreeBSD install! Why did you fail to install something of immediate use? Well, if you have no plans to install XFree86 on this machine, you need the cvsup-without-gui port, which is not available during the install. The cvsup that is available depends on X libraries that you would like to avoid installing if possible. Fortunately the acquisition of cvsup-without-gui is as simple as:

% sudo pkg_add -r cvsup-without-gui

Typically when impatient administrators use cvsup to update the source tree, they do so as root. Downloading source code shouldn't require root-level privilege. Really, the only reason this level of access is needed is because of default filesystem permissions. The cvsup program will need to store information in /var/db/sup, and will write into /usr/src. When you upgrade your system, you'll also need to write into /usr/obj. The solution here is to adjust the default permissions of these three directories (you may need to create /var/db/sup first) so that you can write to them without elevated privileges.

How you accomplish this is up to you. If you're the sole administrator in charge of performing system upgrades, you might just want to make yourself the owner of these directories as shown in Example 3-2. Otherwise, you may want to use a special administrators-only group and grant group-write access to these directories.

Example 3-2. Changing ownership of key directories for cvsup

% sudo mkdir /var/db/sup  % sudo chown -R  username  /var/db/sup /usr/src /usr/obj 

Now that you've got permissions straight, it's time to configure cvsup. First, you will need to create an appropriate supfile. This file sets a variety of defaults and will be read in by the cvsup program when you update your sources. Begin with one of the example files in /usr/share/examples/cvsup, perhaps standard-supfile. Look for a line that specifies the release and tag, for example:

*default release=cvs tag=RELENG_5_3

The tag specifies the branch of FreeBSD you want to track. In general, most carefully administered FreeBSD servers track the security branch which includes only critical bug and security fixes. Thus if you install FreeBSD 5.3, you will always be running FreeBSD 5.3 with patches, and the appropriate tag for this is in fact RELENG_5_3.

If the supfile you're working with indicates something other than a security branch, for example RELENG_5 (that indicates -STABLE) or just . (a period, that indicates -CURRENT), adjust the tag as appropriate. After you adjust the supfile, save your working file elsewhere, perhaps /usr/local/etc/security-supfile. Finally, update your FreeBSD sources by running:

% /usr/local/bin/cvsup -L 1 -h cvsup x .freebsd.org \    /path/to/your/chosen/supfile

Be sure to replace the x in cvsupx.freebsd.org above with a number corresponding to a cvsup mirror close to you.

Do not directly modify any of the example supfiles. If another example cvsup configuration file better suits your needs, use it instead. If you need to make drastic changes to any of these files, save a modified copy of the file elsewhere. You do not want to accidentally lose your changes during a system upgrade.

While it is possible to track the -STABLE branch, be aware that system upgrades may include more changes than you bargained for. Some administrators have had success carefully tracking the -STABLE branch by performing upgrades to noncritical servers and subsequently upgrading other servers (using source from the exact same time) after a great deal of testing. Other administrators have been badly burned by tracking this branch. Unless vital features or fixes exist in the -STABLE branch, stick with the security branch. Finally, forget about tracking -CURRENT on production infrastructure. It is too volatile and unreliable and is better suited to systems with which you tinker but not on which you rely.

After you have successfully performed an update, you have the opportunity to save your update preferences for later use. To do this, add a block similar to the following to /etc/make.conf(5):

SUP_UPDATE=         yes SUP=                   /usr/local/bin/cvsup SUPFLAGS=                   -L 1 SUPHOST=                    cvsupx.freebsd.org SUPFILE=                   /path/to/your/chosen/supfile

After doing this, you may update your sources by running make update from /usr/src.

For more information about cvsup including (and especially) using refuse files to tune which files or directories you retrieve, see the FreeBSD manpage for cvsup(1) and Appendix A.5 of the FreeBSD Handbook. To learn more about tracking branches of FreeBSD, see the relevant discussion in Chapter 4.

3.3.3.2 Kernel configuration

Before upgrading your system, you will probably want to fine-tune your kernel, both for security and performance reasons. Customizing your kernel configuration is typically recommended for FreeBSD systems, and only needs to be done immediately after the system is built and when you introduce new hardware. Given an environment where there are few hardware changes and consistent hardware across an infrastructure, the one time cost of fine-tuning yields rewards over the long term.

Creating a custom kernel configuration is almost never done from scratch. Typically you start from a copy of the /sys/conf/GENERIC kernel and remove options as necessary. In some cases it may be necessary to add hardware support from /sys/arch/conf/NOTES (In FreeBSD 4.x this file was LINT). As with installing distributions and packages, the following adage holds true: if you do not need it, do not install it. In a kernel context, this means if you do not need the kernel option, delete the configuration line and it will not be compiled in. The fewer drivers and options compiled into the kernel, the less always-running code there is to exploit.

Be careful with what you remove. It may not be obvious that some options are mandatory. For many releases, the COMPAT_43 option had the somewhat vague comment "Compatible with BSD 4.3" in the GENERIC file. Few administrators understood why they would want to be compatible with BSD 4.3 and removed this option. Then they discovered that their systems would no longer boot, and the comment now includes "[KEEP THIS!]."

The process of configuring a custom kernel is exceedingly well documented in Chapter 9 of the FreeBSD Handbook. While you need not actually compile or install your kernel in this step (we will do that in a moment as part of the system upgrade), now is a good time to create a configuration file for your custom kernel. The following list of options includes some of the changes you may want to make to the generic kernel for security reasons.

BPF

The Berkeley Packet Filter option in the kernel allows packet sniffers such as tcpdump(1) to function. On many servers, the bpf pseudodevice is probably not necessary. Some key exceptions are DHCP servers/clients and IDS hosts. Access to information provided by this pseudodevice relies on the user being able to read from /dev/bpf*. If you want to restrict snooping on network interfaces, remove the bpf device from your kernel configuration.

CD9660

Removing this option from the kernel will relegate the ISO9660 filesystem drivers to a kernel module. In a securelevel of 1 or greater, this module will not load, and access to a CD will require that you bring the system to single user mode or reboot. In a hostile physical environment, this may be desirable. In other cases, the administrative hassle will probably outweigh any security benefit.

DEBUG

This option is disabled by default and should remain that way on production servers. Turning this option on would cause symbols to not be stripped after linking yielding a larger kernel, larger core dumps (unless you have disabled core dumps using sysctl as described in Chapter 2), and more information in those core dumps.

IPv6, gif, faith

Falling under the category of "if you don't need it, don't install it," if IPv6 is not being used in your environment, there is no need to compile it into your kernel. Removing this option will shrink your kernel and allow for the removal of gif and faith devices that provide tunneling and relaying support for IPv6. Compiling without this option will also ensure that ports you build on your system after installing your new kernel do not have IPv6 support compiled in by default.

KTRACE

The KtrACE option in the kernel will provide for kernel tracing using ktrace(1) and kdump(1) as described in Chapter 2. This option is enabled by default. ktrace assists with debugging and providing empirical data regarding the types of I/O operations a program is requesting and arguments to these operations. As a result, ktrace can assist in leaking sensitive information to the individual running ktrace. Unless you plan on using ktrace for one of the purposes discussed in Chapter 2, it is probably best to leave this option out of the kernel.

MSDOSFS

The MS-DOS filesystem drivers will, like the ISO 9660 filesystem drivers, be compiled into a kernel module if this option is disabled. As with CD9660, the kernel module will not load at securelevel 1 or higher. In addition, even without this kernel option, mtools (in the FreeBSD ports collection) provides a means to access MS-DOS media without the support of this filesystem.

NFS

NFS between systems is rarely used on production systems with direct exposure to the Internet. Support for NFS and NFS_ROOT can be safely removed from your kernel configuration unless you plan to provide a locally accessible and read only master jail as described in Chapter 2, or your system is on a LAN and the situation calls for it.

UCONSOLE

This option allows non-root users to own the system console device (/dev/console). On an infrastructure system, there should be no need for users whatsoever. On a workstation or other server running X however, it is likely users will want to grab the console using programs like xconsole. Your situation will determine whether you want to leave this in.

USB

USB devices are invaluable on workstations. Some servers these days ship without integrated removable media bays at all and rely on the availability of USB floppies and CD-ROM drives. Your hardware will in large part determine whether USB devices should be supported by your kernel. In an untrusted environment, automatic support of USB media may not be desirable.

Remember that just because the functionality is not compiled into your kernel, you may still have access to it. Much of the kernel is modular, so even if you do not compile it in, you can load the appropriate module later, provided your system is running in a securelevel below 1.

Once you have decided how to build your custom kernel, save the configuration file with the other files in /sys/arch/conf. Be sure not to replace the original GENERIC configuration file, but instead, save your changes into another file, e.g., MYKERNEL.

3.3.3.3 Your first upgrade

With the latest sources sitting in /usr/src and a custom kernel configuration file ready, you're prepared to upgrade the system. This entire process has been comprehensively covered in Chapter 21 of the FreeBSD Handbook, so we will not waste time with the entire process here. Instead, a few do's and don'ts of upgrading your FreeBSD system.

• Do read /usr/src/UPDATING. Failure to do so could cause you to miss a step, rendering your system in a less-than-ideal state.

• Do create make.conf(5) for your system. If you plan to run a mail transport agent or nameserver installed from ports or ask a package, you would be well advised to configure make.conf so these binaries are not replaced during a system upgrade (this is less important during your first upgrade). Example 3-3 shows values in /etc/make.conf that might be appropriate for an i386 AMD based server with DNS software installed through ports instead of in the base system.

Example 3-3. Example /etc/make.conf for FreeBSD

CPUTYPE=   k6-2 CFLAGS=    -O -pipe COPTFLAGS= -O -pipe NO_BIND=   true    # no BIND NOGAMES=   true    # no games (games/ subdir) NOPROFILE= true    # no profiled libraries KERNCONF=  MYCONFIG BOOTWAIT=  3000

• In addition, your make.conf can assist with updating your source tree via make update by pointing it to your supfile and cvsup binary as described previously. For a full description of the options available in make.conf, see the make.conf(5) manpage.

• At this stage, don't worry about mergemaster(8) clobbering your configuration files. You haven't made any configuration changes yet. If you've never run mergemaster before, read the manpage. Table 3-2 describes options that may be useful to you in running mergemaster.

Table 3-2. Important mergemaster options

Option	Description
-i	If a file does not exist in /etc (it is being introduced as part of this upgrade), automatically install it.
-p	Pre-buildworld mode. Compare files essential to the success of the buildworld/installworld process. Run this before buildworld.
-v	Increase verbosity, useful the first time you run mergemaster.
-t [arg]	Specify an alternate temporary root from which to make comparisons.

3.3.4. Step 4: Wrapping Up

With your FreeBSD system upgraded, it's time to turn your attention to some final system lockdown activities. Because this process is so similar for both FreeBSD and OpenBSD, it has been placed at the end of this chapter under Section 3.6. If you decide to complete some of these steps before running mergemaster, you will have to be careful when selecting to install, delete, or merge configuration files you may have changed. Best of luck!