Re: [ossec-list] Re: DNS block active response script not run for named rule

[Ralph Durkee]

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)  wrote:

> On Wed, Mar 15, 2017 at 4:15 PM, Ralph Durkee 
> 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 
> > directives, so I’m wondering if there is a  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 ossec-list+unsubscr...@googlegroups.com.
> > 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
> ossec-list+unsubscr...@googlegroups.com.
> 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 ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] Re: DNS block active response script not run for named rule

[dan (ddp)]

On Wed, Mar 15, 2017 at 4:15 PM, Ralph Durkee  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 
> directives, so I’m wondering if there is a  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 ossec-list+unsubscr...@googlegroups.com.
> 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 ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] Re: DNS block active response script not run for named rule

[dan (ddp)]

On Tue, Mar 14, 2017 at 5:44 PM, Ralph Durkee  wrote:
> Yes, I got the production system working against a test attack script. Will
> monitor it to do tuning for the real flurries of bogus DNS queries, and will
> try the duplicate / twin decoder name to see if that works.  An override
> option for the decoder name would be ideal. The other thing that occurred to
> me I could do, is copy all the child named decoders into the local decoder
> file and use the parent name of the new improved named decoder.
>

I stopped updating the named decoders when I stopped using it a couple
of years ago, so thanks for up to date log samples.
"url" looks better than srcuser, but I'm open to using whatever.

The below patch is also available at
https://github.com/ossec/ossec-hids/pull/1094

How does this work for you:
diff --git a/etc/decoder.xml b/etc/decoder.xml
index d0c5a196..7d86bad0 100755
--- a/etc/decoder.xml
+++ b/etc/decoder.xml
@@ -952,11 +952,16 @@ Jan  8 19:32:41 tp.lan dropbear[15165]: Pubkey
auth succeeded for 'root' with ke

 
   named
-  : query: 
-  client (\S+)#\d+\s*\S*: query: (\S+) IN 
+  : query 
+  client (\S+)#\d+\s*\S*: 
   srcip,url
 

+
+  named
+  query: (\S+) IN|query \S+ '(\S+)/
+  url
+

 
   named


> --
>
> ---
> 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 ossec-list+unsubscr...@googlegroups.com.
> 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 ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] Re: DNS block active response script not run for named rule

[Pedro Sanchez]

Nice catch! You know it also happened to me when testing your decoders?
Same thing! That is why I always recommend to use ossec-logtest, it's a
wonderful tool :D

I don't think you have a way to not modify* decoders.xml*, there is already
a child decoder matching your event, using "prematch" which will prevent
OSSEC to keep decoding (it match, it is a child, stop and exit).

We have something call "twin decoders"... you can give it a try, I don't
have enough time today to test it for you. You could "expand" a current
decoder by using same decoder name, but it's tricky.

So.. everything is working as expected? AR up and running?


Regards,
Pedro Sanchez.

On Tue, Mar 14, 2017 at 9:43 PM, Ralph Durkee 
wrote:

> Pedro thanks again for your help.
>
>
> I think I found the problem, but the work around requires modification of
> the decoder.xml
>
> I moved decoder into the decoder.xml file (I now that’s not the
> recommended), before the named group decoder, and made the decoder not a
> child of the named group decoder. From etc/decoder.xml
>
>
> . . .
>
> 
>
> ^named
>
> denied$
>
> client (\S+)#\d+\s+\((\S+)\): query 
>
> srcip,user
>
> 
>
>
>
> 
>
> 
>
> ^named
>
> 
>
> . . .
>
>
> The decoding works properly as per logtest
>
>
> # head -1 log-sample1 | bin/ossec-logtest
>
> 2017/03/14 16:30:27 ossec-testrule: INFO: Reading local decoder file.
>
> 2017/03/14 16:30:27 ossec-testrule: INFO: Started (pid: 4093).
>
> ossec-testrule: Type one log per line.
>
>
>
> **Phase 1: Completed pre-decoding.
>
> full event: 'Mar 14 12:58:58 net19 named[6147]: client 108.239.52.141#3181
> (kzcvyjchmduzkj.tengyin66.com): query (cache) '
> kzcvyjchmduzkj.tengyin66.com/A/IN' denied'
>
> hostname: 'net19'
>
> program_name: 'named'
>
> log: 'client 108.239.52.141#3181 (kzcvyjchmduzkj.tengyin66.com): query
> (cache) 'kzcvyjchmduzkj.tengyin66.com/A/IN' denied'
>
>
> **Phase 2: Completed decoding.
>
> decoder: 'named-query-denied'
>
> srcip: '108.239.52.141'
>
> *dstuser: 'kzcvyjchmduzkj.tengyin66.com
> '*
>
>
> **Phase 3: Completed filtering (rules).
>
> Rule id: '12108'
>
> Level: '4'
>
> Description: 'Invalid Query cache denied.'
>
> Info - Link: 'http://www.reedmedia.net/misc/dns/errors.html'
>
> **Alert to be generated.
>
>
>
> I originally had the decoder as a parent top level decoder, otherwise the
> logtest output seemed to only mention the named decoder, rather than the
> child. I thought it was just limited output at the time. So once I was
> convinced it worked, I moved it to be a child decoder, and moved it to the
> local_named.xml file, and made its parent be the named decoder. However I
> believe the ‘named-query-denied’ decoding is not working as a child of the
> named decoder. Any ideas why???
>
>
> The rest of the rules and alerts etc are working fine, but I believe if
> the decoder fails to extract the dtsuser from the log, then OSSEC would
> silently refuse to call the active response script, because it didn’t have
> the expected user value from the log.  (Might be nice to have a log on such
> a failure)
>
>
>
> *Is there a way to make this work without modifying the decoder.xml file ?
> *
>
>
>
> *Thanks!*
>
>
> --
>
> ---
> 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 ossec-list+unsubscr...@googlegroups.com.
> 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 ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] Re: DNS block active response script not run for named rule

