Hardening OpenBSD Internet Servers
Details Contents
Updated to account for changes in OpenBSD 3.0 on Dec. 15, 2001: an
overview of the 2.9 to 3.0
changes is included. Detailed how-to instructions for hardening
OpenBSD servers are are divided into the following topics.
Limiting users and using strong passwords as described in
Users, Files and Auditing
will provide the largest security enhancement for the least work.
Also discussed are key BSD system configuration files and their
permissions. Generally OpenBSD sets tight default permissions
but several key security related files are needlessly world
readable. Tightening permissions and adjusting the built in
security auditing system included with OpenBSD are covered.
Most unauthorized remote compromises are achieved by exploiting
buffer overflows in services. OpenBSD has an excellent record in
this regard but turns several services on by default that may not
be needed. Removing Unneeded
Services reviews these and describes how to turn these off
or enable others that may be needed.
Portmap, RPC, NFS, Sendmail and several minor
services covered. Use of TCP Wrappers to protect TCP services
that are needed and the use of port scanners to identify open
ports are discussed.
If an OpenBSD computer is exposed to an Internet connection and not
behind a dedicated firewall, IP Filter or now with 3.0,
Packet Filter, should be
considered mandatory. This discussion covers both OpenBSD 2.9 and
3.0 and both IP Filter and the replacement, Packet Filter, are
covered. Configuration options, controlling logging, monitoring
firewall results and creating and testing firewall rules are
covered. Not covered are issues related to two or more network
cards and routing or bridging issues. In other words, use of IP
Filter or Packet Filter on a non firewall host to protect that host
is covered.
BSD systems include some facilities to make unauthorized system
changes difficult.
Chflags, Immutable Files and
Security Levels create some interesting possibilities for
securing key system elements. Even root can't change a file once
it's made immutable without local access.
Read Only Filesystems and some
little known mount options may hinder an intruder's use of a system.
The possibilities, as well as the significant trade-offs, of using
these options are discussed.
All operating systems, including OpenBSD, include unnecessary
information in certain login banners and system greetings.
Logon Banners to Warn, Not Help
Intruders identifies where some of this information is kept
and tells how to keep it from reappearing after it's removed.
Suggestions for warning messages that may be required to pursue
intruders legally are included with where to place them.
Removing unnecessary or security sensitive files may limit the
damage caused by an intrusion, aid detection of an intrusion and
prevent accidental configuration changes that facilitate an
intrusion. Approximately three hundred programs in the basic
OpenBSD install may not be necessary or represent some threat. In
Removing Files, a well
commented script can automate their removal but reviewing a 600+
line script with sufficient care so that you can make your
own judgements will be time consuming. The effort of file removal
is rewarded with the potential to "lock down" a system or
specific parts of it, so that it cannot be changed without both
root access and the ability load removable media, such as the
described recovery CD or OpenBSD install media, into the
appropriate drives. The file removal script creates links to
removed files placed on a
recovery CD-R which then acts as a
system lock allowing
removed files to be used only when the CD is mounted.
The GENERIC kernel provided with OpenBSD is designed to include
support for all supported devices and provide maximum
compatibility with related operating systems. It also includes
support for several filesystem types, debugging and other
capabilities that may not be needed on all servers. What
capabilities can be turned off and when it may be desirable to do
so is discussed. The mechanics of building
Custom Kernels are described in
detail. Options applicable to all architectures and i386
specific options are covered. Other architectures are not
discussed.
A Check List page has been placed at the
end of this section and includes a printer friendly version. The other
pages a grouped based on related techniques and ordered roughly in by
importance with the most important techniques first. The Check List
page tries to reduce each operation described on the following pages
to a simple one or two line action item. Each is assigned a value of
0 (not recommended) through 5 (essential) based on criteria covered in
the Priorities, Costs and Benefits
page. The Check List items are listed in a suggested order of
completion. If you print the printer friendly version and pre mark
all the "NO" items that will not be performed, the remaining items can
be completed and marked in order.
Top of Page -
Site Map
Copyright © 2000 - 2014 by George Shaffer. This material may be
distributed only subject to the terms and conditions set forth in
http://GeodSoft.com/terms.htm
(or http://GeodSoft.com/cgi-bin/terms.pl).
These terms are subject to change. Distribution is subject to
the current terms, or at the choice of the distributor, those
in an earlier, digitally signed electronic copy of
http://GeodSoft.com/terms.htm (or cgi-bin/terms.pl) from the
time of the distribution. Distribution of substantively modified
versions of GeodSoft content is prohibited without the explicit written
permission of George Shaffer. Distribution of the work or derivatives
of the work, in whole or in part, for commercial purposes is prohibited
unless prior written permission is obtained from George Shaffer.
Distribution in accordance with these terms, for unrestricted and
uncompensated public access, non profit, or internal company use is
allowed.
|
