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 (pde@cs.mu.oz.au) http://www.cs.mu.oz.au/~pde for techno-leftie inspiration, take a look at http://www.computerbank.org.au/
Attachment:
pgpHhOKGywOc3.pgp
Description: PGP signature