GeodSoft logo   GeodSoft

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. Passwords and 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 staff.

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 strong, passwords.

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 sensitive files.

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.

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.