RE: [OT?] Replacing hacked binaries
first off, i'd like to apologize for posting the predecessor to the wrong
list. it was supposed to go to debian-security, not debian-devel. i need to
start reading headers... :)
> On Fri, 1 Dec 2000, Jan Martin Mathiassen wrote:
> Hi Jan,
>
> Just to compare with what's possible on an rpm-using distribution,
> rpm stores md5 checksums of all files from all packages in its database.
> If you have a known clean version of this database (possibly from
removable
> media), you can boot from floppy, drop the clean database back on the
drive,
> and use a known good copy of rpm (again from the floppy) to verify what's
> changed. When you have a machine that's taken a lot of coddling to get
> everything installed just the way you want it, taking the machine off-line
> for a few hours to do this can be a lot easier than a reinstall, and if
done
> with care can be just as effective at cleaning up after a break-in.
hmm. this is interesting news. redhat doing something security-minded?
*gasp* :)
okay, gay distro jokes aside, this is a nice feature to have, but that
doesn't really solve the problem at hand. if your box is hacked, the hacker
can insert files into your runlevel structure, he can enable anonymous
access on your FTP site (if any), etc etc etc. there are just so many things
that can be done that a reinstall just won't fix, especially if you've spent
a lot of time tuning the setups... you won't throw them out just like that,
now would you? which means, you reinstall everything, but you probably leave
the setups alone... which means the hole is still there.. or there's a rogue
executable lying about.
if you want to know what was changed, you use tripwire (well, everyone
should do that anyway). that util shows changed, deleted, added, etc... the
usual shit. of course, the database will have to be kept off of the box in
question (since, again, tripwire could be re-run to cover up his tracks)...
> Whether or not this is a desirable feature to have in Debian, I don't
know.
> But I do think it should be said that even though this method isn't for
just
> anyone, it IS possible to clean up a compromised machine without having to
> wipe it out...
of course, it *is* possible, but still... you *know* someone hacked your
computer, and you *know* they left a backdoor. but do you know if you found
*all* of them? unless you're running tripwire, no, and even then they can
leave backdoors somewhere tripwire isn't watching (imagine monitoring
/var/log... :).
heck, i've even reinstalled my box because it crashed funny (couldn't log in
remotely OR locally... and the logs didn't even show the usual --MARK--
entry). THAT is probably going a bit far, but it coincided with a harddisk
upgrade, so it was a case of nice timing, but still... i can rest assured
that the install i have on my gateway is the way *I* set it up, and there
are *no* backdoors. all i did was take backup of a few config files and
/home dirs, audited those for changed conf files and odd executables, clean
it all out, reinstall, and put the conf files and home dirs back.
the main issue i'm trying to point out here is, configs, homedirs and trust
are the important part of a linux install. that's where all the hard work
lie. that's where the differences between linux systems are. the rest of it
is just bog-standard, and can easily be replaced at the blink of an eye. i
mean, a normal debian install here takes what? 45 minutes (including kernel
compile... on a p200 :). compare that to several hours, maybe DAYS spent
comparing, wondering and worrying.
returning to your initial idea (just to make this post fit in on devel :),
what if we were to extend that idea, and add md5 sums to every file in a
.deb, so we could use dpkg to check the validity of a package by doing
dpkg --validate <moo>?
> Steve Langasek
> postmodern programmer
-m
When you are having a bad day, and it seems like everybody is trying to piss
you off, remember that it takes 42 muscles to produce a frown, but only 4
muscles to work the trigger of a good sniper rifle.
Reply to: