ONLamp.com: An Overview of OpenBSD Security

Published on ONLamp.com (http://www.onlamp.com/)
http://www.onlamp.com/pub/a/bsd/2000/08/08/OpenBSD.html
See this if you're having trouble printing code examples

An Overview of OpenBSD Security

08/08/2000

OpenBSD is often noted for its code auditing and integrated crypto, but the security features go far beyond this. OpenBSD was built from the ground up on the model of being a fabric woven with security in mind, not a patchwork of bug fixes and security updates. This has led to OpenBSD finally being recognized today for what it is: the most secure operating system on earth. This article aims to illustrate these features and provide practical examples of their implication on production machines.

Encryption

One of the most astounding things about the information superhighway is the number of people driving down it with their doors unlocked. Users and even administrators still commonly employ systems where sensitive information such as financial records and personal details are thrown over public networks as clear text. This is largely due to the proliferation of cleartext protocols such as telnet, rlogin, and http. OpenBSD solves these issues by containing encrypted replacements by default: OpenSSH for telnet and rlogin and https (OpenSSL). One of the first configuration tasks for an OpenBSD administrator should be the correct setup of ssh and ssl to ensure system security. OpenSSH is configured via two primary configuration files; some useful excerpts of those files follow:

/etc/ssh_config (OpenSSH client configuration):

UseRsh no
FallBackToRsh no 
  # OpenSSH will never fall back 
  # to the cleartext RSH protocol.
ForwardX11 no 
  # Do not allow X windows forwarding 
  # through the SSH session.

/etc/sshd_config (OpenSSH server configuration):

Port 22
ListenAddress 0.0.0.0 
  # Listen on all active interfaces
HostKey /etc/ssh_host_key 
  # Store the key in the default location
ServerKeyBits 1664 
  # Generate a 1664 bit key (stronger 
  # crypto than by default)
LoginGraceTime 600 
  # Allow 600 seconds for a client to login
KeyRegenerationInterval 3600 
  # Generate a new key every 3600 
  # seconds (hourly)
PermitRootLogin no 
  # Do not allow clients to login directly as 
  # root, must use su
X11Forwarding no 
  # Do not allow X windows forwarding through 
  # the SSH session.
PermitEmptyPasswords no 
  # A password MUST be issued - no passwordless 
  # logins allowed.

With SSH configured using these or similar options, the next step in enabling OpenBSD crypto is to set up OpenSSL-based https. This is a good replacement to cleartext http when sensitive information is being parsed through CGI POSTs or similar methods. The official documentation for mod_ssl (located by default in /var/www/htdocs/manual/mod/mod_ssl/ on OpenBSD systems) provides more detailed configuration information, but the process is three relatively simple steps:

1. Generate a server key and self-signed x.509 certificate:

Generate a server.key:
openssl genrsa -des3 -out server.key 1024
Place this file in /etc/ssl
Generate a CSR (Certificate Signing Request):
openssl req -new -key server.key -out server.csr
Place this file in /etc/ssl
Generate an RSA key for your CA (Certificate Authority):
openssl genrsa -des3 -out ca.key 1024
Place this file in /etc/ssl
Generate an x.509 certificate for your CA:
openssl req -new -x509 -days 365 -key ca.key -out ca.crt
Place this file in /etc/ssl
Sign your CSR:
./sign.sh server.crt
sign.sh comes packaged with the OpenSSL source distribution.

2. Edit /var/www/httpd.conf:

In the main section:

<IfDefine SSL>
Listen 80
Listen 443
</IfDefine>

<IfDefine SSL>
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl    .crl
</IfDefine>

A <VirtualHost> tag for your domain:
<VirtualHost _default_:443>
#  General setup for the virtual host
DocumentRoot /home/www/vhost/www.mydomain.net/htdocs
ServerName www.mydomain.net
ServerAdmin admin@mydomain.net
ErrorLog logs/error_log
TransferLog logs/access_log

#   SSL Engine Switch:
#   Enable/Disable SSL for this virtual host.
SSLEngine on

SSLCertificateFile    /etc/ssl/server.crt
SSLCertificateKeyFile /etc/ssl/server.key
</VirtualHost>

3. Edit /etc/rc.conf to enable https:

httpd_flags="-DSSL"

Code auditing

One of the largest problems with systems such as Linux is the inclusion of unchecked third party software. If a vulnerability or security issue arises, the third party must release a patch and the operating system vendor must then redistribute this patch to their users. Not only this, but the third party software is not in any way audited or checked for quality by the operating system vendors and as such can be vulnerable for a long time before any sort of fix is available to users (as happened numerous times with wu-ftpd). One of the major steps forward for OpenBSD was when the entire source tree was audited for buffer overflows and vulnerabilities. This has been constantly maintained and has resulted in a product unparalleled in terms of security and system integrity. In saying this, third party software is usually necessary for the operation of a functional system, so OpenBSD makes it available via the ports tree, a mechanism for downloading, installing, and configuring third party software known to work under OpenBSD or modified to do so. I won't go into details here of configuring the ports tree -- this has been broadly documented elsewhere.

Security updates

As opposed to the majority of commercial vendors and even some other open source projects, OpenBSD takes a "full disclosure" approach to any bugs or vulnerabilities found in the source tree. This means that bugs are reported immediately to users in their entirety, generally with a patch or workaround included. The outcome of this is a system with no hidden bugs or "features" shielded from the users, a prime example of which is the +.htr bug recently in Microsoft IIS. Users wishing to monitor security updates as they occur can subscribe to the security-announce mailing list, or monitor the patches posted to the OpenBSD errata page. The patches provided are generally a source tarball, which can be simply installed over the top of an existing system. An example of this is the installation of the recent ftpd remote-root exploit patch:

1. Download the patch:

wget ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.7/common/019_ftpd.patch

2. Place the patch in your source root directory (usr/src):

mv 019_ftpd.patch /usr/src

3. Apply the patch to the source tree:

patch -p0 < 019_ftpd.patch

4. Recompile ftpd:

cd libexec/ftpd make obj && make depend && make && make install

5. Restart ftpd (which in this case has been started from inetd):

ps aux | grep inetd
root 19983 0.0 0.4 72 264 ?? Ss 29May00 3:03.68 inetd
kill -1 19983

As has been demonstrated, OpenBSD's "Secure by default" slogan holds merit in all aspects of the system. Hopefully other open source projects (or -- dare I suggest it -- commercial vendors) will start to take onboard this holistic security approach to their own systems. Next week's article, which is the final in the OpenBSD Explained Networking series, will look at the future of OpenBSD networking, examining developments such as ipv6 support, as well as other possibilities for future releases.

David Jorm has been involved with open source and security projects for several years, originally with OpenBSD and Debian GNU/Linux, now with the development team at wiretapped.net.

Read more OpenBSD Explained columns.

Discuss this article in the Operating Systems Forum.

Return to the BSD DevCenter.