Re: [OT?] Replacing hacked binaries
On Sat, Dec 02, 2000 at 01:21:29AM +0100, Jan Martin Mathiassen wrote:
> 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)...
Using tripwire data (or any other sort of comparison) to decide that a system
has been restored to a known state is a very dangerous approach, even with an
external read-only database. Tripwire is meant to work like its namesake, to
alert you of a possible problem. It does not do sufficient auditing to make
any assurances about whether a compromised system has been cleaned. Once an
attacker has root access to a system, every mutable bit on the system becomes
suspect. What if a rogue MBR has been installed? This is easy to do, and
everything in the kernel and filesystem will check out.
A complete reinstall from known good media is the only way to have any peace of
mind. If the system has been kept clean, it really isn't that much work. The
only human work is to compare configuration files, authorized_keys and such
with offline backup copies to catch any malicious changes. Once you've done
that, you only have to worry about trojans lurking in system firmware.