Common security checks for a base installation - packages reviewed.
I've had a look over three difference security checking packages,
to see what they do, and whether they would be appropriate for
Debianization - to replace or augment the 'checksecurity' package.
The things I examined were:
1. The SuSE seccheck package [1]
2. The OpenBSD checksecurity script [2]
3. The tiger scripts [3]
Each of these scripts, or collections of scripts tests a collection
of different things, and can be setup to mail the root user any
oddities, or deviations from the norm.
Most of these checks a very straightforward:
* Checking the /etc/passwd file to make sure there are no
entries with unset passwords, or duplicate UIDs.
* Testing the shadow password file for the same thing.
* Testing the /etc/group file.
* Making sure that home directories are only readable by
the correct UID/GID
* Checking the ownership/writability of dotfiles within
home areas.
* Checking permissions of mail spools.
Some of these tests are things that could be directly applied
to Debian machines, others are a little tricker. (I seem to
remember that it was a debconf question whether home directories
were world-readable?)
Other 'tests' don't actually test things, instead they will dump
a list of loaded kernel modules, or report upon all the ports which
are listening.
Personally I'd like to recieve no email in the general case, just
alerts when things go bad, or things look suspicious, so I'd not be
interested in a daily list of ports being open - perhaps a list of
the differences between the previous run would be sufficient?
(Getting a daily email from 20+ machines with a big list of port
numbers would probably let me switch off; and stop paying attention
to the reports).
seccheck
--------
This is the offering from SuSE it is based upon the OpenBSD
checksecurity script.
This package is broken down into several cronjobs, which run on
a daily, weekly, or monthly basis. Each job is written using /bin/sh,
and appears to be rather uncommented but portable.
(It requires 'lsof' 'pidof' and several other common binaries).
checksecurity
-------------
This is the OpenBSD effort.
I'm not 100% sure how this is called, I'll assume daily unless informed
otherwise.
This is a *nasty* long shellscript, which I found hard to read.
(OK that's a little exaguration, but it's not pretty).
This script has a habbit of producing output even when things are OK,
which I wouldn't want - I'd reserve some sort of VERBOSE flag for that
for the paranoid types.
tiger
-----
Lots of scripts.
The dependencies weren't setup appropriately for the package I downloaded,
it aborted on it's first run because it couldn't find 'lsof'.
The scripts themselves are fairly well written, in /bin/sh.
Suggestions
-----------
Looking at the tests which the different systems have in common there
are some very good ones which make sense - testing the password file for
duplicate entries, etc.
My personal list of requirements would look something like this:
* Uses the minimum resources necessary - not recursing through the
file tree multiple times.
* Quiet by default - only sending email if there is something to
complain about, or notify.
* Minimal dependancies upon external tools.
* Ideally it would be written in Perl, not /bin/sh ;)
* Simple to tweak, via a configuration file.
The Tests
---------
The tests that a security package should provide:
* Testing for appropriate permissions upon :
/etc/logrotate.d/
/etc/init.d/
/tmp
/var/spool/mail/
/var/tmp
/var/spool/cron
/etc/{ cron.d cron.daily cron.weekly cron.monthly }
* Testing for empty password, and duplicate UIDs.
* Testing for weak passwords. (Only really weak attempts for example,
password == username - more sophistication I'd leave to john/crack).
* Flagging users who've never logged in.
* Flagging users with writable files in their home area:
.profile
.bashrc
.bash_profile
.vimrc
.exrc
.emacs
.gdbrc
.forward
... etc.
* Testing for writable .ssh directories, and readable private keys.
* Testing for .rhosts, and .shosts files.
* Any changes in setuid files since the last invokation.
* Changes in filesystems/mounts.
* Testing for a filesystem above 95% fullness.
The information needed to be kept between invokations would be stored
in /var/cache/checksecurity - and the logfiles would always go to
/var/log/checksecurity, regardless of whether a mailing was going to
happen.
What now?
---------
Well the first thing to do is to think about the tests which the
packages already support, and then add in any other potentially
useful additional tests.
In addition to this all the tests must be configurable, so that
an admin for whom a particular test isn't relevent can just
disable this one test without having to either remove the package,
or hack the code.
Finally it would be nice if the testing framework were extensible
enough that other packages could add their own tests - in a similar
manner to how the lockcheck-database allows other packages to define
their own patterns. (Something like a magic directory,
/etc/security-check.d/ into which packages could install files).
Of the available options Tiger would be a good candidate for
selection, it's much more extensible than the other scripts, and there
are clear lines of seperation and a good configuration file. However
I've not looked at it as much as the other two packages, so I may have
missed some of the downsides.
If it were up to me I'd first build up a list of tests, then code
a simple wrapper/calling program in perl - and go from there...
.. I hope this was interesting/useful to some ..
Steve
---
[1] SuSE seccheck package licensed under the GPL
http://www.suse.de/~marc/seccheck-2.0.tar.gz
[2] The OpenBSD checksecurity script.
http://www.openbsd.org/cgi-bin/cvsweb/src/etc/security?rev=1.54&content-type=text/x-cvsweb-markup
[3] The Tiger system checking scripts.
http://packages.debian.org/tiger
Reply to: