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
system:
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"
problem.
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
it.
>
> > 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
administrator.
--
|> |= -+- |= |>
| |- | |- |\
Peter Eckersley
([EMAIL PROTECTED])
http://www.cs.mu.oz.au/~pde
for techno-leftie inspiration, take a look at
http://www.computerbank.org.au/
PGP signature
