GeodSoft logo   GeodSoft

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.

transparent spacer

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 (or 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 (or cgi-bin/ 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.

Home >
How-To >
Harden OpenBSD >
Details Contents >

What's New
Email address

Copyright © 2000-2014, George Shaffer. Terms and Conditions of Use.