3.6. Post-Upgrade Hardening

At this point, you are ready to start locking down your system configuration. As we repeat throughout this book, disabling features and creating limits does not always increase the security of the system. It generally makes sense to take a "bang for the buck" approach to hardening. Deal with the most critical yet easily handled issues first before moving on to more complicated security with diminishing returns. The following steps provide one approach to system lockdown, but it is not the only way.

3.6.1. Configure Users and Groups

If your system will be serving multiple users, allowing logins, providing FTP accounts, and so on, spend some time thinking about how to structure your users and groups. For workstations with many users, configuration of different sets of users and groups on each machine may be impractical. However, through the use of a centrally managed authentication and authorization mechanism, users and groups can be administered in a scalable fashion.

The most important group on a BSD system is, of course, wheel. Members of the wheel group have a variety of read rights in /dev that normal users do not and are the only users allowed to su(1) to root (with knowledge of the root password, of course). You may choose to make yourself and other administrators members of the wheel group, but if you're using sudo, there's little motivation for doing so.

With FreeBSD 5.x and the introduction of ACLs, the reliance on Unix groups has diminished. In some cases (such as a file server) ACLs may be a more appropriate access control than groups. See Chapter 4 for additional information about user/group administration and access control for users and administrators. See Chapter 2 for more information about how ACLs work and how to use them.

3.6.1.1 Toor (FreeBSD only)

FreeBSD includes a toor (root spelled backward) account, which has been historically used to gain root access with an alternate root shell. The rationale being, should the system need to boot in single user mode, root (with statically compiled /bin/csh) would still be able to log in.

This user has since been made somewhat moot given two changes. First, when FreeBSD boots into single user mode, the administrator is prompted for a shell even if the default root shell is /usr/local/bin/bash, for instance, the administrator could enter /bin/sh and log in. Second, FreeBSD has introduced a fully dynamic system (binaries in /bin and /sbin are not statically linked, but rely on libraries elsewhere on the filesystem). A collection of static binaries for recovery have been placed into /rescue.

In any case, you shouldn't be logging in as root unless you're performing system recovery, thus the toor account may be safely deleted.

3.6.2. Adjust Mount Options

The following mount options can affect the security of the system. Turning on all options for every filesystem will render your system unusable, so do not do that. Look closely at what the options do, and consult the manpage for mount(8) for more information.

As mentioned previously, OpenBSD administrators may have some of these options already set depending on the filesystems that were sliced out during the install process.

noauto

This option, when specified for a filesystem in /etc/fstab, will ensure that the filesystem is skipped for mount -a (run during system startup). This can be useful for filesystems you want handy, but not mounted all the time such as CD-ROMs.

nodev

As the name implies, this option prevents character or block special devices from being interpreted as such when found on the filesystem. While all but the root filesystem are good candidates for this option, remember that chrooted or jailed services often require /dev inside their pseudo root filesystem.

noexec

Binary executables will not be loaded and executed from the filesystem if this option is set. All but the root and /usr filesystems are candidates for this option. Remember, however, shell scripts will continue to work just fine. On a system with developers, setting noexec for /home will ensure you get beat up in the parking lot on your way home.

nosuid

This option prevents the setuid or setgid bits from taking effect. Programs will run as the executing user. As the manpage for mount mentions, this option has little use if a setuid or setgid wrapper is installed and publicly executable on the filesystem.

rdonly

Nobody can write to a filesystem mounted read-only. It may be tempting to consider this option instead of using immutability flags, but root can easily get around the read-only option by running mount -uo rw filesystem. The system must be rebooted into a securelevel of less than 1 if the immutable flag is to be circumvented.

suiddir (FreeBSD only)

suiddir allows files in a directory with a setuid bit set to inherit ownership from the directory. Thus if the directory has the setuid bit set and is owned by root, other files created in that directory will also be owned by root. The manpage for mount provides good additional information about this option. Be wary whenever you enable suiddir.

There are a variety of other options available for mount, and you should seek them out. It's fairly obvious, though, that while these options are useful, they are by themselves not as strong as some of the other security features of FreeBSD. For a system built according to a defense-in-depth strategy, however, they're well worth using where appropriate.

3.6.3. Lock Down sshd

Authentication is the way systems are convinced you are who you say you are. By default, the secure shell daemon (sshd(8)) accepts a variety of authentication mechanisms including via password, public key, and through some alternate challenge-response mechanism. This may not be ideal.

3.6.3.1 Password authentication

Users are very familiar with password authentication: you provide your username and your password. If the password on file for the username you provide matches the one you provide, you have successfully authenticated. All you need is a valid username and password to get into a system configured to allow password authentication through SSH.

