Hi Brenden, In your initial rule, the match syntax was wrong:
<match>ossec: output: 'wget -o /dev/null -O - http\//www.unruleable.org/blog/ | sha1sum'</match> OSSEC was actually looking for the string sha1sum OR the command output name ( | sha1sum we treat as a separator). As for the key, we use the rule id as the storage key, so you would need a different rule for each one of those sites. thanks, -- Daniel B. Cid http://dcid.me On Fri, Dec 7, 2012 at 2:47 PM, Brenden Walker <[email protected]> wrote: > On Fri, 7 Dec 2012 13:18:33 -0500 "dan (ddp)" <[email protected]> wrote: >> On Fri, Dec 7, 2012 at 12:47 PM, Brenden Walker >> <[email protected]> wrote: >> > On Fri, 7 Dec 2012 12:31:24 -0500 "dan (ddp)" <[email protected]> >> > wrote: >> >> On Fri, Dec 7, 2012 at 12:22 PM, Brenden Walker >> >> <[email protected]> wrote: >> >> > I'm trying to monitor a few websites for changes, I followed some >> >> > examples online other than needing to change http:\\ to http/\\ >> >> > in the match (that's how it appears in archives.log): >> >> > >> >> > >> >> > Added to ossec.conf >> >> > >> >> > <localfile> >> >> > <log_format>full_command</log_format> >> >> > <command>wget -o /dev/null -O - http://www.poxodd.com | >> >> > sha1sum</command> <frequency>7200</frequency> >> >> > </localfile> >> >> > <localfile> >> >> > <log_format>full_command</log_format> >> >> > <command>wget -o /dev/null -O - >> >> > http://www.unruleable.org/blog/ | sha1sum</command> >> >> > <frequency>7200</frequency> </localfile> >> >> > >> >> >> >> Use <alias>es to better differentiate between these commands. >> > >> > Figures I was missing something simple. Any idea how ossec >> > differentiates these? When I changed my config to a call to >> > checksites.sh I got this: >> > >> > Received From: goonsquad->/opt/ossec/checksites.sh >> > Rule: 150013 fired (level 10) -> "Website change detected" >> > Portion of the log(s): >> > >> > ossec: output: '/opt/ossec/checksites.sh': >> > www.poxodd.com >> > 9506ac8e36f9727c2567d7ee90d117cb557b24d9 - >> > www.unruleable.org/blog/ >> > 81ddc99e3c2ee60518a3b219f561117185284bf0 - >> > www.diablops.com >> > 83626f4b502af0e55329cc6634078b6bf7ca2443 - >> > gta.diablps.com >> > 68e498cf5f10bef32d8fc0a0b4e9ffbc79832861 - >> > Previous output: >> > ossec: output: 'wget -o /dev/null -O - http\//gta.diablops.com | >> > sha1sum': 58aaa26e0e263ced83260b07abba280b84d3df39 - >> > >> > >> > Which leads me to believe that an alias is required for command >> > output entries, otherwise they'd all get muddled up?? >> >> I'm fighting a horrible headache at the moment, so I'm probably >> missing something simple here. >> >> Originally you had 3 commands, all of them the same except for a small >> bit. Since the differences were deep enough into the command the >> output was getting mixed up. So did adding an alias to each of those >> commands help? >> >> When the commands aren't basically the same they don't get mixed up. I >> personally think aliases make things easier, so I always use them. > > > I changed the discreet command checks into a single call to a shell script. > AND aliased it (I agree, good idea there). I figured that it would be better > this way as I can simply add a site to the check script (sure it'll give me > an initial alert when I change, but that's good). > > What I find weird is that it compared the previous output from this no longer > existing <localfile> section: > > <localfile> > <log_format>full_command</log_format> > <command>wget -o /dev/null -O - http://www.poxodd.com | > sha1sum</command> <frequency>7200</frequency> > <frequency>7200</frequency> > </localfile> > > With this new and completely un-related <localfile> section: > > <localfile> > <alias>web_modifications</alias> > <log_format>full_command</log_format> > <command>/opt/ossec/checksites.sh</command> > <frequency>7200</frequency> > </localfile> > > > I removed the per site <localfile> sections. What I can't figure out is what > ossec is using as a key to previous command output? It's certainly using > nothing in the <command> section as these two have nothing in common there. > Which is why I suspect that alias is really required, or this is a simple bug. > >
