>That's a bad way to go about it. I tested this by recreating the rule > >in local_rules.xml and adding the overwrite option. > > I totally agree, I modded the rule because I'm testing on a VM that I'll snapshot back to a clean state once I'm done. I was short on time and wanted to confirm I wasn't screwing up :D
> > > >I see the same thing, no idea why. Instead of breaking rule 4101 I > >created a new rule looking for TEST. It's possible there's something > >in the firewall code path making this happen. Before I consider > >digging into it, what's the real world application of the TEST action? > >Is it worth caring about? (I'd suspect you'd need to mess with > >src/analysis/alerts/log.c, specifically the case after " /* Setting > >the actions */") > The test action was just to confirm OSSEC somehow only works with "DROP" and nothing else. In our prod environment we use iptables with the following log suffixes: "[UFW: CatchAll]: " "[UFW: ILEGAL PKT]: " "[UFW: ChainFilter]: " "[UFW: SCAN]: " Generally speaking the current code will only allow us to work with rules that specifically state DROP as action so it makes it difficult to work with log entries that don't use that log prefix. In our case all of our local rules that feed off rule # 4100 are failing to fire because they expect specific actions and frequency hits. I'll check src/analysis/alerts/log.c but I have zip experience with that language. Its taken me a month to get ossec2snorby.pl working and its made up of simplistic changes :( but it doesnt hurt to try. Thanks for the info thus far Dan. -- --- 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.
