|Main Archive Page > Month Archives > focus-ids archives|
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.
On Thu, Mar 27, 2008 at 10:56 PM, Zow Terry Brugger <email@example.com> 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
> 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
> 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?
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.