Re: Debian audititing tool?
On 00-12-22 Peter Eckersley wrote:
> On Thu, Dec 21, 2000 at 02:33:32PM +0100, Christian Kurz wrote:
> > > 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.
> If you are willing to trust your Debian mirror (or perhaps you could
> even circumvent the mirror and go to .debian.org for signed checksums),
Where do you have a signed checksum on .debian.org?
> the audit tool will tell you "replaced foo with upgraded (official) foo
> version#", or "ALERT: foo does not match official checksums".
And how does it detect if the upgrade packageof official? Also the
second detection will be based on the assumption that the file
containing the checksum has not been replaced also.
> > > 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.
> I think we're agreeing with each other. I said "debsums is inadequate",
> you appear to be trying to explain this to me.
No, I tried to explain why it also won't work for the "less-careful"
intruders, as they will use tools to hide their changes.
> > > 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?
> Search for "mirror authentication". I'm not sure how they did it, but
Well, no documentation about this available on the URL.
> if I were trying to do mirror authentication, I'd ship apt with an
> official .debian.org public key, and then ask .debian.org whether a
> the public key presented by a mirror was kosher. There are other ways
> of doing it...
puiblic key? GnuPG or PGP? Or do you mean ssh or what kind of public key
do you think of? Also this would impose that everyone downloads package
from only one .debian.org server and this would generate a lot of
traffic and resources on this machine. Or otherwise you have to convince
every admin of .debian.org to generate a public key and install them all
when you install apt.
> > 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.
> I'm not claiming to have a solution for automatic rootkit detection. As
> I said in the original email, kernel (and module) scanning is just an
> extra feature which is not perfect, but which might help somebody one
> day. Of course, there will always be new or mutating rootkits (like
> there are new or mutating virii on Windows), but if any rootkit is in
> widespread use, it will be detectable.
And what about rootkits that are often used and not widespread but that
you don't detect really? I think that also such a rootkit is already
> * automatic recognition of changes to the snapshot which correspond to
> the installation of packages from /etc/apt/sources.list, possibly
> augmented by mirror authentication
You still failed to describe how you want to do automatic recognition of
Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser
und größer als ein "Ja" um zu gefallen oder noch schlimmer, um
Schwierigkeiten zu umgehen.
-- Mahatma Gandhi