[Pedro Sanchez]

Hi Ralph,

You are welcome.

Yes, I did, I can confirm I was seeing entries on active-response.log and
the *firewall-dns-query-drop.sh* was triggering.

Let me see if I can keep helping you, by "stand-alone" you mean you only
have an OSSEC Manager running isn't it?
Just to be sure, at active-response block, "*local*" means "agents", and "
*server*" means that the AR will work for the OSSEC Manager, you could
check the documentation here

which
probably explain everything better than myself :D

Copy-pasting from OSSEC Docs:


> *location*Where the command should be executed. You have four options:
> Allowed:
>
local: on the agent that generated the event
> server: on the OSSEC server
> defined-agent: on a specific agent (when using this option, you need to
> set the agent_id to use)
> all: or everywhere.


"local" setting will run the command only on agent side, never on Manager
side.

Hope it helps.

Cheers,
Pedro.

On Tue, Mar 14, 2017 at 2:04 PM, Ralph Durkee 
wrote:

> Thanks for trying it.
>
>- Permissions on the script are good.
>
> # ll active-response/bin/firewall-dns-query-drop.sh
> -rwxr-x--- 1 root ossec 5758 Mar 10 07:58 active-response/bin/firewall-
> dns-query-drop.sh*
>
>- I removed the  8 tag.
>- This is a stand-alone install so I don't think the server tag is
>needed.
>
> Just to confirm that when you say it worked, the active-response.log shows
> an attempt to run  the script active-response/bin/firewall-
> dns-query-drop.sh?
>
> I did a test where I copied firewall-drop.sh to firewall-dns-query-drop.sh
> just to eliminate any concern that the issue might be with the script, but
> the script did not get invoked. It would generate an error, because an IP
> address isn't passed, but  I'm convinced it's something in the
> ossec-server.conf file.   I'm going to try it out on a clean Cent-OS 7
> system next.
>
> Thanks for the help,
>
> -- Ralph
>
>
> On Tuesday, March 14, 2017 at 8:13:31 AM UTC-4, Pedro Sanchez wrote:
>>
>> Hi Ralph,
>>
>> I have been testing your configuration, everything works great on my
>> environment (using standard firewall-drop.sh).
>>
>> Few tips which may help you:
>>
>>
>>- Active-response block: you are using *rules_id *and *level*, since
>>your rule will have same level no matter what, maybe you could remove
>>
>>- Active-response block: You defined "local" which will only trigger
>>active-response to remote agents, in case you want to trigger
>>active-response at the manager, you could use "*server*", or both, "
>>*server,local*" ("*all*" option is not working on my environment)
>>- Ruleset: I did verify your decoders and rules, still, you could use
>>bin/ossec-logtest tool and paste your event, just to confirm they are
>>working properly on your installation
>>- You could run the active-response manually by running: 
>> *bin/agent_control
>>-b ip_address_to_block -f firewall-dns-query-drop5400 -u agent_id*
>>- Permissions: Confirm your scripts have permissions to root:ossec
>>and rwxr-x---
>>
>>
>> Hope it helps, best regards,
>> Pedro Sanchez.
>>
>>
>>
>>
>>
>>
>>
>>
>> On Monday, March 13, 2017 at 3:11:50 PM UTC+1, Ralph Durkee wrote:
>>>
>>>
>>> I’m getting heavy flurries of bogus DNS queries to non-recursive,
>>> authoritative DNS server. The traffic comes from a large spread of src ip
>>> address, so it’s obviously mostly spoofed. The queries are all denied, so
>>> it’s almost no risk, except that it heavily overloads the log management,
>>> it’s annoying, and could cause some more serious logs to get missed in the
>>> flurry. The rate of traffic is about 3 – 20 queries per second, and a
>>> flurry often runs for several hours. The host name is random, but the
>>> domain names are pretty static within a single flurry. So I’ve written a
>>> named decoder to extract the host name as ‘user’, and rules to alert on the
>>> flurry of denied queries. The decoder and alerts are working fine. I also
>>> have an active response script which adds an iptable rule to drop queries
>>> for a specific denied domain name. The script works fine when run by hand.
>>> Its based on the existing active-response/bin/firewall-drop.sh so that
>>> it uses the same locking directory, so that the two scripts will co-operate
>>> on locking, The one thing that’s not working that when the alert is
>>> generated the script doesn't get run. The script is in the
>>> active-response/bin with rx permissions. There’s no error log in the
>>> ossec.log and there’s not even an indication that it started to run in the
>>> active-responses.log. The first thing the script does is generate a log to
>>> active-response.log similar to the script it’s based on. However the script
>>> is not run when the alert is generated for rule 12.
>>>
>>>
>>> *Sample traffic:*
>>>
>>>
>>> Mar 13 01:42:45 net19