Hardening OpenBSD Internet Servers
Remove Files, Create a System CD Lock and Key
Options for selectively "locking down" system functions by removing
the files needed to perform the function are discussed. All files
that can use network access to add components to the system are
considered for removal. A CD containing removed files, which may be
symbolically linked to, can become a physical key to the system as
both local media and root access are required to use functions
migrated to a CD-R. For example, relocating all password, user and
group maintenenace programs to a CD-ROM effectively eliminates
remote user maintenance and requires the CD-ROM (or BSD install
media) to perform local user maintenance.
Why Remove Files
The largest step in hardening an OpenBSD server is identifying
and removing executable files not needed for routine daily
operations. If I did not already know the function of the
program, I reviewed the man pages for every program in /bin,
/sbin, /usr/bin, /usr/libexec and /usr/sbin. The file removal
documented here removes over 300 programs. The large majority
of programs will be the same on all systems but some programs
stay or go depending on the specific purpose of the system
being built. For example httpd and related programs may be
removed on firewalls but must be kept on web servers.
I know that removing executable programs will seem pointless to
some. The consensus in the security community is that there is no
system that can't be cracked. If this is meant to include social
engineering attacks and the extremes of physical theft, extortion, or even
murder, then it's almost certainly true. If it's intended to
mean that every computer or network permanently connected to the
Internet is vulnerable to a network based attack, then I am
highly skeptical. I do, however, believe the overwhelming majority
of systems are vulnerable in some manner. I also know that as
much as I may know regarding computers and computer security,
it's dwarfed by what I don't know.
No matter what efforts are put into preventing a break-in or how
secure we think our computers and networks are, realistically,
everyone has to acknowledge the possibility that an intruder may
someday gain access to one or more of our systems.
Disabled services may prevent an intrusion. Removed files first
effect is to prevent a disabled service from accidentally being
turned on again, possibly by a well meaning system administrator.
A new administrator at a site may be used to always seeing some
service turned on. If the only thing that prevents this service
from being turned on is a 'NO' in /etc/rc.conf, the new
administrator may simply change the NO to YES. A service turned
on by accident won't be configured with security in mind. If
there are no executables, the attempt to turn it on will fail, and
hopefully prompt the administrator to inquire as to why the
system is set up as it is.
The primary effect of removed files is to hinder an intruder
after they have gained access. Depending on what tools the
intruder is used to working with that have been removed, the
absence of these tools may directly prevent the intruder from
inflicting certain damage on either the local or remote
computers.
Many intruders make use of rootkits or other prepackaged
exploits; file removal to the extent discussed here could break
such tools by removing programs the authors took for granted as
being present on the attacked system. An unskilled cracker
following in the steps of others won't know how to fix tools
broken in such a manner. Extensive removal of programs as
discussed below will significantly raise the knowledge level that
the intruder will need to function effectively on the system.
It's likely to effectively take "script kiddies" out of the
equation.
Removing many programs from the system may force a knowledgeable
intruder to perform more operations and to take longer to
accomplish specific tasks than the same intruder on a more
standard system would take. Both of these increase the
likelihood of early detection. The sooner an intruder is
discoverd, the easier it will be to repair damage and determine
the method of access.
Along these lines, where the FTP client is needed, it is renamed.
Of course it can be found. Renaming just forces an intruder to
look for it when otherwise they would only have to type three
letters
What Was Removed
As with the services that were disabled, removed programs were
not limited to potentially harmful programs. Almost everything
that did not appear to be necessary to support the machines
intended functions was removed. This included programs that
should be completely harmless such as banner as well as useless
programs such as audioctl, a program to control a non existent
audio device. Executables related to disabled services
were removed unless they were found to affect delivery
of necessary local services such as sendmail.
I kept all the simple text manipulation utilities as well as
anything I thought might be called from the system startup
scripts. Reviewing what was removed from the first systems I
hardened, it's clear that I kept some things that serve no useful
purpose. Each time I do this, I see more programs that can be
removed. remain.txt is a list of all
programs in the five core directories that were left on the
most recent OpenBSD 3.0 system that I hardened. (These whatis
lists are not a one to one correlation to the physical files
left as some programs produce serveral lines of whatis output
and others are not found.)
I have in the past removed programs that I'd installed into
/usr/local/bin but considered too dangerous to leave on a hardened
system, continuously available. Now such programs will not normally
be put on a system that will be hardened. These included nmap and
snort. Nmap was discussed above. Besides being used to gather
information about my network, a successful intruder could use it to
probe other networks thus endangering my Internet connection. After
losing all my computers to theft or fire damage, losing my Internet
connection is as damaging a security catastrophe as I can think of.
My systems are sufficiently backed up that I'm sure I could rebuild
them on new systems faster than I could get another DSL connection.
Security includes trying to assess all the ways that your
business can be damaged and the steps to prevent or minimize the
potential losses. Thus a cracked system, containing tools
generally perceived as cracking tools, can become a serious
threat to the system owners in a manner other than the obvious
threats to their own systems.
Snort is a network intrusion detection tool. It's a specialized
sniffer designed to detect network intrusion attempts. It can
easily be configured to gather information useful in cracking
systems on the same LAN segment as it is located.
Removing Necessary Files
I've done something else that I've not seen anyone recommend related
to hardening a system. I removed a number of programs that are
essential to the administration of the server but only used
occasionally. I could remove these and /usr/local/bin programs
because I was going to take an additional step that I've also not
seen recommended for hardened system. I burned all the removed
programs to a CD ROM as mentioned above. Removed programs
are replaced by links to the CD location when the CD is mounted.
Thus removed programs are available when the CD is mounted and
not when it isn't.
One set of necessary files that was removed were all programs
related to user creation and maintenance. Because OpenBSD keeps the
real user information in multiple files including non text database
files, it's necessary to use the proper utilities for adding and
changing users. Editing /etc/passwd with vi simply doesn't work.
The following programs were removed for this purpose: adduser,
rmuser, chfn, chpass, chsh, passwd, user, userdel, userinfo,
usermod, useradd and vipw. Initially I missed pwd_mkdb, which also
needs to be part of this group, as editing /etc/master.passwd with
vi (though not recommended) does work when followed by pwd_mkdb. The
group maintenance programs were also removed.
The intent is to make it impossible to alter any user
authentication and setup data without the CD ROM being mounted;
if successful, this effectively eliminates remote user
maintenance. This is probably practical for many firewalls; it
may not be practical for a web server if there is more than a
very small population of web content authors who need access to
the system.
Dangerous Programs
Examples of "dangerous" programs include the assembler and all the
compilers. There is some source code included in the standard
install and the kernel source or all source might be installed if
custom kernels are built. Without knowing exactly what is on the
system, there is no way of knowing what removed pieces may be
recreated or what existing pieces can be altered. Even if file
transfers are completely disabled a skilled cracker can write source
code with the tools on the system and if the development tools
remain, turn this code into executables. If file transfer is
available to a cracker, besides transferring binary files, they
could transfer source to tools that otherwise would not be available
or create Trojan versions of standard programs. It's pointless to
strip a system of programs and leave the tools to recreate the
removed programs.
One of the most useful and most dangerous programs that comes
with OpenBSD is Perl. A skilled Perl programmer can use Perl to
do anything that most compiled languages allow and can often do
it quicker. If you don't need Perl for Web CGI scripts and don't
use it for administrative purposes, then get rid of it. If it is
used, it's probably used too frequently for a link to a CD ROM to
be practical. The same reasoning applies to any powerful
scripting language such as Python or Rexx. These should never be
installed unless they are actively used and should be removed if
they are installed but not used.
Other dangerous programs include tcpdump which can be used to collect
plain text passwords that may be carried on the network segment of a
compromised host. Unfortuanately, starting with OpenBSD 3.0, you
must keep tcpdump online on a firewall machine if you want to view
the logs in a text format. You might do this on a different machine
that the logs are transferred to, provided this machine is also
an OpenBSD 3.0 system. Tcpdump appears to have been customized to
handle the file format extention necessary to include what the
firewall did with a packet, so tcpdump from other UNIX like systems
probably will not be able to read Packet Filter logs. It certainly
could not on a Red Hat 7.2 Linux system I tried it on. Thus the
standard binary format for Packet Filter, really isn't that standard.
Telnet and FTP clients, if they are not needed for the functioning
of the system, are often key tools in breaking into other systems.
If your network used only SSH, leaving telnet clients where
they are not needed, gives crackers tools to attack remote networks
for which you and your systems might be held liable.
Extreme File Removal
None of the files discussed so far affect day
to day routine operations or administration tasks. A truly
extreme approach to file removal would be to identify all the
really common utilities and essential system administration
utilities and place them on the CD ROM with the other removed
files. This would make the system virtually unusable for
interactive access, except when the CD ROM was mounted. It might
require that the CD be mounted during the boot process. The
system servers would continue to do their jobs but anyone who
accessed the system remotely would have an almost hopeless task
trying to accomplish anything. Care would need to be exercised
not to remove any programs that were referred to in cron jobs.
Think what it would be like trying to use a system missing the
following programs: at, cat, crontab, cut, diff, ex (vi's guts),
grep, halt, head, ifconfig, ipf, ipfstat, ipnat or pfctl and
pflogd in 3.0 and later, join, kill,
less, ln, ls, mail, man, more, mount (all versions except
cd9660), mv, od, pg, pwd, reboot, route, shutdown, sort, su, sudo,
sysctl, tail, touch, vi, whatis, which. Also missing would be
all the other programs already identified. Not listed are
any programs I know to be present in any of my cron jobs.
This would obviously, seriously hamper an intruder. It's also pushes
the trade-offs between security and usability beyond a point that I
am willing to deal with. I don't want to have to mount a CD every
single time I use a system for even a few minutes. A possible side
effect would be to cause the CD to be left in the drive, thus
defeating the original intent. Still, if you have a system that has
extreme security requirements, can always be administered locally or
at least in close physical proximity to the system and only requires
occasional system maintenance it's something to consider.
For specific machines it may well be worth selecting some of these
programs for removal. For example on a production firewall, after
the rule set is well tested and the network configuration stable,
it might be useful to move the network and firewall related
configuration commands and the reboot related commands to a
CD ROM and boot with the CD ROM mounted early in the boot process
and unmounted and ejected at the end of the boot process. This
would make it very difficult for anyone without local access
to interfere with the machine's core functions.
Scripting the File Removal
After preliminary testing identified the files to remove, the
removal and linking was performed via a simple script. Programs
identified for removal were added to the script. First each
removed program is moved from its normal location to a matching
directory tree under a /deleted directory. Then the script
creates a symbolic link to where the program will be on the
mounted CD that will be made. The
remove script script should be changed according to
the functions a specific system will be used for.
If you run this without reviewing every line, it may remove
programs you regard as essential. A successful run will
complete with no output. Any messages indicate a problem that
needs to be fixed.
I've commented the lines that remove firewall utilities,
printing, perl, web and FTP servers so if you want these removed,
these lines will need to be uncommented. Also commented are
removals that will cause error messages in OpenBSD's daily
script. The development, user and group management tools are
removed. Telnet, lynx and cvs are removed. All are dangerous if
not needed. Telnet has been discussed elsewhere. CVS can be used
to load software and unless actively used to keep a system
up-to-date, is not needed.
Even if you remove ftp, ftpd, and tftp, lynx will let anyone who
can get onto a system bring in any software they want. It's not
hard for a hacker to set up their own web server as a repository
for their hacking tools; they can even restrict access to it, to
current target systems. Lynx has the advantage (to an intruder)
of bypassing most firewall setups as very few restrict outbound
web browsing. I'd like to know of any programs I've missed that
can be used to add software to a system via the network.
Also included is a whatis listing of most
of the removed programs (current as of 3.0). A few of the removed
programs have no man pages so there is no whatis entry for these.
Use this as a preliminary guide to what to remove. After removing
files, the following command can be used in the major program
directories to review what remains:
find . -type f -exec whatis {} \; |less
By doing the program removal in a script, the script becomes
documentation for what has been removed and allows the process to
be repeated on other systems. By moving the removed programs to
a temporary location all their file owner and permission
attributes are preserved. A tar can be made of the deleted
programs and used to create the CD from which some will later be
run. The tar should be made from inside the /deleted directory
so that the deleted files in the tar will have the same relative
path as the original files and can be restored to their original
locations in a single operation by restoring from the root
directory.
If you want to later be able to reliably recreate the hardened
system, it is important that all removed files be removed via the
script and that the script and deleted file tar be kept in sync.
Before removing additional files, the previously deleted files need
to restored. If this is not done, the deleted files will be
scattered in multiple locations and rebuilding the system will
require more manual steps. If script and tars get out of sync or the
system gets messed up, an "upgrade" can be used to put back the
executable files and restore originial permissions. Only the
base30.tgz and comp30.tgz sets need be included. If permissions had
been changed on any files that were kept on the system, these would
be restored to their original settings. Pax could probably be used
to restore the files from the original install files without
affecting files left on the system but this would not restore any
files that were not part of the standard OpenBSD install.
Creating a tar of all removed files that has the same relative paths
as the file's standard locations do from the root directory, is
simpler than any alternative method that I've been able to
think of. Simply restore all deleted files from the deleted tar before
running an updated remove script. After the remove script is run,
a new deleted tar is created and used to build an updated CD as well
as to prepare for any subsequent rounds.
Be careful while creating and testing a remove script. It's easy to
damage a system doing this. If you're going to do it at all, doing
file removal immediately after building a custom kernel may be a
good idea. If you make a mistake you won't lose time invested in
other steps. A full backup transferred to another system before
running an untested remove script is a good idea. For convenience,
the remove script could be debugged early but the files to be
removed, restored to their normal location for most of the hardening
process. Both I and some readers performing this file removal have
run into problems by making / (the root directory) not world
readable, as the remove script was developed. This causes a variety
of security related errors including not allowing a non root user to
log in because the user's home directory is not available.
Both /deleted and its tar must
be removed from the system or there is no point in deleting
files.
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.
|
