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

Re: Debian audititing tool?

On Thu, Dec 21, 2000 at 01:39:19PM +0100, Christian Kurz wrote:
> On 00-12-21 Peter Eckersley wrote:
> > Basically, I started reading the tripwire documentation, stopped, and
> > thought "Debian ought to make this *much* simpler".  It seemed that if I
> > wanted to use tripwire, I'd need to tell it every time I was installing
> > a new package.  I'd then need to update a record on read-only media...
> Hm, looking at your statement above, I get the feeling that you have no
> idea, what the purpose of tripwire really is. If you use it without a
> read-only media to save the data too and rerunning it when you install
> software on the machine, it won't be very helpful to track an intrusion.

I understand the requirement for read-only media.  Tripwire should give
me a "clean" snapshot of a system.  But when I administer a machine, I
regularly make changes to the "clean" image.  If I want tripwire to
track this, I must do the following every time I want to update the

1.  Reboot with a clean kernel
2.  Run tripwire with my read-only record
3.  Install my Debian packages
4.  Update my read-only record

My suggested alternative is a system which knows about official Debian
packages, and will register that change as simply "installed/upgraded
package XYZ".

> > Debsums seems to help a little bit - you can expect to catch some
> > less-clueful intruders with it, but it doesn't help in general.
> debsums just uses md5sums which can be manipulated on the one hand and
> on the other hand you modify binaries so that the md5sum will still be
> the same. 

Hence my comment.  "Less-clueful" intruders won't modify
/var/lib/dpkg/info/package.md5sums ; debsums will catch these people,
but will not help if the cracker is smart.

> > What I'd really like is this:
> > A CDROM or boot floppy with a clean kernel, which downloads a set of clean
> > md5sums from a trusted server, and checks those.  It could then produce a list
> > of modified configuration files, which one would need to check by hand.
> So, how do you define clean kernel? Which kernel is really clean? How do
> you define if a server is trustable and how do you make sure that no one
> has put modified binaries on it?

Of course, at some point, you have to make a leap of faith.  ATM, most
Debian users trust their DNS server and their Debian mirror.  IIRC,
Connectiva's modifications to apt-get will fix the "trust your DNS"

A kernel source is "clean" when it has the Debian kernel maintainer's
signature on it.  A kernel binary is clean when the administrator:

* reboots the machine and uses the hypothetical auditing tool
* gets a clean kernel source
* compiles it, and records the md5sum of the kernel with the "security
  server" (or on a piece of paper).

> > * Kernel "trojan scans" for all known nasty kernel code.
> How do you want to do this with a source that is about 117M big? You
> have any idea how long it will take? Also you could hide nasty code very
> good in it and which will be hard to catch (This is an assumption by
> myself, after having looked at some parts of the kernel-source.)

This service is not perfect, that needs to be made clear.  However, it
is reasonable to state that a large fraction of break-ins will use a
"vanilla" rootkit, which might be detected even if the administrator
*hasn't* recorded the custom kernel's checksum.

As new rootkits are observed "in the wild" (and a tool like this might
help find them :), they can be added to the list of trojan signatures.
This is closely analogous to the operation of virus scanners in M$ land.

> > * Debian security servers - these could keep a record of which config file
> > 	changes you've okayed.  They might also allow you to checksum customised
> What? Mirrors worldwide for your config-files? Use tripwire and you
> don't need this.
> > * Heuristic analysis scripts to look for funny things in users' home
> >   directories, such as SETUID stuff and questionable aliases in .bashrc, for
> > 	example (although this can never be perfect).
> You want to scan user-dirs without telling them that you do this? In
> Germany you would better be careful with that as otherwise you could go
> into jail for doing this. Please think about respecting the privacy of
> your users.

Do Windows sysadmins run their virus scanners with an "ignore users'
files" flag?  Have you added /home to your /etc/updatedb PRUNEPATHS?

I am proposing the creation of a tool.  Like any other tool, it might be
abusable (not nearly as abusable as nmap, I might add).  If using it in
a particular way on a particular machine is inappropriate, then don't do

> > Does a tool like this exist already?  If not, what do people think of the idea?
> No and I think on the one hand you have bit to much paranoia (Do you
> have two entrance doors, grilled windows. a complete list of everything
> in your house/flat in a safe by a lawyer? If no, I would suggest that
> you think about your ideas again.) and on the other hand you seem to
> have missed the idea behind tools like tripwire.

Well, if I have misunderstood tripwire, you haven't managed to explain
to me how I've misunderstood it.

As for the question of paranoia... well... I hope you're not a systems


|> |= -+- |= |>
|  |-  |  |- |\

Peter Eckersley
for techno-leftie inspiration, take a look at

Attachment: pgpHhOKGywOc3.pgp
Description: PGP signature

Reply to: