Re: rootkit and trojan hunting

["Return C" <return.c () gmail com>]

Hi Terry,
             I appreciate your valuable comments. One thing I forgot
to tell in my previous post is that, I solely develop this tool for
academic purpose and nothing to make it like Tripwire or so and so
softwares. I always enjoy coding in Linux and C and try to learn new
things by coding myself rather installing a tool and learning it.
Offcourse, I do read a lot about techniques and other tools in
security space, to keep my knowledge up to date. This is purely for my
personal interest. Also I love to devel tools which would be helpful
for sysadmins and security pro's as well. Like I used to develop worm
removal tools in Win32. Thank you all once again.

return C;


On Thu, Mar 27, 2008 at 10:56 PM, Zow Terry Brugger <zow () acm org> wrote:
> >  >  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.
------------------------------------------------------------------------