Re: Common security checks for a base installation - packages reviewed.
On Fri, Dec 27, 2002 at 11:22:24PM +0100, Javier Fern?ndez-Sanguino Pe?a wrote:
> You've missed one of my personal favorites in Tiger:
Ahh, I spent less time looking at that than the others, knowing that you'd
step forward if my understanding was mistaken, or if I missed anything
important :)
I'm still looking at it at the moment, it's taking a while, because of
the large number of checks it's capable of.
> - Configuration checks for common programas (lilo, apache...)
I still think that the packages themselves should be capable of checking
their own setups.
That way things are always kept in sync, and the checksecurity doesn't
have to worry so much about updates. (It's very remeniscent of the
discussions we had upon this list recently about virus scanners; the
core package would be infrequently updated, but it's likely that the
signatures would have to be touched many times. It would seem to me
that this is a comparable situation).
> 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.
Ahh thats a fine default - but the same still goes for the other tools.
> Lsof is not that common BTW.
Hmm if it's an apt-get away, then it's simple to install. I've always
considered it a common tool regardless.
> Which package did you test? It should abort if a program is not
> found. Please contact me directly and tell me what happened).
Version in unstable - mailed a description of what I did to you.
> 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.
The reason I suggest perl is that many things can be done with it, and
the standard included modules which actually lowers the requirements.
For example detected open ports could be done in pure perl - without
having to worry about any installed `lsof`, or `netstat`.
Another big plus is that it's simpler to document than shell scripts,
and we get things like modularisation and functions which make things
easier to update and understand than the long shell scripts, such as
the OpenBSD checksecurity script - for example.
(I look after lots of systems and perl is installed upon them all, even
on the Windows client machines - maybe this is atypical, but I do tend to
assume that Perl is available even when bash isn't).
> 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.
True, but core perl installation installs lots of very useful modules,
which would almost certainly be sufficient. (I'm thinking that only
LWP and MD5/SHA modules would be needed for a security checking system).
> Why not the whole filesystem?
> You are also missing important /etc files such as inittab.
True, these were samples. I don't think checking the whole filesystem
for valid permissions is going to be worthwhile - but certainly all the files
in /etc/ should be tested for readability and writability by non-root users.
> > 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.
One thing that occurred to me as a first step the tool should traverse the
filesystem and create a database of all the files it finds:
name size ctime mtime atime user group perms
This way that database could be used for all subsequent operations, this
would minimise the number of times the filesystem itself had to be touched.
Traversing the filesystem should be avoided if possible; certainly it shouldnt
be necessary to walk it more than once.
(Hmmm, does locate/slocate store enough information in its database?)
> 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)
Yes I see that now.
> Ummm.... I wouldn't like to have a checksecurity script other
> packages tampered with.
I don't think that the core should be touched by anything else, however I
do think that other packages should be able to augment the checks - like
I said above I see no reason why apache shouldn't include a apache-specific
check in its package, rather than having one in the main package, ditto for
lilo.
(A lilo configuration could warn, for example, if there was a password set
and the file was world readable. This is a level of detail above that of
the checksecurity script - ditto for testing whether the lilo password was
the same as the root password).
> - the signatures function has not been updated for Debian (and many other
> new OSs)
Doesn't this suggest that apache/lilo/etc checks should be outwith the main
package - to ease the maintainence.
> - it doesn't use SHA-1, only MD5 (that could be fixed easily) for
> signatures checks
That's only a minor concern at the moment I guess.
> - the differentiated output which is used by cron to trim down reporting is
> a quick hack and needs a lot of improvement
I think this is partly a consequence of the implementation...
> - there is no possible alarm mechanism besides mail
That is a more serious concern. I had in my mind a plugable output system,
somewhat like that used by netsaint - for example:
* Mail
* Page
* Update a webpage/status page. (Hmm. test that it isn't world accessible, and protected via .htaccess too?)
* Stopping services as an extreme.
> - there are some points of failure I dislike: cron, mail and the log
> directory
Mail I think is excusable, and as for cron short of having a seperate
deamon you'd have to trust it.
> - using shell script instead of Perl, even if very portable, make it
> difficult to code some checks (or at least do it properly)
Perl++ ;)
> 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.
True.
> Umm... I wouldn't use Perl but that's just IMHO.
Any particular reasons other than that of availability?
> 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.
Thanks that's not a bad idea; I'll update what I previously wrote when I\ve
studied tiger some more and stick it online at the very least.
> PS: It would be nice if you could check the msec script from Mandrake
I shall add it to the list..
Steve
---
# Free Software. Piercing
http://www.steve.org.uk/
Reply to: