Hello, Yes its in place currently, but not sure if its really caught much/anything.
Looking into it looks to be more that there also needs to be a catch in place in case the decoder doesn't match so that an alert can be sent for that also. Its worth knowing if something hasn't matched the decoder so I can create one for it rather than the message silently disappear... it might be very important. For example something like "Aug 10 09:00:03 hostname CRON[31237]: (root) CMD (/usr/sbin/ntpdate hostname)" Wasn't matched against a decoder according to my ossec-logtest... For PCI purposes I want to make use of ossec so i would therefore like to create an arsenal where if something isn't matched be be known good or bad that it gets alerted regardless. On this note also... did i read correctly somewhere that ossec checks against all rules of course after going through a decoder and then alerts on the highest level ruling? Or it just parses through the decoder as usual and then sequentially goes through the rule list after finding any match it will alert on that match first? Three primary questions:- - Would like to know how to make ossec catch and email on anything where a match hasn't been found - Do log messages pass through ossec in a sequential order, so lowest numbered/ID'd rules are checked against first? (my reasoning for giving my catch all rule such a high rule number in the hope this was the case and then means the catch all rule is hopefully evaluated last.) - Will each and every decoder set-up require a separate catch-all rule? Cheers, M > Date: Mon, 9 Aug 2010 17:00:18 -0400 > Subject: Re: [ossec-list] Central Remote Agent Configuration > From: [email protected] > To: [email protected] > > Have you tried it? > > On Mon, Aug 9, 2010 at 4:46 AM, Mark F <[email protected]> wrote: > > I would like to double check if this method of a catch-all will work > > however? > > <rule id="500000" level="3"> > > <match>*</match> > > <description>Catch All</description> > > </rule> > > Thanks all
