Decoding the host name in named log as "url" causes it to not get passed to the active response script. I just a dash "-" as a place holder. Decoding as user isn't perfect either as the built-in validation will sometimes reject the value and not call the script, For example the following error in ossec.log when the "user" has http:// in it.
2017/03/17 10:03:39 ossec-analysisd(1272): WARN: Invalid username '8. http://www.ralph66.com'. Possible logging attack. I can create a static block for DNS queries with an invalid 'http://' in the host name. Any thoughts on the decoding and the validation? On Wed, Mar 15, 2017 at 4:32 PM, dan (ddp) <[email protected]> wrote: > On Wed, Mar 15, 2017 at 4:15 PM, Ralph Durkee <[email protected]> > wrote: > > Dan, > > > > > > When I started this I was apparently was using some old documentation, > > probably the book you wrote several years ago, and the parameter examples > > were limited. Also the newer docs show a limited set of <same_xxx> > > directives, so I’m wondering if there is a <same_url> directive. Maybe > > location would make sense? Actually the whole concept of blocking on > > same_location will not work unless the decoder strips off the first > random > > hostname and grabs the rest of the domain name. Of course all of this > may be > > too specific and the more generic version of the rules may be preferred > if > > it works as well. > > > > Daniel Cid wrote the book, I'm the other Dan. Daniel Cid also created > OSSEC. :-) > But it is outdated at this point > > > > > What I have now worked against a recent flurry of bogus DNS requests, but > > then a second flurry started and it didn’t trigger a second time. It > would > > have been during the timeout window of the first flurry of requests. So > I’m > > thinking it may be related to not triggering active response again during > > the timeout window. When I have some more time I’ll do some testing to > try > > to confirm the hypothesis, but any insights or questions from those with > > more experience are much appreciated. > > > > I'm not sure why that would happen. I'll have to read through this > thread again and maybe try to recreate it (or at least something > similar). > > > > > I will try out the decoder soon, but first wanted to test and resolve the > > issue about not firing for a second flurry. > > > > > > Thanks for the help! > > > > I love the flexibility and capabilities of OSSEC > > > > > > -- Ralph Durkee, CISSP, GXPN, GPEN, GCIH, GSEC, GSNA, GCIA, C|EH > > Principal Security Consultant > > > > > > > > -- > > > > --- > > 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/d/optout. > > -- > > --- > You received this message because you are subscribed to a topic in the > Google Groups "ossec-list" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/ossec-list/BTPA-plCXxM/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- 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/d/optout.
