IDS mailing list archives
Re: rootkit and trojan hunting
From: "\"Zow\" Terry Brugger" <zow () acm org>
Date: Thu, 27 Mar 2008 10:26:24 -0700
> 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. ------------------------------------------------------------------------
Current thread:
- rootkit and trojan hunting Return C (Mar 26)
- Re: rootkit and trojan hunting "Zow" Terry Brugger (Mar 26)
- Re: rootkit and trojan hunting Jeff D (Mar 26)
- Re: rootkit and trojan hunting Nuno Treez (Mar 28)
- Re: rootkit and trojan hunting "Zow" Terry Brugger (Mar 28)
- Re: rootkit and trojan hunting Return C (Mar 28)
- Re: rootkit and trojan hunting "Zow" Terry Brugger (Mar 28)
- Re: rootkit and trojan hunting "Zow" Terry Brugger (Mar 26)