Re: Common (basic) security checks for a base installation? (was Re: Security notification script in Perl)
On Thu, Dec 26, 2002 at 03:32:27PM +0100, Javier Fern?ndez-Sanguino Pe?a wrote:
> I believe we are starting to have (in the distribution) too many
> "simple standalone tests" (I am also to blame here)
I guess that could be true, but it's also the case that different systems
may not need/require all the different tests. Some tests which require
internet connections, for example, aren't going to be appropriate for
dialup/home users. (I guess it could be argued that these people are at
lower risk anyway).
> There are some things that won't work or are not
> appropiate (password check: done by 'john' already , rpm check).
> Aside for that I guess it can be useful. I have, as a matter of fact,
> included some of the tests to Tiger (some were already there). Check out,
> for example, check_neverlogin:
I'm just in the process of looking over the tiger package, it looks nice.
I actually approached the login checks from another angle, what happens when
you see people login from multiple locations? Theres a simple tool `locations` which will allow you to keep an eye on this here:
(This should also be cron'd up I guess).
> > Signing packages and releases is a whole other issue. It's not a great
> > idea to verify sums of packages against a local database, as it would be
> > trivial to replace the local database.
> You mistook me. The MD5sums is for _installed_ files, not for
> package installation, that's a different issue (and a beaten horse). As for
> attacks to system integrity these are all well known. Even if an attack is
> possible (which might not be if you store in RO media, or use proper
> capabilities access to prevent even root from tampering them) it is still
> good to have a local database.
> Tiger checks the database the same way debsums does, the problem
> here is that MD5sums are not mandatory for packages (and dpkg does not
> generate them even if there are some quick hacks to do this).
> In order to properly check integrity it might be useful to have
> MD5/SHA1 sums _and_ filesystem permissions. It's not only useful to recover
> from a security incident, it's also useful to recover from unknowledgeable
> admin users (try a chmod -R 000 /usr and see if you can -easily- recover
> the system)
True I guess. But already rootkits remove all the logfiles they can
find, it would seem to be a trivial modification to remove the md5sums
files too - or update them. This is only going to be foolproof if the
sums are stored on a WORM media, which is going to be atypical at best.
Having the sums checked is a good thing, but I'd worry that they might
give a false sense of security.
Storing file permissions, though, is a great idea and something that I
would love to see. These permissions could be checked upon a nightly basis
along with the setuid changes - if nothing else.
I think that a simple database system package could be installed to do
these things, much like `tripwire` or the other free checkers - until
dpkg itself could be coerced into storing the information when installing
> Try to remove your libc and see your system explode :)
True. I've even done this by accident once on a RedHat box. *ouch*
> Keeping a copy in a backup storage are of critical system files is
> IMHO a good thing. Automatic restoration needs to be handled carefully, but
> still, it's a worthwhile goal.
> Cron is a single point of failure for Tiger (as is the MTA). Kill
> cron and you've finished with all security checks. Since cron does not
> necesarily say anything unless there is a problem, an admin might be
> blissfully think all is working fine :)
True .. personally cron failure on any of my servers would be a catastrophic
failure, backups wouldn't happen, log rotation wouldn't happen, etc.
I'd notice very quickly because I'd stop receiving emails - but short of
having an email sent every day "cron is still working", or having a cron-watching
deamon this is something that would be hard to tackle.
> Not really. System integrity is one thing, system
> security monitoring is another (different) one. Both have overlapped areas
> but logcheck (which does a great job BTW) does not fit into what I was
> thinking of.
I was suggesting that logcheck could be used to check that normal things
like cron were working, rather than checking the logfiles itself.
> It would be nice, however, if, in order to determine what should Debian
> provide as a 'standard security check' you could compare Tiger checks
> against SuSE's checksecurity and against OpenBSD's (I believe the last to,
> do the same stuff) and against RedHat's (I believe they have one but have
> not seen the sources of it). (Any other's?)
I will compare the systems and report back in a couple of days.