|JP Vossen on 24 Feb 2012 12:07:18 -0800|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: [PLUG] Hacked server - recovery|
Date: Fri, 24 Feb 2012 10:45:04 -0500 From: Fred Stluka<email@example.com>
Is there any advantage of fcheck over tripwire?
Pros and cons. IMO, fcheck is a *heck* of a lot easier and faster to set up so it removes a lot of the "that's a time-consuming, tedious pain so I'll do it later" inertia. OTOH, it is arguably less secure than some alternatives. In theory I agree, but in practice, having something (fcheck) is hugely better than having nothing (I'll install Osiris Real Soon Now).
Please go read the 3 slides in my preso, they have a bit more info like this.
Also, logcheck over logwatch?
The goal is the same. I haven't used logwatch, but I *think* the way it works is to look for stuff it knows and report that. Can anyone correct me?
Having said that, logcheck will blacklist known good stuff and tell you about the rest, while I think logwatch will only tell you about its whitelist. Think about that for a sec, because in this context a blacklist is good and a whitelist is bad.
Logcheck (http://www.logcheck.org/), on the other hand, is the application of a concept that I also call "logcheck" for lack of a better name. My introduction to the concept was from Marcus Ranum and Fred Avolio's 'frequentcheck.sh' for TIS Gauntlet, way back when. See also my old Windows port of this: http://www.jpsdomain.org/windows/winlogcheck.html. And I've yammered on about this before: http://lists.netisland.net/archives/plug/plug-2009-03/msg00190.html.
The concept is simple. Given some data (e.g., a log file): 1.1) Remove stuff you know you don't care about1.2) Look for things you know you do care about, but then remove things you don't care about (false positives)
You then get output in two parts: 2,1) Stuff you don't know about 2.2) Stuff that is known to be badOver time, you "tune" the #x.1 "stuff you know you don't care about" list so you end up with only "known bad" output...until something novel happens or upstream changes or adds log messages.
Do you see how simple yet awesome that is? I can't say it's "self tuning" since--hey, you have to write the egrep regular expressions yourself, though if you 'grep' for stuff you can already do that and there are lots of examples. You never have to audit it to see what it might be missing, it just evolves with your environment very organically and seamlessly.
The tricky part for doing this for a growing log file is to not miss anything and no do repeats and there is a 'logtail' tool for that. It's a lot easier to do on a flat file after a complex build or other verbose process has completed. I do this a *lot* and it's great. There's a trivial 'egrep' implementation in my Windows logcheck port above.
I'd do a PLUG preso on this, but it's only about 10-20 mins... I've also wanted to do a wikipedia article on it, I just never get to that.
Later, JP ----------------------------|:::======|------------------------------- JP Vossen, CISSP |:::======| http://bashcookbook.com/ My Account, My Opinions |=========| http://www.jpsdomain.org/ ----------------------------|=========|------------------------------- "Microsoft Tax" = the additional hardware & yearly fees for the add-on software required to protect Windows from its own poorly designed and implemented self, while the overhead incidentally flattens Moore's Law. ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug