Linux, OpenBSD, Windows Server Comparison:
So far we've looked primarily at problems that expose systems to
unnecessary dangers which can be fixed by knowledgeable
administrators. We have not looked explicitly how the default
installs compare. It's very easy to rate the systems default
installs, because only OpenBSD is specifically designed to be secure
by default. There is no contest. For an operating system installed
from the standard disks, using all default options, OpenBSD is far
ahead of the leading Linux distributions, and even further ahead of
any Windows system. A review of OpenBSD will show some of the prime
characteristics of a system designed to be secure by default. Here we
are looking at a general purpose operating system and so Linux
comparisons will be to widely used general purpose distributions such
as Red Hat. There are specialty Linux distributions such as Trustix
and EnGarde that specifically configure Linux to be very secure.
OpenBSD has a well deserved reputation as the most secure general
purpose operating system available. There are several reasons
for this. For starters, creating a stable and secure system was
the primary goal and reason for OpenBSD's creation. OpenBSD was
an outgrowth of NetBSD. NetBSD is known for running on more
hardware platforms than just about any other operating system.
FreeBSD split from NetBSD because the developers wanted to
optimize the system for performance on Intel processors. As a
result, FreeBSD is widely regarded as the fastest OS that runs on
Intel systems. OpenBSD split later with the goal of creating a
reliable and secure OS. When someone or an organization has a
clear and realistic goal and does not have conflicting
priorities, the goal can normally be accomplished.
Strictly speaking, a system can only be optimized for a single
factor. Reliability and security are not separate. Rather,
reliability is a prerequisite for security. The large majority
of security problems are the result of bugs. A bug is a
system doing something unexpected or failing to do the expected,
often in response to an infrequent or unexpected event.
Historically, the most frequent and dangerous security problems on
most systems have been buffer overflows: a service running as
root, an administrator or the system, does something unexpected,
for example, allows the execution of arbitrary code, in response
to an unexpected event, such as the arrival of excessive data.
Eliminating bugs is the first prerequisite of a secure system.
The BSD family of OSs is relatively small and simple compared to many
of their competitors. This means there are less lines of code to have
bugs. One key characteristic that sets OpenBSD apart from most other
systems are periodic and systematic code audits. To quote from the
"Our security auditing team typically has between six and twelve
members who continue to search for and fix new security holes. We
have been auditing since the summer of 1996. The process we
follow to increase security is simply a comprehensive
file-by-file analysis of every critical software component. We
are not so much looking for security holes, as we are looking for
basic software bugs, and if years later someone discovers the
problem used to be a security issue, and we fixed it because it
was just a bug, well, all the better." The same OpenBSD page
states that thousands of bugs were fixed in late 1996 and early
1997. Each release of OpenBSD, which comes every six months,
includes new features and enhancements, but the focus remains on
quality so OpenBSD's growth is evolutionary.
Secure by Default
In part, because it's not a commercial system, OpenBSD can take a
secure by default stance. Their security page states "All
non-essential services are disabled." OpenBSD has less services
turned on by default than nearly any other system available.
When I first wrote my web pages on
Hardening OpenBSD Internet Servers,
2.7 was the current release. I identified 10 services that were
turned on by default and I thought could be disabled on a machine
intended as a web, FTP, e-mail, DNS or other Internet server or
firewall. In 2.8, two of these were no longer on by default.
In the mid nineties, when OpenBSD was first developed, the
Internet was much less hostile, and its was expected that UNIX
machines would network locally, with other UNIX machines via
services that are now widely regarded as LAN services, and not
suitable for use across the Internet. The Portmap service is a
key component on which many of these services depend and is still
on by default; a comment describes it as "Nearly always needed".
On the other hand, a very common service, NFS has been turned off
by default since I've been familiar with OpenBSD (2.6). This is
equivalent to Windows disk sharing.
Secure by default tends to be a problem for any system that
attempts to be "easy to use" including most commercial systems
because such systems appear to be less functional than ones with
all common services enabled. For example, on the first Red Hat
Linux system I installed in 1999, httpd was up and running when I
first looked for it. In contrast I had to learn how to control
services on OpenBSD before I could run a web server.
Part of the secure by default hope and assumption is that if
services are not already turned on, people will learn something
about them before turning them on. At a minimum they must have a
knowledge of the function, a desire to turn it on and learn how
to do that much.
It just happened that I wanted to run a web server on the Linux
machine. It's likely that most Linux machines, even those set up
as servers, won't be intentionally running user maintained web
sites. Some users would never be aware that their PC was running
a web server. Services that are turned on but not used are just
an intruder invitation, especially those that run as root.
Apache on Red Hat Linux 6.1 was not running as root.
Where a server, such as a web server is on by default but not
used, it may never get turned off and you can be sure that it
won't be updated if a security issue is found. Any administrator
knowledgeable enough and dedicated to actively upgrade services
when a security issue is found, would have already turned off all
Secure by default not only routinely turns off services that
would otherwise be on, but it also typically does not install
software that would otherwise be included in default installs.
This will include specific services that are less used but it
will also include support libraries that are not needed by those
servers which are installed. Thus when an administrator adds a
new function to a secure by default system, they are likely to
find that they must also locate and install support libraries or
functions that are not on the system.
A secure by default system is likely to have many file and
directory related security settings that prevent ordinary (non
root) users from doing things that are allowed on most systems.
Examples include not allowing users to su to root unless they are
in the wheel group or view systems files not needed for the
ordinary use of the system.
"Four years without a remote hole"
The OpenBSD web site opens with a claim that attracts some
attention including claims that it's not true or someone just
found a bug that invalidates the claim. The statement is "Four
years without a remote hole in the default install!" They do not
provide a detailed explanation what this means so lets analyze
it. I think "Four years without" is clear enough that it's not
likely to provoke substantive discussion.
I've seen some claims that there was a bug in some piece of
software that is commonly installed and is thus a "default" at
the sites it's installed. I don't think that's what "in the
default install!" means at all. I think it means in the software
that will be running following an install from the standard media
taking all the default options.
Commonly used software that is not on by default includes NFS,
FTP, telnet, DNS and IP Filter (now removed from the CVS source
tree for license reasons). Bugs or holes in any of these would
not count because they are not "default install".
"remote" means network access. If a user is already logged in,
either at the console or from a remote location but now acting
locally via ssh, telnet or rsh, it doesn't count. It means via a
network protocol. If for example, sshd which is on by default,
had a buffer overflow that could be exploited via the network,
without using it to log on, either with encrypted keys or a
username and password, that might break the four year run.
Finally what does "hole" mean? I don't think it means bug. If
you look at the OpenBSD Security Advisories under 2.8 you will
find "May 29, 2001: Sendmail signal handlers contain unsafe code,
leading to numerous race conditions." Sendmail is on by default
and if hole meant bug then OpenBSD would need to change the
opening web statement.
UNIX Signal Handler and Open Source Software Fixes
In the May 31, 2001 issue of the SANS Security Alert Consensus
mailing list the lead article begins "An interesting research
paper by Michal Zalewski of Bindview was released this week
detailing various problems in the signal handler design of Unix
applications. We expected to see some vulnerability advisories
based on this problem in the near future; however, they've
already started -- Sendmail (a widely deployed mail server on
Unix) has released an updated version to fix the problems
outlined in the paper."
The paper itself is dated May 16-17, 2001. It appears however
that the authors did not publicly announce the problem until they
posted an announcement to the Bugtraq mail list on May 28. The
SANS Alert refers to
archive. Apparently Michal Zalewski contacted key UNIX
vendors so that they could fix their products before making a
Also note that the OpenBSD fix is available with the announcement
the day after the problem is publicly announced. I couldn't find
any release dates on the Sendmail site. I would guess that
OpenBSD was already working behind the scenes with authors of
Sendmail and coordinated the timing so that the fix would appear
just after the public announcement.
Later in the SANS Alert under the Sendmail specific item, they
say the denial of service attacks would be possible and that root
compromise was a possibility. There was no suggestion that any
actual exploits or denial of service attacks had been developed
let alone successfully used against anyone yet. Like most bugs,
there is some idea of what definitely can be done with it but
it's harder to know what the limits to the problem are. Someone
more imaginative than those currently examining the problem might
see additional ways to exploit the problem than those who first
to study it.
This is a good example of how the open source model can work.
Someone identifies a problem and notifies key parties behind the
scenes. Fixes are developed and released at about the same time
as the problem is announced. No black hat ever has a chance to
exploit the problem.
Actually that is not true. There are millions of UNIX
computers most of which use Sendmail as their mail transfer
agent. Sendmail is on by default on nearly all systems with
which it's included. It will be interesting to see how long it
takes the various Linux vendors to have patches for their
distributions. Of course even though some patches are out now
and others will be soon, most systems will never be updated.
That's no different than with commercial software. Once the
vendors or open source authors have announced the problem and
released fixes, they've done their job.
What's important here is that a problem was found by white hats
via code review and analysis and that it was circulated in a way
that key parts of the UNIX community released fixes before the
black hats knew of the problem. With any proprietary product
only the employees can look at the code. Once a current product
is tested and released, no one is likely to look at existing code
until someone reports a problem. Of course as some critics say,
the vast majority of open source users do not review the code
they use. What matters is that for any significant code, a lot
more than the one or two authors directly involved do read the
IP Filter Bug
The speed of the Sendmail fix is not unusual for an OpenBSD
response to any security related issue. Another recent security
issue that affected OpenBSD was the fragment caching
vulnerability in IP Filter. The OpenBSD Security Advisory said:
"Apr 23, 2001: IPF contains a serious bug with its handling of
My recollection when I first read about it a week or two after
the advisory was that it did sound serious. Serious enough that I
pursued installing the patch. I had some difficulty with the
OpenBSD patch and had to update from the IP Filter site. I
believe the patch was posted about five days after the problem
was first publicly discussed. As a point of contrast, not relevant
to the systems being compared, but still rather interesting,
Hewlett-Packard announced their fix to this problem on Jan. 23,
2002, or nine months to the day after the OpenBSD announcement.
Unlike the signal handling issue, this was not handled quietly
behind the scenes but announced publicly by the person who found
the problem. Once again though, it was found by someone not
associated with the source code, reading the code and seeing the
After I'd read most of the relevant matter and upgraded my IP
Filter, my conclusion was that a more accurate description would
be "an interesting theoretical bug" rather than a "serious bug".
I understand why it was called serious and this emphasizes how
seriously security is taken by the OpenBSD authors lead by Theo
De Raadt. See below for why
I did not consider this a serious bug.
It also returns us to the definition of a "hole" versus a "bug".
I believe a hole means a bug that was actually exploited to in
some way harm an OpenBSD system before a fix was posted on the
OpenBSD site. Granted, if some system were compromised by this
problem on May 30, as a practical matter, there would have been
no way that the administrator could have been expected to learn
of the problem and apply the fix in time to do any good. The
system authors though, can't be responsible whether
administrators fix their sites within a week or a month or never.
So what does "Four years without a remote hole in the default
install!" really mean? It means that no one who has installed
OpenBSD with default options has actually experienced a network
based intrusion in four years. Since the OpneBSD authors can
only go on what they know, it means no one who has reported such
an intrusion. As OpenBSD is only used those who are more than
casually concerned about security in the first place, it's very
likely if such an intrusion had occured, it would have been
reported. Even though OpenBSD is not widely used, it is an
impressive record. I know in my Internet explorations, I've
seen statements to the effect that many would be intruders,
as soon as they determine a target system is OpenBSD, move onto
In the past four years there are less than 75 OpenBSD Security
Advisories. Most of them are with peripheral products that are
distributed with OpenBSD, like IP Filter and most sound a lot
less serious than the IP Filter problem which I prefer to
characterize as theoretical.
A quick look at my web site will leave little doubt that I'm
aware of and concerned with security issues. Enough so that if I
screw up, I can't blame anyone but myself. I think the
practical implications of many bugs reported as serious security
issues is greatly overstated. Had I understood the IP Filter
problem as well, before I set about trying to fix it as I did
afterwards, it's unlikely that I would have bothered, even though
I consider my firewall to be my second most important security
measure (after backups).
OpenBSD Daily Security Audit
The *BSD family, including OpenBSD, comes with a feature lacking
in other operating systems I've worked with. It has a daily
security audit that is turned on by default. Every night, an
e-mail to root is composed that analyzes all kinds of security
related settings. If any system files have changed or any
security related permissions on key files or directories changed,
any suid programs added to or modified on the system, any world
writable directories created or any of several other changes
that might indicate a security issue, an automated e-mail to root
describes the changes. It's similar to having a system
preinstalled with a Tripwire like system.
This can be turned off by a system administrator but I can't
think why one would. As the system runs entirely locally, a very
knowledgeable intruder should be able to defeat it, but not
without considerable risk of triggering one or more alerts.
Turning the system off would stop these. There are enough checks,
that when you customize an OpenBSD system and tighten security,
it normally takes several days of tuning, to make all the
auditing system settings match the new system and thus stop
sending security related warning messages. Until the actual
system and auditing system are synchronized a new set of warnings
is sent each night.
Top of Page -
Copyright © 2000 - 2014 by George Shaffer. This material may be
distributed only subject to the terms and conditions set forth in
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