[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:
> http://savannah.nongnu.org/cgi-bin/viewcvs/tiger/tiger/systems/Linux/2/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.


Reply to: