Rule 510 is triggering events but logtest is not showing any rules that should be triggered

480 views
Skip to first unread message

Rob Williams

unread,
Apr 5, 2017, 3:26:31 PM4/5/17
to ossec-list
Hi all,

I'm running into an issue where rule 510 is triggering and I'm getting spammed with alerts but I can't seem to tune it correctly. What's weird is that I am still getting alerted for rule 510 for this log, but I can't figure out how to get that to show in logtest. Basically, I am getting spammed with rule 510 and trying to filter it down more and here is what happens when I enter the log in logtest:    .... any ideas on how to fix this?

**Phase 1: Completed pre-decoding.

       full event: 'File '/filepath/' is owned by root and has written permissions to anyone.'

       hostname: 'hostname'

       program_name: '(null)'

       log: 'File '/filepath/' is owned by root and has written permissions to anyone.'


**Phase 2: Completed decoding.

       decoder: 'sample_decoder_setup'

       id: '/filepath/'

dan (ddp)

unread,
Apr 5, 2017, 3:39:42 PM4/5/17
to ossec...@googlegroups.com
Did you restart the OSSEC processes on the server after making your
modifications?

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

Rob Williams

unread,
Apr 5, 2017, 3:44:16 PM4/5/17
to ossec-list
Yes I have, I've also tried to disable all the relevant changes I've made, restart, and still have the same issue.

dan (ddp)

unread,
Apr 5, 2017, 3:48:21 PM4/5/17
to ossec...@googlegroups.com
On Wed, Apr 5, 2017 at 3:44 PM, Rob Williams <tsinfo...@gmail.com> wrote:
> Yes I have, I've also tried to disable all the relevant changes I've made,
> restart, and still have the same issue.
>

Try stopping the ossec processes, verify that ossec-analysisd has
stopped (sometimes it doesn't and causes issues), and start it back
up.
Can you also post the changes you made?

Rob Williams

unread,
Apr 5, 2017, 4:45:52 PM4/5/17
to ossec-list
I stopped them all (which appeared to work fine) and start again. Here is the rule and decoder I made for this (I want to alert only once if the same ID (filepath) has alerted in the past minute):

<rule id="80100" level="7" frequency="2" timeframe="60" ignore="120">

    <if_matched_sid>510</if_matched_sid>

    <same_id />

    <description>This is meant to reduce noise as these events happen in batches with not much difference in meaning.</description>

  </rule>


DECODER:


<decoder name="sample_decoder_setup">

  <prematch>^(\.+) (\p/filepath\.+) </prematch>

  <regex>(/filepath/\.+/mnt/\.+/)</regex>

  <order>id</order>

</decoder>


Logtest returns the id I am looking for to match and that part works fine. It only gets to the first 2 steps though, and does not match it with a rule in logtest.

Jesus Linares

unread,
Apr 6, 2017, 4:30:01 AM4/6/17
to ossec-list

dan (ddp)

unread,
Apr 6, 2017, 1:13:16 PM4/6/17
to ossec...@googlegroups.com
On Wed, Apr 5, 2017 at 4:45 PM, Rob Williams <tsinfo...@gmail.com> wrote:
> I stopped them all (which appeared to work fine) and start again. Here is
> the rule and decoder I made for this (I want to alert only once if the same
> ID (filepath) has alerted in the past minute):
>
> <rule id="80100" level="7" frequency="2" timeframe="60" ignore="120">
>
> <if_matched_sid>510</if_matched_sid>
>
> <same_id />
>
> <description>This is meant to reduce noise as these events happen in
> batches with not much difference in meaning.</description>
>
> </rule>
>
>
> DECODER:
>
>
> <decoder name="sample_decoder_setup">
>
> <prematch>^(\.+) (\p/filepath\.+) </prematch>
>
> <regex>(/filepath/\.+/mnt/\.+/)</regex>
>
> <order>id</order>
>
> </decoder>
>
>
> Logtest returns the id I am looking for to match and that part works fine.
> It only gets to the first 2 steps though, and does not match it with a rule
> in logtest.
>

Well 510 won't match because it expects 509 to match. 509 won't match
because it requires decoder "rootcheck" to match. Your decoder is
taking priority apparently. Maybe if you made your decoder a child of
rootcheck.

Rob Williams

unread,
Apr 6, 2017, 1:28:21 PM4/6/17
to ossec-list
Hi,

I tried to do this, but I'm getting:

ERROR: Parent decoder name invalid: 'rootcheck'
ERROR: Error adding decoder plugin

I don't see the rootcheck decoder within decoder.xml as well, any ideas?

Thanks again for the help!

dan (ddp)

unread,
Apr 6, 2017, 1:44:57 PM4/6/17
to ossec...@googlegroups.com
On Thu, Apr 6, 2017 at 1:28 PM, Rob Williams <tsinfo...@gmail.com> wrote:
> Hi,
>
> I tried to do this, but I'm getting:
>
> ERROR: Parent decoder name invalid: 'rootcheck'
> ERROR: Error adding decoder plugin
>
> I don't see the rootcheck decoder within decoder.xml as well, any ideas?
>

It must be one of the built in decoders, and I guess those can't be
used for child decoders.
No other ideas at the moment, but I'll keep thinking about it.

> Thanks again for the help!
>
>
> On Wednesday, April 5, 2017 at 12:26:31 PM UTC-7, Rob Williams wrote:
>>
>> Hi all,
>>
>> I'm running into an issue where rule 510 is triggering and I'm getting
>> spammed with alerts but I can't seem to tune it correctly. What's weird is
>> that I am still getting alerted for rule 510 for this log, but I can't
>> figure out how to get that to show in logtest. Basically, I am getting
>> spammed with rule 510 and trying to filter it down more and here is what
>> happens when I enter the log in logtest: .... any ideas on how to fix
>> this?
>>
>> **Phase 1: Completed pre-decoding.
>>
>> full event: 'File '/filepath/' is owned by root and has written
>> permissions to anyone.'
>>
>> hostname: 'hostname'
>>
>> program_name: '(null)'
>>
>> log: 'File '/filepath/' is owned by root and has written
>> permissions to anyone.'
>>
>>
>> **Phase 2: Completed decoding.
>>
>> decoder: 'sample_decoder_setup'
>>
>> id: '/filepath/'
>

Jesus Linares

unread,
Apr 7, 2017, 5:24:28 AM4/7/17
to ossec-list
Hi Rob,

it is not possible to create decoders for rootcheck because they are at C level: https://github.com/wazuh/wazuh/blob/master/src/analysisd/analysisd.c#L772

Also, you don't need them, just create a rule like:

<rule id="70908" level="0" frequency="0" timeframe="45" ignore="300">
   
<if_matched_sid>510</if_matched_sid>
   
<match>your conditions (match the file?)</match>
   
<description>Ignore rule 510 during 300 seconds.</description>
</rule>



Also, you can disable the check in the ossec.conf.

I hope it helps.
Regards.

Rob Williams

unread,
Apr 13, 2017, 6:13:50 PM4/13/17
to ossec-list
Hi Jesus,

Thanks for the reply. I have noticed when I activate this rule, it blocks all events and does not alert on the first event. Also note, I am trying to use the ID field from my decoder to match against. I can't just use a static match as the ID continuously changes so I'd need the ID from the decoder to do so. Any ideas? Thanks!


On Wednesday, April 5, 2017 at 12:26:31 PM UTC-7, Rob Williams wrote:

Jesus Linares

unread,
Apr 17, 2017, 4:16:48 AM4/17/17
to ossec-list
What rule did you use?. Please, share here the rule and the alerts that you want to ignore.

I'd need the ID from the decoder to do so
There are no xml decoders for rootcheck. What you want to extract in the id field is the file, right?. You can do a match in the rule for the file.

Regards.

Rob Williams

unread,
Apr 17, 2017, 12:55:19 PM4/17/17
to ossec-list
Hi Jesus, the first rule is what I am trying. You said I can match the file in <match> but can I do that when the file changes as is not one file I want to ignore. Can I use regex syntax in rules? I used it in decoders as I thought I wasn't able to. Thanks!

<rule
 id="70908" level="0" frequency="0" timeframe="45" ignore="600">

    
<if_matched_sid>510</if_matched_sid>
    
<same_id />

    
<description>Ignore rule 510 for 600 seconds if the same ID is matched.</description>
</rule>

Jesus Linares

unread,
Apr 18, 2017, 8:14:28 AM4/18/17
to ossec-list
Hi Rob,

you need to add the conditions to trigger that rule only for your specific files. Use match or regex:

<rule id="70908" level="0" frequency="0" timeframe="45" ignore="600">
   
<if_matched_sid>510</if_matched_sid>

   
<!--
    contitions:
    option 1:
    <match>YOUR_FILE1|YOUR_FILE2|...</match>
    option 2:
    <regex>YOUR_FILE\.+</regex>
    -->

   
<description>Ignore rule 510 for 600 seconds for some files.</description>
</rule>

I think you can't use same_id because the decoders are not extracting any ID.

Regards.

Rob Williams

unread,
Apr 18, 2017, 1:45:13 PM4/18/17
to ossec-list
Hi Jesus,

I'll try this and let you know. The decoder is extracting the ID effectively, however, it is just not matching the log with any rule it seems.

Jesus Linares

unread,
Apr 20, 2017, 3:44:57 AM4/20/17
to ossec-list
Hi Rob,

I guess your decoder is working in ossec-logtest. But, in the real world, the events from rootcheck don't use xml decoders, they use c decoders: https://github.com/wazuh/wazuh/blob/master/src/analysisd/analysisd.c#L772

Regards.

Gert Verhoog

unread,
May 18, 2017, 7:46:58 PM5/18/17
to ossec-list
Hi Jesus,

I'm having the same problem, and the triggering of this rule causes so much noise that it's drowning out other alerts. I have added a rule like you suggested to my local rules:

  <rule id="100510" level="0" frequency="0" timeframe="45" ignore="600">
    <if_matched_sid>510</if_matched_sid>
    <regex>/var/lib/docker/volumes/\.*/_data/\.* is owned by root and has written permissions to anyone</regex>
    <description>Ignore rootcheck warning on world-writable docker volumes</description>
  </rule>

But it doesn't seem to have an effect. I've played with the regex, simplifying it and even deleting it altogether, but I still can't seem to get it working. Logtest shows the following output:


File '/var/lib/docker/volumes/81c96e1d9b6a07710dc0ba90daccf5650efe59e213b20354bbb86f4e65929a0e/_data/path/to/static/fonts/icons/glyphicons-social-regular.eot' is owned by root and has written permissions to anyone.


**Phase 1: Completed pre-decoding.


       full event: 'File '/var/lib/docker/volumes/81c96e1d9b6a07710dc0ba90daccf5650efe59e213b20354bbb86f4e65929a0e/_data/path/to/static/fonts/icons/glyphicons-social-regular.eot' is owned by root and has written permissions to anyone.'


       hostname: 'ec2-12-34-56-78'


       program_name: '(null)'


       log: 'File '/var/lib/docker/volumes/81c96e1d9b6a07710dc0ba90daccf5650efe59e213b20354bbb86f4e65929a0e/_data/path/to/static/fonts/icons/glyphicons-social-regular.eot' is owned by root and has written permissions to anyone.'




**Phase 2: Completed decoding.


       No decoder matched.



I'm fairly new to OSSEC and Wazuh, so I may be missing something. Is there anything obvious that I'm doing wrong?

Cheers!
Gert

dan (ddp)

unread,
May 19, 2017, 9:04:44 PM5/19/17
to ossec...@googlegroups.com
On Thu, May 18, 2017 at 4:51 PM, Gert Verhoog <ge...@montoux.com> wrote:
> Hi Jesus,
>
> I'm having the same problem, and the triggering of this rule causes so much
> noise that it's drowning out other alerts. I have added a rule like you
> suggested to my local rules:
>
> <rule id="100510" level="0" frequency="0" timeframe="45" ignore="600">
> <if_matched_sid>510</if_matched_sid>
> <regex>/var/lib/docker/volumes/\.*/_data/\.* is owned by root and has
> written permissions to anyone</regex>
> <description>Ignore rootcheck warning on world-writable docker
> volumes</description>
> </rule>
>
> But it doesn't seem to have an effect. I've played with the regex,
> simplifying it and even deleting it altogether, but I still can't seem to
> get it working. Logtest shows the following output:
>
>
> File
> '/var/lib/docker/volumes/81c96e1d9b6a07710dc0ba90daccf5650efe59e213b20354bbb86f4e65929a0e/_data/path/to/static/fonts/icons/glyphicons-social-regular.eot'
> is owned by root and has written permissions to anyone.
>

Is this the log message you get from the agent? You can turn on the
logall option and check archives.log for the exact message from the
agent.

Jesus Linares

unread,
May 22, 2017, 9:35:58 AM5/22/17
to ossec-list
You can't use ossec-logtest for rootcheck events. For example, if I get the full_log of a real alert: "File '/usr/local/nsis/nsis-3.0b2-src/Contrib/Language files/Valencian.nlf' is owned by root and has written permissions to anyone." and I paste it in logtest:

*Phase 1: Completed pre-decoding.
       full
event: 'File '/usr/local/nsis/nsis-3.0b2-src/Contrib/Language files/Valencian.nlf' is owned by root and has written permissions to anyone.'
       hostname
: 'ip-10-0-0-10'
       program_name
: '(null)'
       log
: 'File '/usr/local/nsis/nsis-3.0b2-src/Contrib/Language files/Valencian.nlf' is owned by root and has written permissions to anyone.'



**Phase 2: Completed decoding.
       
No decoder matched.


So, ossec-logtest doesn't show anything, but the alert is properly generated. This is due to rootcheck has decoders at c-level.

Your rule looks right, just restart OSSEC and test it manually. Sometimes, OSSEC has problems with \.* so if that part doesn't have spaces, it is better to use \S*.

Let me know if it works.
Regards.

Gert Verhoog

unread,
May 22, 2017, 10:22:02 PM5/22/17
to ossec-list
Aha, thanks for the insights, that makes sense. I've changed the \.* into \S* and restarted everything. It seems to work! Thanks for your help!

Cheers,
Gert

Gert Verhoog

unread,
May 23, 2017, 9:02:24 PM5/23/17
to ossec-list
Unfortunately, it's still not working, and I'm not sure what else I can try... This is what I'm doing:

The log entries that I want to ignore all look like this (from archives.log):

2017 May 24 12:38:16 (ci-runner__development_12.34.56.78) any->rootcheck File '/var/lib/docker/volumes/d758587e86d60a53043c93c1f730d6e04acdcb5f7a5a181182cfe0fb754aa293/_data/path/to/some/file.txt' is owned by root and has written permissions to anyone.

Inspired by rule 511 from the wazuh ruleset, I have the following rule in /var/ossec/etc/rules/local_rules.xml:

  <rule id="100510" level="0">

   
<if_sid>510</if_sid>
   
<regex>is owned by root and has written permissions to anyone</regex>
   
<description>Ignore this rule</description>
   
<group>rootcheck,</group>
 
</rule>

After editing the local rules file, I execute a "/var/ossec/bin/ossec-control restart" on the server, and after that also on the client. I wait for rootcheck to execute, which generates many entries such as the one above in the archives.log. Unfortunately, they still show up as a level 7 event in the kibana dashboard:

rule.id:510 agent.name:ci-runner__development_12.34.56.78 agent.id:009 manager.name:ec2-11-22-33-44.ap-southeast-2.compute.amazonaws.comrule.firedtimes:1,700 rule.level:7 rule.description:Host-based anomaly detection event (rootcheck). rule.groups:ossec, rootcheck source:decoder.name:rootcheck title:File is owned by root and has written permissions to anyone. full_log:File '/var/lib/docker/volumes/d758587e86d60a53043c93c1f730d6e04acdcb5f7a5a181182cfe0fb754aa293/_data/path/to/some/file.txt' is owned by root and has written permissions to anyone. @timestamp:May 24th 2017, 12:38:16.000 file:/var/lib/docker/volumes/d758587e86d60a53043c93c1f730d6e04acdcb5f7a5a181182cfe0fb754aa293/_data/path/to/some/file.txt host:ec2-11-22-33-44.ap-southeast-2.compute.amazonaws.com location:rootcheck


Unfortunately, we can't just change the permissions of these without breaking our CI. I'm not very concerned about the world-writable files under /var/lib/docker/volumes, since only root can traverse this path anyway, so I would love to just ignore them, as they are about 90% of what shows up in the dashboards, so it drowns out other events. 

Do you have any ideas what I could try next? 

Many thanks for your help so far!

Gert Verhoog

unread,
May 23, 2017, 11:32:48 PM5/23/17
to ossec-list
I think I'm just really confused as to what "regex" and "match" are actually matching against. Given the following log event:

2017 May 24 12:38:16 (ci-runner__development_12.34.56.78) any->rootcheck File '/var/lib/docker/volumes/d758587e86d60a53043c93c1f730d6e04acdcb5f7a5a181182cfe0fb754aa293/_data/path/to/some/file.txt' is owned by root and has written permissions to anyone.

This rule successfully ignores it:

  <rule id="100510" level="0">
   
<if_sid>510</if_sid>

   
<regex>/var/lib/docker/volumes/\S+/_data</regex>

   
<description>Ignore this rule</description>
   
<group>rootcheck,</group>
 
</rule>


But this one doesn't:

  <rule id="100510" level="0">
    <if_sid>510</if_sid>
    <regex>is owned by root and has written permissions to anyone</regex>
    <description>Ignore this rule</description>
    <group>rootcheck,</group>
  </rule>


What string does regex match against? The docs say "Any regex to match against the log event"; that should include more than just the file path, right?

Cheers,
Gert

Jesus Linares

unread,
May 24, 2017, 9:21:52 AM5/24/17
to ossec-list
I don't know what is happening. Both, regex and match look in the full_log field. So it should work with regex (escaping reserved characters) and match. It looks like the full_log doesn't contain that information, only the filename. 

Anyway, if you are using Wazuh 2.0, the "title" and the "file" are extracted as dynamic fields. Example:

local_rules.xml  (change the level to 0)

<rule id="100510" level="15">
   
<if_sid>510</if_sid>
   
<field name="title">File is owned by root and has written permissions to anyone</field>

   
<description>Ignore this rule</description>
   
<group>rootcheck,</group>
</rule>

alerts.log
Rule: 100510 (level 15) -> 'Ignore this rule'
File '/var/lib/test' is owned by root and has written permissions to anyone.

title
: File is owned by root and has written permissions to anyone.

file
: /var/lib/test

You can use both fields to ignore only some files:
<field name="title">File is owned by root and has written permissions to anyone</field>
<field name="file">good_file.txt</field>

The <field> tag is a regex, so you can use wildcards (\.+ \.*), or (|), expressions (\w, \S), etc.

I hope it helps.

Gert Verhoog

unread,
May 28, 2017, 11:04:40 PM5/28/17
to ossec-list
That works like a charm, thank you for your help!

Cheers,
gert
Reply all
Reply to author
Forward
0 new messages