Re: Debian audititing tool?
On 00-12-22 Peter Eckersley wrote:
> 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
And you are running the system with an unclean kernel? If you not add
your kernel that you are running to the tripwire check, you won't notice
if anyone puts a bad module or a modified kernel on your system.
> My suggested alternative is a system which knows about official Debian
> packages, and will register that change as simply "installed/upgraded
> package XYZ".
Where should it register that? What exactly should it register? Your
current description sounds like a system that just notes that package
foo has been instaleld and nothing else. This will still make it
possible to replace foo with an modified foo that allows someone to take
your machine over.
> > > 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.
No, as it would say that if this md5sums will be wide spread, someone
will write a tool to modify binaries without modifying the md5sum and
then you have the problem again or even create a tool that replaces the
md5sum in the file /var/lib/dpkg/info/package.md5sum with a new one, so
that debsum won't notice the difference.
> > > 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.
Well, but you still have to trust your mirror and their admins? So how
do you want to make sure that you can trust this mirror? Which
modifications of apt are you talking about? What exactly did they
modify? Did they change apt to not accept hostnames but only ip-address?
> A kernel source is "clean" when it has the Debian kernel maintainer's
> signature on it. A kernel binary is clean when the administrator:
Which signature? If you download a debian package there's no signature
on it that you could check. So how do you want to check a signature and
make sure that there's no poisoned kernel-source on your debian mirror?
> * gets a clean kernel source
> * compiles it, and records the md5sum of the kernel with the "security
> server" (or on a piece of paper).
Of the kernel? What do you mean with kernel? Only vmlinuz? Or also the
modules? Be more precise.
> > > * 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.
What do you define as "vanilla"? Also remeber that rootkits can change
and become more sophisticated in the future. And so you will also be in
a time lag behind the people having the rootkits as you first have to
get a copy of it to create a detection for it.
> 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.
So you really think that someone who will write such a tool will be able
to get acccess to all rootkits? I hope this is not meant serious.
> > > * 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'
Do I care about Windows machines?
> files" flag? Have you added /home to your /etc/updatedb PRUNEPATHS?
Yes, for machines, where I'm not the only user and admin in person, I do
this.
Ciao
Christian
Reply to: