Hardening OpenBSD Internet Servers
Users, File Permissions and Auditing
Unneeded users with weak passwords remain a common method of
gaining illicit access to a system. One general point on
hardened Internet servers is made but otherwise this page discusses
OpenBSD user and file permission specifics. The nightly security
audit is discussed. Some of the files for the nightly audit are
world readable. Changing this and fixing the resulting error
messages is covered.
UNIX Users and Security Groups are
covered more generally elsewhere.
Users and Passwords
Hardened systems should have the minumum number of users necessary to
perform their intended functions.
A hardened system should have at least one "normal" user added
who is the system administrator. This person should always log
in as themselves and su or sudo to root as needed. As additional
users are added to the system, logging in under personal accounts
rather than as root preserves accountability. Any users who can
su to root should have
strong passwords like root. I think it should be a universal
policy that no users ever share personal passwords or the purpose
of individual accounts is defeated. Root and some special purpose
accounts such as default database administrators or accounts used
for automated file transfers may need passwords known to multiple
I don't think root should ever (even with SSH) be allowed to
login directly to a system from any remote connection (network,
dial-up). If the system will not allow direct root logins, except
from the local console, which is in a presumably secure location,
then remote root login requires the knowledge of two, hopefully
The total number of accounts on a hardened machine should not
exceed the number that can be displayed on a single terminal
screen or less than 24. The fewer, the better. The system administrator
of a hardened machine should recognize every user, their home
directory and shell. The more scrolling that is necessary to see
all users, the less likely that system administrators will spot
bogus changes. Intruders who have gained root access on a
compromised system, typically add accounts for remote login
purposes and may create alias root accounts. When the number of
users reaches the point that all system administrators don't know
the users well enough to easily spot the addition of such bogus
accounts, it's hard to consider a system hardened regardless of
what other configuration characteristics it may posses.
The /etc/security script provided with OpenBSD and run once a day
by default via cron and the /etc/daily script will find some of
the "odd" users sometimes created by intruders. If an intruder
has succeeded in creating a new user or modifying an existing one
they've already achieved root status and may be able to
circumvent or alter /etc/security so that it does not reveal
their actions. It's best for the legitimate system
administrators to recognize all users.
OpenBSD is installed with fewer special purpose users than most
systems and those that are included are set up in a secure manner.
There is no guest who can login as a normal interactive user without
a password as some systems have been delivered. There are four
users associated with specific services or programs that should
perhaps be removed if the services will not be used. These are
named, popa3d, uucp and www associated respectively with the BIND
name service, POP3, UNIX to UNIX copy and a web server.
No files belong to popa3d or www so there should not be adverse
consequences from removing these. I've seen no problem with
removing named but files in /var/named do belong to this user.
Removing uucp will require some cleanup. The "/var/log/aculog
uucp.dialer" line in /etc/newsyslog.conf will need to
be commented out to prevent hourly e-mail error messages. Also
removing uucp will require adjustments to /etc/mtree/special as well
as to the files described, to account for the now unknown user and
resulting messages in the daily output and insecurity reports.
OpenBSD Specific File Permissions
Generally OpenBSD file permissions seem about right but there are
some files that OpenBSD leaves world readable where there seems to
be no need of this. The system startup and configuration files that
several of these hardening pages deal with, the files related to
OpenBSD's daily, weekly and monthly activities and some of the root
login files should not be world readable. The startup and
configuration files, all in /etc include: hosts.allow, hosts.deny,
inetd.conf, login.conf, rc, rc.conf, rc.local, rc.securelevel,
rc.shutdown, netstart, syslog.conf, firewall and NAT rules
(ipf.rules now replaced by pf.conf, and ipnat.rules now replaced by
nat.conf in 3.0). The hosts allow and deny files are not present in
a default install. Note hosts.allow and hosts.deny are not part
of the default install but may be added for TCP Wrappers or
additional control of sshd; if present these are importan security
The OpenBSD install creates several cron jobs. The scripts for
these jobs and some data files used by the scripts all reside in
/etc. They are: daily, weekly, monthly, security, changelist
and /etc/mtree/special. Security is the script that generates the
daily insecurity report. It uses changelist for a list of files
to backup and check for changes. I find it puzzling that
changelist and security are world readable when
/etc/mtree/special, that is also used by security is readable
only by root (as it should be). The root login files, .cshrc,
.login and .profile in /root are world readable by default.
Knowledge of the contents of these files does not give a non root
user access to anything directly but there seems to be no reason
why a normal user has any need to know any of these things. For
example, a normal user attempting to elevate their access level
can use the ability to read security and changelist to determine
what files the security script checks for changes. If the user
does elevate their access, this will save time that needs to be
spent as root performing steps to cover their tracks. They can
determine that by removing /etc/changelist from changelist that
they can then remove other files from changelist that they wish
to change and do not want to be checked for changes.
Unless the intruder already knows OpenBSD well, they will not
know this. If security and changelist were root readable only,
an intruder could not determine their uses until after root
access was gained. Any intruder should be curious about the
contents of a file named "security" in /etc even if they know
almost nothing about OpenBSD. On the other hand, while intruders
may be able to determine the general purpose of
/etc/mtree/special (from /etc/security) they can't know what
files are listed in special or what settings have been placed on
the listed directories and files. Interestingly, special is not
included in /etc/changelist; it should be.
The daily insecurity report is not created if no security related
changes are detected. If the files listed above are changed so they
are not world readable or access to any other files listed in
/etc/mtree/special is additionally restricted, the daily insecurity
report will start listing them as not matching the "preferred"
permissions defined in special. To stop these messages from
appearing every day, special needs to be edited so that the
recommended permissions match the actual settings. Otherwise, these
daily messages may mask reports of new and unauthorized security
changes. In no case should any of the settings in /etc/mtree/special
be made looser or more open.
Some additional files with security implications should be added to
/etc/changelist and /etc/mtree/special. These include the remove
(disucssed later) and local backup scripts. It's probably worth
considering adding any script run from crontab or regularly run by
root. If the system is used as a firewall or network address
translator and the production rules are located in any but the
default files, the actual rule files should be included. Hosts.allow
and hosts.deny should be added to special if they are created; they
are already in changelist.
Top of Page -
Copyright © 2000 - 2006 by George Shaffer.
This material may be distributed only subject to the
terms and conditions set forth on
These terms are subject to change. Distribution is subject to the then
current terms, or at the choice of the distributor, those defined in a
verifiably dated printout or electronic copy of
http://GeodSoft.com/terms.htm at the time of the distribution.
Distribution of substantively modified versions of GeodSoft content is
prohibited without the explicit 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 permission is
obtained from George Shaffer. Distribution in accordance with these
terms, for private, unrestricted and uncompensated public access, non
profit, or internal company use is allowed.