On Sat, Dec 28, 2002 at 09:50:01PM +0000, Steve Kemp wrote: > 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. I think tiger (8) lists most of them (if not all). I might not have documented some of the latest ones. > > - Configuration checks for common programas (lilo, apache...) > > I still think that the packages themselves should be capable of checking > their own setups. Not sure about this. It's like asking Apache to lock itself down instead of having Bastille do it. There are some issues which have to be taken a look in a broader context... > 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 (...) Probably. It's not easy to see, however, were should this functionality reside... > > > 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. You mean other checks (in Tiger)? The differentiated reports works for all checks. Regardless of what they do. > > > 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. Keep in mind that Tiger can also be used in non-Debian OS. In any case my statement was talking about these (not Debian). > > 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. (...) > > 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). Once again. My statement was talking about Tiger's need to be portable amongst non-Linux os too. > > > 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). > Probably. Yes. > 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 But were would the database reside? Memory? Disk? If the situation changes (a file is modified) after, say, running a test that takes 30 minutes to process the database then the next check might miss an important issue. > 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. > I do not necessarily agree here, however, that really depends on the load on the system after a filesystem traversal. If you are doing, say, 1 check per hour, I believe you _can_ afford having the check go through the file system. > (Hmmm, does locate/slocate store enough information in its database?) Not that I know of. > > 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. If you are using a shell/perl script that runs outside of a sandbox as root it can most certainly touch the core of the check-security test script. I'm thinking of having the check-security stuff separate unavailable even to root, for example, if you are running a SE-linux (or similar system). > (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). Yes. That's what /usr/lib/tiger/systems/Linux/2/check_lilo does precisely (save for the comparison betweeh lilo/root password which I don't see the reason for BTW) > > - 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. Errr ... no. This has nothing to do with apache/lilo, please read the README.signatures file to see how signatures work. It's kind of a snapshot of a known system (filepermissions and MD5 sums of a fresh Debian 3.0r1 installation for example) > > - 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... Not only. The 'difflogs' util is the culprit here ( /usr/lib/tiger/util/difflogs) it could be improved to remove some cruft that get mailed. Also, configuration options could be improved to remove even more cruft. > > > - 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. > I would say my preference in this are mail, syslog and snmp (only). Note that pages could be programmed through any of these. Syslog has the advantaged of being logged (mail can get lost) and can also be sent to a remote system which cannot be tampered with easily. Snmp provides integration with Network Management tools which could provide more effective alarm mechanisms (ticket integration, automatic response, or whatever) > > Umm... I wouldn't use Perl but that's just IMHO. > > Any particular reasons other than that of availability? The other one I have is system load. The perl interpreter is way more overhead than a shell script. This might not be an issue with big tests (going through all the filesystem) but probably is with small tests (just running nestat and looking the output). I believe I don't have anything in Perl to compare Tiger tests with, unless I re-coded all of them. If I were to rewrite Tiger I would do it in C better than Perl. Would take quite more time too. > > > PS: It would be nice if you could check the msec script from Mandrake > > I shall add it to the list.. See my previous post. I am taking a look into it and will extract the tests that are not already done by Tiger. Regards Javi
Attachment:
pgpD0JfsX3JwI.pgp
Description: PGP signature