Re: rootkit and trojan hunting

["\"Zow\" Terry Brugger" <zow () acm org>]

>  >  Don't reinvent the wheel -- just use Tripwire.
>  >  http://sourceforge.net/projects/tripwire/ for the open source version,
>
>  (sigh) What about learning?
>
>  "Give a man a fish and you feed him for a day. Teach a man to fish and
>  you feed him for a lifetime." Chinese Proverb

I can't resist the retort: "Build a man a fire, you keep him warm for
a day. Set a man on fire and you keep him warm for the rest of his
life."

Seriously though, I will grant you the educational value of doing
something yourself, but in the security space, a lesson that is best
not learned the hard way is that building security software is hard.
Security critical software can be attacked in a lot of ways, and a
mature, well-known product has hopefully already addressed them. This
is usually most easily observed in the crypto space where someone
thinks they've come up with a great new way to encrypt data, but in
fact it's vulnerable to a attack that was well understood by
professional cryptographers years ago. Even developers who know what
they're doing make mistakes and we continue to find vulnerabilities in
mature products, as evidenced by the traffic on Bugtraq. One only
needs to read a couple issues of RISKS digest and CryptoGram to
understand this. The last thing I would want to see is this
enterprising programmer putting together this system, deploying it,
and then thinking they're safe; although, I will grant you that unless
an attacker had a particular interest in the system at hand, it's not
likely they'll think to look for and disable a custom-built integrity
verification system.

There are two other general reasons that I don't like seeing people
reinventing the wheel (not specific to security software), and one
more reason specific to learning settings:
1. it creates more wheels,
2. it dilutes effort across numerous systems rather than making one or
two systems very good, and
3. building software from scratch is a less valuable skill than being
able to fix, extend, and integrate software written by others.

The first is self explanatory to anyone who has ever wanted to add
some functionality to a Debian box -- be it a word processor or a new
window manager (both examples from real experience in the very recent
past). Which one to choose? Now, I understand the political or
technical reasons that cause code bases to fork, but it seems that
more often developers are too lazy to try to understand someone else's
code or unwilling to make an effort to work together, and we end up
with a massive duplication of effort. This duplication of effort is
particularly unfortunate if it could instead be used to make any one
of these systems better. (Is a decent open source WYSIWYG word
processor too much to ask for?) Now granted, both of these reasons are
really tilted heavily towards open source development, because if a
company tries to create a competing product, then they should know if
they're going to be attracting customers on price, features, or
something else (marketing, monopolistic business practices, etc). As I
recall, AIDE was created before the open source version of Tripwire,
and was probably largely responsible for Tripwire putting out an open
source version. All the other suggestions made so far are worth
looking at as they all provide different functionality from each
other.

The final point is one that's come more from experience. I'm not
saying that writing code from scratch is not a worthwhile skill, just
that being able to work within code others have written has proven to
be a valuable skill in my career -- one that's not shared with all
developers, and has pretty much been self taught, as my undergraduate
education actively discouraged it, and while my graduate coursework
didn't discourage, it didn't do anything to encourage it either.

All that said, I read Return C's original request as, "This seems like
a good idea, so I'm coding it up to protect my servers. What do all of
you think I can do to make it better?". Now, if they actually meant it
as, "I've heard this is an approach, and I'd like to code it up myself
to see what's involved. What do all of you think I should try or watch
out for?" Then I think that's great, and this forum will probably be
well served by a discussion of integrity checking approaches for
intrusion detection. I'll even start it off:
How do you protect the hashes? Tripwire 1 required that you put them
on WORM (Write Once, Read Many) or write-protected media. Tripwire 2
uses public key crypto to sign the hashes. While both approaches work,
neither has seemed particularly elegant, particularly as they require
a human in the loop, which makes system updates or managing large
groups of systems more labor intensive. I believe "Tripwire
Enterprise" adds features to ease these management issues in large
environments, but ultimately, it's just adding more layers to hide the
underlying issue. Any ideas how it could be better handled, perhaps by
leveraging kernel extensions such as LIDS or SELinux?

Cheers,
Terry

------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it 
with real-world attacks from CORE IMPACT.
Go to http://www.coresecurity.com/index.php5?module=Form&action=impact&campaign=intro_sfw 
to learn more.
------------------------------------------------------------------------