Hardening Concepts
OpenBSD Security Characteristics
Hardening Defined
Security Through Obscurity
Hardening Requires Making Choices
OpenBSD Security Characteristics
OpenBSD is widely regarded as the most secure general purpose
operating system available. OpenBSD gets it's security from two
characteristics. First, it has a relatively small, fully
security audited code base. A closely coordinated group of
developers have built a system emphasizing high quality,
relatively bug free code over rapid feature growth.
When OpenBSD adds features, they tend to relate to security. Passwords
can be encrypted selecting from several encryption methods and the
default Blowfish encryption allows loop configuration so fast machines
can have harder to crack password storage. Both the client and server
sides of SSH (the secure replacement for telnet and FTP) are installed
and ready to use at the completion of an install. Both OpenSSH and
OpenSSL are OpenBSD team products used on nearly every open source and
some commercial operating systems today. OpenBSD installs with a
Tripwire like, active auditing process as part of the basic install.
OpenBSD included a stateful firewall almost two years before Linux.
OpenBSD was the first operating system to implement IPSec and remains
one of a few to install it by default as a core part of the OS;
OpenBSD is an ideal platform for complete VPN solutions.
The second security related characteristic of OpenBSD is that many
features are disabled by default. Only the most widely used functions
(daemons or servers) are normally on by default. When features are on
by default or turned on with the standard methods, the configurations
are set up with an empahsis on security. Sendmail runs as a non
privileged user and DNS Bind (named) runs chrooted. File and directory
access are restrictive compared to most systems. Because features
that are typically on at the end of a standard install on other
systems, are often off on OpenBSD, the system is somewhat more
difficult to use than other systems for users unfamiliar with it. On
the continuum of open to closed by default, Microsoft Windows and
OpenBSD occupy the extreme opposite positions with other general
purpose operating systems falling somewhere between.
There is little that persons installing OpenBSD can
do to improve the quality of the OpenBSD code
base but there are a number of steps that can be taken to make
its configuration more secure. As it's installed by default,
OpenBSD is still a general purpose operating system. It includes
all the standard Internet servers as well as a number of servers
that are primarily intended for LAN use.
Hardening Defined
The process of hardening is that of identifying exactly what a
specific machine will be used for and removing or disabling all
system components not necessary for that function. It's turning a
general purpose computer into a single or limited purpose
computer. Here we're building a system suitable for use as a
firewall, web server or other limited purpose, Internet server.
The specific components left on a given machine will be determined
by the function or functions for which that computer will be
used. Multiple Internet services may run on a single hardened
machine.
More generally hardening may be treated as any and all of the steps
used to tighten or improve the security on a computer. Often included
are limiting the user population, password policies, access controls
and user and group rights and intrusion
detection, which is treated separately.
It's preferable that a system being hardened should not be connected
to a network until the hardening process is complete. It should not
be connected to a perimeter network or DMZ or whatever you call your
network segment that is directly connected to the Internet until
after the hardening is complete.
Building a hardened computer is not like installing a workstation
or a test or experimental machine. It's probably unlike any
install you've done before. I know that preparing limited
function computers for full time Internet connections required a
substantial readjustment in how I thought about the installation
process. The first computer that should be hardened and will
benefit most from being hardened is a firewall. All computers with
full time Internet connections should be protected by a firewall
and hardened to some degree.
You can't take many of the more extreme measures to harden a computer
as discussed here until you have enough computers that one or more are
truly limited function machines. Other steps are applicable to almost
any Internet connected computer. Hardening
OpenBSD page groups techniques that are related and has been
reordered to put the more useful techniques first but some techniques on
the same page may have very different values. Perhaps the most useful
approach is to start at the top of the new
Priorities, Costs and Benefits and work
down it until the described technique seems more trouble than it's
worth. Though many would argue with the specific order, it would
be pretty hard to make a case that any technique near the bottom of
this page is as useful as any near the top.
If you can't afford to dedicate your Internet server(s)
and harden them, your public Internet services should be
outsourced. Attempting to place a public Internet server on a
machine that is also used as a file server, to host internal
management systems or serve other general purpose internal
functions will both make it impossible to secure the Internet
server adequately and also expose valuable internal data to
unnecessary risk.
What benefit is to be gained from removing features on a
computer? Any potential intruder's purposes won't be the same as
those for which a hardened machine is built. The fewer general
purpose features on a specific computer, the harder it will be
for an intruder to access it or make effective use of it if it is
accessed. Hardening also makes it more difficult for internal
staff to use a machine in other than it's intended fashion.
Removing functions is preferred to disabling because part of the
intent of hardening is prevent even root users from being able to
re-enable functions by making simple configuration changes.
Depending on what software is left on the hardened machine and
what firewall and network security devices are in place, it may or
may not be possible for a root user to reinstall the removed pieces.
The right network setup can make it effectively impossible for
any user without access to local removable media to add
components to a system. Even where it is possible, it's obviously
more difficult to obtain the necessary pieces of some software
and put them in the right places and change the corresponding
configuration files than it is to just change the configuration
files.
The author believes in defense in depth. This involves putting
multiple, redundant obstacles in the path of a potential
intruder. If one obstacle is breached or bypassed, the next may
prevent entry. Obstacles are not limited to getting on to the
computer but include obstacles to the inappropriate use of the
computer by users and intruders who have gained access. The more
obstacles there are to get past, the more likely the intruder
will have tripped one or more alarms that is part of the system's
or network's intrusion detection system(s). Implementing
intrusion detection may be regarded as part of hardening a
system; for simplicity, I will treat that as a separate topic and
deal with it elsewhere.
Security Through Obscurity
There is a concept that is sometimes severely criticized by
members of the security community. It's called security through
obscurity. This is often no security at all but simply putting
things in obscure places where it's hoped the wrong people won't
find them. Some examples are public web and FTP servers with no
DNS entries. A little more obscure is a web server with no DNS
entry and running on an odd port. Placing a sensitive document
deep in an unlikely directory tree is another example. These are
all examples security through obscurity that are rightly
criticized as no security. In these cases, it's likely to be
simply a matter of time before the "hidden" resource is found by
the unwanted. With network and disk scanning tools it may not
even be very much time.
On the other hand some perfectly valid security techniques are
entirely dependent on obscurity for their effectiveness. The
obvious example is passwords. That is why so much training needs
to go into selecting good
passwords and why organizations that don't train users or
force good passwords are more likely to be broken into. Users
naturally tend to select passwords that are not obscure enough
and hence easily guessed or found by password cracking programs.
Even where obscurity isn't an inherent part of the technique, it
is a useful complement. Firewalls don't depend on obscurity to
work. Still no network administrator in his or her right mind
would publicly post a firewall's rule set or diagrams of their
network's topology. Doing so doesn't automatically give
potential intruders entry the way that possession of a password
in the right location does. Such information will, however, help
intruders or at a minimum keep them from wasting time on
well defended resources. Properly configured web
servers don't enable directory listings except in very special
circumstances. If someone is going to launch an application
level attack against a web server, learning what scripts or
programs are available is the first essential step.
Hardening Requires Making Choices
Hardening a system is about making choices. Specific choices may
make a system somewhat more secure but also more difficult to use
and administer. The choices appropriate to one site may not be
appropriate at another. The approach described here is
moderately extreme; some may regard the resulting systems as
unusable. Some even more extreme options will be discussed.
Anyone using these pages as a guide needs to make their own
choices. Few will opt for all the choices made here. Sometimes
the effort or added system maintenance burden will simply not
seem worth the limited gain in security. Options are presented
here for you to chose from. Every site needs to decide what
security measures are appropriate to the resources being
protected and practical given the skills of those who will be
using the systems. Technical security measures will not work if
your own staff is actively opposed to them.
I'm going to use an example from Windows systems because nearly
everyone will be familiar with it and it seems obvious to me. Some
authors argue that to secure a Windows NT server for use as an
Internet server, all Netbios services, which include file sharing,
should be disabled. My counter would be that by disabling file
sharing, one of the primary reasons for using a Windows server in
the first place has been eliminated. If users responsible for
maintaining a web site on a Windows server can't do this through
standard drive mappings, they might as well be connected to a UNIX
box. Of course disabling Netbios is more secure, but a firewall can
and should be used to block all Netbios traffic between the local
network and the Internet. whether or not Netbios functions are on or
off on any specific machine. There may not be as much defense in
depth as some would like but clearly the security advantages are
outweighed by the lost functionality. If security is important
enough to justify disabling file sharing, then a UNIX, or more
specifically an OpenBSD server, should be used instead of a Windows
server.
Most of the techniques discussed here are fairly standard and
apply to most UNIX systems. There is one technique introduced
here that I've not seen elsewhere. It involves using a CD-R disk
to store programs off-line that are essential to some system
operations but infrequently used. These may include compilers and
other development tools and system configuration programs that
would otherwise need to be reinstalled and then removed when
certain tasks are performed. By using a consistent directory
structure and standard mount point, symbolic links can be made to
the programs on the CD-R disk. When the CD-R is in the drive and
mounted, the programs are only somewhat slower than if they were
on the hard disk. When the CD-R is removed, the programs are as
inaccessible as they would be had they simply been erased from
the hard disk.
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.
|