In article ,
Dave Hinz wrote:
On 7 Feb 2005 20:48:02 -0500, DoN. Nichols wrote:
[ ... ]
I'm not sure whether you want to lump me into that last
category, as I'm normally using Sun's Solaris and OpenBSD's unix, not
linux. :-)
How's OpenBSD? I've been using FreeBSD lately for my intel (and Mac,
obvously), and it seems very stable, and everything works. Bull****
and advocacy aside, any good reason to pick Open over Free?
That is a good question. I don't use FreeBSD, so I can't do a
true comparison, but OpenBSD is predicated on careful analysis of all of
the source code, and having only things which are *trusted* turned on in
the system as it installs. Things like sendmail (which is of
questionable security, just based on history, and which *must* run as
root) are run in a "chroot jail", so there are severe limitations on
what it can do to the rest of the system.
Also -- if you want to establish a truly hardened system as a
firewall -- start with "pf" (packet filter), which I understand that
FreeBSD has picked up from OpenBSD, get the system configured and
running as you want, and then set the bits using "chflags" (like chmod,
but it works on a different set of flags). You can set the following
flags on a file-by-file basis:
================================================== ====================
arch set the archived flag
opaque set the opaque flag (owner or superuser only)
nodump set the nodump flag (owner or superuser only)
sappnd set the system append-only flag (superuser only)
schg set the system immutable flag (superuser only)
uappnd set the user append-only flag (owner or superuser only)
uchg set the user immutable flag (owner or superuser only)
================================================== ====================
In particular, look at the last four, with "schg" and "sappnd" being the most
important. Once you have those set, edit the "/etc/rc.securelevel" file
to set "Securelevel" to a value of 1 (the default in mult-user mode) or greater.
Here is the man page for securelevel, so you can see just how
tight it can make a system.
================================================== ====================
SECURELEVEL(7) OpenBSD Reference Manual SECURELEVEL(7)
NAME
securelevel - securelevel and its effects
SYNOPSIS
The OpenBSD kernel provides four levels of system security:
-1 Permanently insecure mode
- init(8) will not attempt to raise the securelevel
- may only be set with sysctl(8) while the system is insecure
- otherwise identical to securelevel 0
0 Insecure mode
- used during bootstrapping and while the system is single-user
- all devices may be read or written subject to their permissions
- system file flags may be cleared
1 Secure mode
- default mode when system is multi-user
- securelevel may no longer be lowered except by init
- /dev/mem and /dev/kmem may not be written to
- raw disk devices of mounted file systems are read-only
- system immutable and append-only file flags may not be removed
- kernel modules may not be loaded or unloaded
- the fs.posix.setuid sysctl(8) variable may not be raised
- the net.inet.ip.sourceroute sysctl(8) variable may not be
raised
2 Highly secure mode
- all effects of securelevel 1
- raw disk devices are always read-only whether mounted or not
- settimeofday(2) and clock_settime(2) may not set the time back-
wards or close to overflow
- pfctl(8) may no longer alter filter or nat rules
- the ddb.console and ddb.panic sysctl(8) variables may not be
raised
DESCRIPTION
Securelevel provides convenient means of ``locking down'' a system to a
degree suited to its environment. It is normally set at boot via the
rc.securelevel(8) script, or the superuser may raise securelevel at any
time by modifying the kern.securelevel sysctl(8) variable. However, only
init(8) may lower it once the system has entered secure mode. A kernel
built with option INSECURE in the config file will default to permanently
insecure mode.
Highly secure mode may seem Draconian, but is intended as a last line of
defence should the superuser account be compromised. Its effects pre-
clude circumvention of file flags by direct modification of a raw disk
device, or erasure of a file system by means of newfs(8). Further, it
can limit the potential damage of a compromised ``firewall'' by prohibit-
ing the modification of packet filter rules. Preventing the system clock
from being set backwards aids in post-mortem analysis and helps ensure
the integrity of logs. Precision timekeeping is not affected because the
clock may still be slowed.
Because securelevel can be modified with the in-kernel debugger ddb(4), a
convenient means of locking it off (if present) is provided on highly se-
cure systems. This is accomplished by setting ddb.console and ddb.panic
to 0 with the sysctl(8) utility.
FILES
/etc/rc.securelevel commands that run before the security level changes
SEE ALSO
chflags(2), settimeofday(2), mem(4), options(4), init(8), rc(8),
sysctl(8)
HISTORY
The securelevel manual page first appeared in OpenBSD 2.6.
BUGS
The list of securelevel's effects may not be comprehensive.
OpenBSD 3.5 January 4, 2000 2
================================================== ====================
So -- you see that the combination of the immutable flags on
properly selected files and the securelevel make it very difficult for
the system to be modified without going to single-user mode -- which
means that anyone attacking from the net cannot get in while in
single-user mode. (That is -- all networking is turned off in that
mode.) Obviously, log files would only get the append-only flag, not
the immutable one.
But OpenBSD prides itself on the security of the default install
of the system. Yes -- you can do things to reduce the security of the
system, such as opting to not run apache in a chroot jail, and to not
run it in /var, which by default is mounted "nodev" and "nosuid", making
it more difficult to get out of the chroot jail.
I hope that this helps,
DoN.
--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. |
http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---