On Fri, Dec 27, 2002 at 01:23:06AM +0000, Steve Kemp wrote:
>
>
> I've had a look over three difference security checking packages,
(...)
>
> 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.
(...)
>
> 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.
You've missed one of my personal favorites in Tiger:
- MD5 sums of files and permissions (based on 'signatures' of releases)
- Checks of package versions against a list of all published DSAs
(Debian-only)
- Configuration checks for common programas (lilo, apache...)
> 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).
You've missed one of the interesting thing about Tiger:
differentiated reports (see the README.hostids file that explains the
behaviour). Basicly Tiger will report _only once_ the open ports of any
given system, it does this by comparing each run done through the cron task
to the previous run (or a template) of each of the tests.
> seccheck
> --------
(..)
> (It requires 'lsof' 'pidof' and several other common binaries).
Lsof is not that common BTW. And netstat can do the same job in some cases
(the Tiger test script for open ports in Linux can use both)
> checksecurity
> -------------
>
> This is the OpenBSD effort.
(..)
> This is a *nasty* long shellscript, which I found hard to read.
> (OK that's a little exaguration, but it's not pretty).
/me too
(...)
> 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'.
Which package did you test? It should abort if a program is not
found. Please contact me directly and tell me what happened).
> The scripts themselves are fairly well written, in /bin/sh.
Also, _all_ the tests done by OpenBSD/Seccheck are already in (save
those that are already done by john/tripwire)
> Suggestions
> -----------
(..)
> 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.
Yes. That's one of the things I haven't (yet) gotten Tiger to do
perfectly.
> * Minimal dependancies upon external tools.
> * Ideally it would be written in Perl, not /bin/sh ;)
That kind of contradicts the previous one. One of the good things
about Tiger is that you can take the scripts to _any_ Unix system and 90%
of them will work out of the box. Of course, this portability is not
necessary in Debian since 'perl' will be installed by default.
However, I'm a Perl programmer too and I tend to use modules
whenever they are available. This (not so uncommon) habit, in the long run,
makes a program depend on quite a lot of packages in Debian.
> * Simple to tweak, via a configuration file.
Agreed.
> 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 }
Why not the whole filesystem?
You are also missing important /etc files such as inittab.
> * 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:
(..)
> * 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.
Agreed.
>
> 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.
Yes. That's a good approach.
> 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.
Just FYI this is done in Tiger through the Tigerrc configuration
(when you run the full 'tiger' program) or through the cronrrc file (which
tells cron which tests to run and at what times)
> 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).
Ummm.... I wouldn't like to have a checksecurity script other
packages tampered with.
>
> 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.
>
There are quite some downsides to tiger:
- the signatures function has not been updated for Debian (and many other
new OSs)
- it doesn't use SHA-1, only MD5 (that could be fixed easily) for
signatures checks
- the differentiated output which is used by cron to trim down reporting is
a quick hack and needs a lot of improvement
- there is no possible alarm mechanism besides mail
- there are some points of failure I dislike: cron, mail and the log
directory
- using shell script instead of Perl, even if very portable, make it
difficult to code some checks (or at least do it properly)
I can think of some more but I'll let you look into it. In any case
some of the downsides are not only specific to Tiger.
> 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...
>
Umm... I wouldn't use Perl but that's just IMHO.
> .. I hope this was interesting/useful to some ..
>
It was, quite a lot, for me. As a matter of fact I think that this
could be a pretty good article for linuxsecurity.com if you detailed it
further on.
Regards
Javi
PS: It would be nice if you could check the msec script from Mandrake
Attachment:
pgpswob9prH0Z.pgp
Description: PGP signature