3.6.3.2 Public key authentication

To configure public key authentication for ssh between two systems, you must first generate a pair of keys for yourself: a public and private key. This is accomplished using the ssh-keygen(1) utility and will, by default, create a ~/.ssh/id_dsa private key and a ~/.ssh/id_dsa.pub public key. When your public key is placed on a target host in the .ssh/authorized_keys (or .ssh/authorized_keys2) file in your home directory, and you have in your possession (on the source host) the private key, you may successfully authenticate after typing in a passphrase. Note not only do you need something in your possession (the private key), you also need to know a passphrase. This is known as two-factor authentication and is a significant improvement over password authentication.

We strongly recommend reading the sshd(8) manpage to better understand how this form of authentication works. Suffice it to say that it is stronger than mere password authentication and should be required of users and administrators alike.

3.6.3.3 Challenge response authentication

By itself, this is not a single form of authentication. FreeBSD and OpenBSD treat challenge response authentication support in different ways as described below. This allows sshd to point to an alternate authentication framework. In the case of FreeBSD, this framework is Pluggable Authentication Modules (PAM). In OpenBSD, login classes determine possible authentication information. For more information about PAM and login classes.

Workstations on a protected LAN usually benefit from having a variety of authentication options available. Servers, on the other hand, should have a more restricted set of possible authentication mechanisms, we recommend limiting authentication to public key only. Below are configuration changes in /etc/ssh/sshd_config you may want to consider. See the sshd_config(5) manpage for more information.

Allow/deny groups and users

Specifying AllowUsers tells sshd to only allow logins by the listed users. Likewise, specifying groups after AllowGroups limits logins to users who are in the listed groups. The inverse options, DenyGroups and DenyUsers, do what you would expect.

ChallengeResponseAuthentication

This option specifies whether or not PAM should be used for authentication in FreeBSD and whether to allow the authentication styles described in /etc/login.conf to succeed in OpenBSD. It is enabled by default, and can be disabled if you are not using any of the authentication mechanisms specified in FreeBSD's /etc/pam.d/sshd or S/Key on OpenBSD. Setting this to NO alone does not disable password authentication on FreeBSD.

PasswordAuthentication

Password authentication for sshd is weaker than the other options and should be disabled on production servers where possible. At the very least, on infrastructure servers, enforce public key authentication by setting PasswordAuthentication to NO.

FreeBSD only: setting this to NO will still allow authentication through PAM, including password authentication. You will want to remove pam_unix(8) from /etc/pam.d/sshd or set ChallengeResponseAuthentication to NO.

PermitRootLogin

While this option accepts the arguments YES, NO, WITHOUT-PASSWORD, and FORCED-COMMANDS-ONLY, allowing users to log in as root makes accountability impossible. It becomes very difficult to tie people to logins, which is vital to successful auditing. Set this option to NO.

Protocol

If possible, restrict SSH connections to protocol 2 only. The SSHv1 protocol is vulnerable to a MITM attack for which many easy-to-use kits exist. In an environment where the SSHv1 protocol is still prevalent, develop a migration strategy to move users over to SSHv2 and change this option to read Protocol 2.

StrictModes

This is enabled by default, but it is important to know what it does. StrictModes checks file permissions before accepting login. Not doing this can introduce security problems should users leave their private keys unprotected.

UsePrivilegeSeparation

This tells sshd to fork(2) an unprivileged child process to handle the session. This child process runs as the user making the connection mitigating the risks of privilege escalation. It is enabled by default and is a good thing.

VerifyReverseMapping

This enforces RFC931 compliance. That is, the IP address making the connection to the server reverse resolves into a hostname, which in turn resolves to the IP address making the connection to the server. Turning this option on (it is disabled by default) will make people unhappy if they need to connect from environments where they have no control over DNS mappings. Use with care.

X11Forwarding and X11UseLocalhost

When both X11Forwarding and X11UseLocalhost are enabled, the server on which sshd is running provides a proxy display on the wildcard address instead of the loopback address. This exposes the proxy display to requests originating from outside the ssh tunnel. X11UseLocalhost is set to YES by default. Allowing X11 forwarding at all may expose the client system's X server to attack.

If you do not already have an SSHv2 key, generate one now. Resist the temptation to keep using your old key or password because of the hassle. With widespread support of the SSHv2 protocol in both open source and commercial software for most platforms, there's little reason to support either the older protocol or passwords.

3.6.4. Configure Basic Logging

Logs form the basis of your audit trail. Without them, there is little hope you will be able to track down what happened on a system after a security breach or malfunction. An incomplete set of logs will yield an incomplete picture when you are trying to recreate the series of events leading up to a security incident. Having logs by themselves may not even be enough. You need to be sure that your logs have not been tampered with and contain all the information you are interested in tracking.

