Practical Guide to Software Quality Management (Artech House Computing Library)

OpenBSD's proactive "secure by default" approach to security results in a very secure system immediately after install. The goal here is to ensure system administrators start from a system that is not open to remote compromise. Therefore few services will be running after a fresh install, and these services will have undergone rigorous review. If you have followed the recommendations in this chapter, you will have taken things one step further. You have ensured that there are no listening services or have verified that any listening services are not vulnerable to remote exploit.

Nevertheless, system security is an ongoing process, and there is more work to be done. The following two steps are essential to bringing your system into a more secure state, and continued diligence will keep it there.

3.5.1. Step 1: Create a User

When you first log into an OpenBSD system you are admonished for logging in as root. The default .login file from which commands are executed under the default c-shell (csh) includes this warning. It's a bad idea to run around your system as root; a stray typo could send the system into an unrecoverable state. Instead, create a local user account for yourself and use sudo(8) to execute privileged commands. This will accomplish three things:

• It will keep your system safe from you.

• It will ensure that you think about the privileged command you are about to execute before blindly typing it in and hitting enter.

• It will provide a valuable audit trail of privileged commands executed.

Both adduser(8) and vipw(8) will allow you to create a user, though the former command is a little more helpful and will allow you to set a user password. Many administrators like to add themselves to the wheel group at this point. However, you don't need to do this to gain root level access since you're using sudo.

3.5.2. Step 2: Configure sudo

We'll make this step brief because 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 in the previous step. 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.5.3. Step 3: Turn Off Unnecessary Services

Looking at the process list after login (by running ps ax) will show you what's running on your system. Checking the output of netstat -a on a freshly installed OpenBSD 3.5 system will show that sshd, and a few basic services provided by inetd (identd(8), daytime, time), are remotely accessible. In addition, sendmail and comsat(8) are listening on the loopback interface. Depending on the kind of system you are building, some of these services may not be necessary. Let's go through each of them and discuss whether you need to adjust or disable these running services.

3.5.3.1 sshd

The secure shell daemon is of fundamental importance. It serves as your primary means of remote shell access to your system and it is rare you would ever want to disable this service. However, by default, the sshd daemon will allow logins as root. You have already created a user that has sudo rights, so there's no reason to continue allowing logins as root. This can be disabled by setting PermitRootLogin in /etc/ssh/sshd_config to No. For more information about tightening security around sshd, see the Section 3.6 section, later in this chapter.

3.5.3.2 inetd

There are several programs running "out of" inetd by default. For the most part these services are trivial and not prone to attack. However, they are also not particularly necessary and can probably be disabled on most systems. If you are building a workstation, services running out of inetd such as identd and comsat may be useful. inetd with a default configuration, however, is best disabled on infrastructure servers by placing inetd=NO in your /etc/rc.conf.local. You may revisit this decision later.

3.5.3.3 Sendmail

There is little harm in keeping sendmail running in its default configuration on OpenBSD. It listens only on the loopback interface and as such, is only vulnerable to attack from the local host. If your system provides many user accounts, however, you need to ensure that your locally listening services are patched. Alternately you could replace sendmail with another MTA See Chapter 6 for more information on building a secure mail server.

3.5.4. Step 4: Update Your System

It's time for another look at the Errata page on the OpenBSD web site. Here you will find a list of security and reliability issues that have been identified since the latest release and ways to resolve them. The role of your system will determine how you want to approach the topic of system updates now and in the future. OpenBSD has three options available for system update: patch manually, track the patch branch (otherwise known as stable), or track the current source.

Any of these options are viable for OpenBSD workstations, but servers (especially infrastructure servers) must be treated with more care. It's a good idea to limit your updates of servers to the patch branch. For more information about OpenBSD's branches of development, see the relevant discussion in Chapter 4.

So, let's begin by getting a cvs checkout of the appropriate patch branch. First ensure that /usr/src is owned by you or writable by a group to which you belong. Then retrieve OpenBSD sources as follows:

% setenv CVSROOT anoncvs@ some.server.somewhere.tld :/cvs % cd /usr; cvs checkout -P -rOPENBSD_ X_Y src

Where X_Y (e.g., 3_5 for OpenBSD 3.5) is the patch branch you wish to track. For a list of anonymous CVS servers, see http://www.openbsd.org/anoncvs.html. Once the source has been downloaded, rebuild your kernel and make world. For a walkthrough of an OpenBSD upgrade procedure, see the OpenBSD patch branch documentation at http://www.openbsd.org/stable.html. OpenBSD does not encourage that you develop a custom kernel configuration unless you have specific hardware requirements. The following is an excerpt from the OpenBSD FAQ:

Under most circumstances you will NOT need to compile your own kernel. The GENERIC kernel will usually be all that you need. In fact, there are several reasons why you do not want to create your own kernel. The main reason is that it is very easy to make changes to the kernel configuration which look logical, but do not work. This is your danger sign. If something does not appear to work properly, please try the GENERIC kernel before sending in a bug report. Developers will usually ignore bug reports dealing with custom kernels, unless the problem can be reproduced in a GENERIC kernel as well. You have been warned.

As a result we do not cover the process of building a custom kernel configuration. Should the need arise, there's plenty of information for you in the FAQ.

3.5.5. Step 5: Wrapping Up

Once your system has been updated and is running only those services that you require, you can turn your attention to some of the more fine-grained security controls. These steps are fairly similar for both OpenBSD and FreeBSD, so the following section, Section 3.6, covers both operating systems.