On Fri, Aug 9, 2013 at 5:05 PM, David Blanton <[email protected]> wrote: > Thank you very much. I ended up getting everything working. > > <decoder name="bnc3server"> > <program_name>^logger</program_name> > <prematch>^::\S+:\S+:\S+:</prematch> > <regex offset="after_prematch">^BNCServer not found on \S+: - couldn't open > socket: connection refused</regex>
I wouldn't ever do this myself. If you aren't going to be pulling any data out, a regex isn't necessary. Plus, I feel like the entire log message belongs in a rule instead of the decoder. > <order>extra_data</order> You don't have anything to put in extra_data (something in parentheses in the regex line). I wouldn't ever use this decoder. I think it tries to do too much and fails, for example if a log message from bnc3server that doesn't say "not found on" will not match this decoder. > </decoder> > > <rule id="100065" level="12"> > <decoded_as>bnc3server</decoded_as> > <match>connection refused</match> > <description> BNC Server or App has failed; connection/socket > refused</description> > </rule> > > So, for clarifications sake, after_prematch would be matching the log post > prematch, based on what event would occur. In order to > manipulate how the log actually looks after OSSEC fires it, I would have to > make a parent and child decoder with an after_parent regex. > Within the <order> for the child decoder, and after_parent, I can manipulate > the variables to prompt a different looking alert? That's how > I understood this example > http://www.ossec.net/doc/manual/rules-decoders/create-custom.html#create-a-custom-decoder > > I'm guessing this would be pertinent if, for example, I had an alert that > stated that a connection was accepted, refused, or undetermined? In which > case I could create 3 child decoders, and have 3 separate rules for each > state? Or could I have 1 parent and 1 child decoder, use the \w > variable, and have 3 rules to match for the which state the > socket/connection is in. > Given a line like: ERROR stuff happened: connection refused You could do something like (probably in a child decoder): <regex>^ERROR stuff happened: (\.*)$</regex> <order>status</order> Then in you rules you could use: <rule> ... <status>connection refused</status> If the status of a log event ended up being "connection accepted," this rule would not be triggered. > I hope I'm getting this right. > > -- > > --- > You received this message because you are subscribed to the Google Groups > "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