First, decide what you are interested in tracking on the system. On a single-purpose machine such as a mail server, this is fairly easy: you want to know about important system events and have detailed mail logs. Next, make the appropriate configuration changes to /etc/syslog.conf (read the manpage for syslog.conf(5) for more information) as shown in Example 3-4 and HUP syslogd. If you have a syslog loghost server, do not forget to send your logs to it.

Example 3-4. Sample syslog.conf for a mail server

# Facility/Level specification             Log Destination *.err;kern.debug;auth.notice;mail.crit     /dev/console *.notice;kern.debug;mail.crit;news.err     /var/log/messages security.info                              /var/log/security mail.info                                  /var/log/maillog cron.info                                  /var/log/cron auth.info                                  /var/log/ssh *.emerg                                    * *.info                                     @loghost

Bear in mind, you may have to revisit this step after installing ports or packages should you decide to track logs from that application in a different file or by using one of the reserved local facilities. You also want to configure log rotation via newsyslog.conf to ensure that your logs do not fill up your filesystem. newsyslog(8) can be configured to zip up old logs at a certain time or size and reset permissions on new logs it creates. It will even maintain a certain number of logs so you do not have to spend time cleaning up after old logfiles.

Once you have your key logs identified, you may be tempted to use the append-only file flag (sappnd) so that your logs cannot be truncated. If you end up using this flag and you are running in a securelevel greater than 1, however, newsyslog will fail when it tries to delete the old log and create a new one.

For a more comprehensive treatment of logging and building audit trails, see Chapter 10.

3.6.5. Create Login Banners

In U.S. courts, the waters of computer crime and trespassing have only barely been tested. Advising users of your systems that their activities may be monitored and that only authorized users should log into the system only strengthens your position if you wish to use your audit trail in a U.S. court of law. Login banners are fairly easy to create and put into place, so there's no good reason to omit this step from your security checklist. Login banners should, at the very least, warn all users who attempt to access your system that they have no expectation of privacy, and that they implicitly consent to monitoring by using the system, and so on. Consult with a lawyer regarding words that are appropriate for your organization.

The message of the day file, motd(5) is an ideal place to enter a login banner. Various services print motd at login. If login banners are required before authentication (this is a good idea), the problem must be solved on a case-by-case basis. For services that are connection oriented (TCP) and are compiled with libwrap, (e.g., inetd) tcpwrappers can be used for login banners. There are three requirements for this:

• In the case of inetd, you'll need the -w option.

• /etc/hosts.allow must contain the banners directive (see the hosts_options(5) manpage).

• A file must exist in the directory specified as an argument to the banners directive above of the same name as the service for which the banner should be displayed.

A sample hosts.allow configuration may look like this:

ALL: PARANOID : RFC931 20 : deny ALL: ALL: banners /etc/banners

Files containing login banners would then need to be named in.telnetd, ftpd, and so on, and placed in the directory /etc/banners.

sshd may be configured directly by using the Banner configuration option. If you choose this option and provide your motd as an argument, you should also turn off PrintMotd, or users may start complaining of banner overload.

3.6.6. Configure NTP

Keeping your system's time accurate is vital. This is why changes in the system clock are limited to 1s per second at securelevel 2. Without a reliable timestamp, analyzing logs moves from the realm of "art" or even "science" to sheer futility. There are two parts to configuring ntpd(8): initially (and roughly) setting the system clock and keeping it accurate. On FreeBSD systems ntpdate(8) is used to initially change the system clock to the correct time, often at boot. OpenBSD administrators may be more used to rdate(8). In order to keep the clock accurate, ntpd periodically polls time servers and nudges the system clock back toward the right time, should it fall out of sync.

ntpdate on FreeBSD systems may be configured either through sysinstall after installation is complete or manually. rdate on OpenBSD systems may be configured after the install by setting rdate_flags appropriately in /etc/rc.conf.local. You may need to look up NTP servers in your geographic vicinity. A list of public NTP servers is available at http://www.eecis.udel.edu/~mills/ntp/servers.html.

Remember that ntpdate and rdate do not take into account network latency, will only query one server, and drastically adjust the system clock. This is useful to eliminate any large discrepancies that would preclude ntpd from running, but will not provide accuracy beyond a tenth of a second. ntpd uses sophisticated algorithms and multiple servers to keep sub-millisecond accuracy.

It's vital that you set the system clock before the system's securelevel is promoted during boot. This is easily accomplished on FreeBSD by adding the following to your /etc/rc.conf:

ntpdate_enable="YES"  # FreeBSD Only ntpdate_flags="-b  public-ntp-server.domain.tld"

OpenBSD administrators would similarly add the following to /etc/rc.conf.local:

rdate_flags="-n  public-ntp-server.domain.tld"

The ntpdate utility is approaching deprecation, which means it will eventually be removed from the operating system. To prepare for its impending doom, set ntpdate_program to /usr/sbin/ntpd and ntpdate_flags to -q. This will have the same effect as running ntpdate but will use ntpd instead.

ntpd is configured to run by specifying ntpd_enable="YES" in FreeBSD's /etc/rc.conf, or ntpd=YES in OpenBSD's /etc/rc.conf.local. Do not forget to create a configuration file according to the manpage for ntp.conf(5). At a minimum, you must specify one or more servers you wish to contact for time. For more information about configuring and securing ntpd, see the section entitled Section 4.5.5 in Chapter 4.

3.6.7. Tune Your Kernel

A variety of kernel variables can be adjusted on the fly using sysctl as described in Chapter 2. Now's a good time to refer to that list of variables and choose a subset that is appropriate for the system you are building. If you are uncertain about how your change may affect the system or applications you install down the road, skip this step for now and come back to it after your applications are installed. You may then adjust one parameter at a time and ensure that things are working as you would expect.

3.6.8. Set File Flags

Beyond the append-only flags available for system logs, there are a variety of file flags that can be set using the chflags utility. Again, these flags were discussed in depth in Chapter 2. While you might be able to set many of these flags now, it is probably safest to wait until you have installed additional packages. When the time comes, write a script to set and unset the flags this will help you make widespread changes without trying to remember later what files need to have which flags applied or removed. The mTRee(8) tool may help you take such snapshots of your filesystem permissions for use later.

3.6.9. Local Security

Local security is often overlooked by system administrators. Systems are not always located in airtight vaults, guarded by trained personnel, and behind other whiz-bang authentication devices. Even in supposedly secure co-location facilities, other organizations may send their administrators into your "cage." Even if you can afford your own cage, there may be other personnel whom you cannot completely trust with the keys to your system. And servers aren't the only systems vulnerable to local attack providing for local security in a computer lab at an educational institution protects both your campus network and the previous user of the system.

The bottom line is that, when a system is placed in an untrusted environment, additional steps need to be taken to prevent snooping. Mind you, you will be able to do little against someone armed with a bucket of water and some lithium, but you can at least protect your data to some extent. Consider the following steps to help protect your system from local abuse.

3.6.9.1 On the screen

When you walk away from a system, you leave behind some information about what you were doing. If you happened to be running privileged commands, there is a risk of information disclosure. There are a number of ways around this including:

Disabling scrollback buffers

In FreeBSD, the following options can be set to adjust the behavior of your default console driver syscons(4).

SC_NO_HISTORY          #disables back-scrolling in VTYs SC_DISABLE_DDBKEY      #disables the debug key. SC_DISABLE_REBOOT      #disables the ctrl-alt-del key.

Disabling the scrollback buffer cannot be done in OpenBSD, though Ctrl-Alt-Del is disabled by default.

Screen blanking

It can be useful to ensure that your screen is blank when you walk away and the system is idle. In FreeBSD, the splash(4) manpage describes the changes required to /boot/loader.conf and /etc/rc.conf, provided there is support in the kernel. OpenBSD provides wsconsctl(8) that allows you to adjust key wscons(4) variables. It is also possible to blank the screen at logout by adjusting /etc/gettytab from:

P|Pc|Pc console:\         :ht:np:sp#115200:

to:

P|Pc|Pc console:\         :ht:np:sp#115200:\         :cl=\E[H\E[2J:

Auto-logout

Automatic logout may be achieved system-wide in various ways depending on your shell. Adjusting /etc/profile and adding export TMOUT=seconds will affect bash users, and placing the command set autologout=minues into /etc/csh.login will affect csh (and csh-derivative shell) users. You may also enforce that tcsh users authenticate after spending several minutes idle and be subsequently logged out if they fail to do so by specifying set autologout=(x y) where y is the number of minutes to wait before prompting for authentication, and x is the number of total minutes to wait before logging the user out. FreeBSD's csh shell is actually tcsh, and this configuration would apply to root in this case.

3.6.9.2 Adjust /etc/ttys

Find the line specifying the console. This should be easy, it's near the top. Change the word secure to insecure. This will require that users enter the root password even when booting into single-user mode. In the same vein, you may want to consider assigning a BIOS password so the OS cannot be circumvented by removable media just don't require a password for internal hard drive boot.