Re: [ossec-list] Re: Rule 510 is triggering events but logtest is not showing any rules that should be triggered

[Gert Verhoog]

That works like a charm, thank you for your help!

Cheers,
gert

On Thursday, May 25, 2017 at 1:21:52 AM UTC+12, Jesus Linares wrote:
>
> 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)
>
> 
> 510
> *File is owned by root and has written 
> permissions to anyone*
> Ignore this rule
> rootcheck,
> 
>
> *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:
> File is owned by root and has written permissions to 
> anyone
> good_file.txt
>
> The  tag is a regex, so you can use wildcards (\.+ \.*), or (|), 
> expressions (\w, \S), etc.
>
> I hope it helps.
>
>
>
> On Wednesday, May 24, 2017 at 5:32:48 AM UTC+2, Gert Verhoog wrote:
>>
>> 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:
>>
>>   
>> 510
>> /var/lib/docker/volumes/\S+/_data
>> Ignore this rule
>> rootcheck,
>>   
>>
>>
>> But this one doesn't:
>>
>>   
>> 510
>> is owned by root and has written permissions to anyone
>> Ignore this rule
>> rootcheck,
>>   
>>
>>
>> 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
>>
>>
>>
>> On Wednesday, May 24, 2017 at 1:02:24 PM UTC+12, Gert Verhoog wrote:
>>>
>>> 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:
>>>
>>>   
>>> 510 
>>> is owned by root and has written permissions to anyone
>>>  
>>> Ignore this rule 
>>> rootcheck, 
>>>   
>>>
>>> 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!
>>>
>>>
>>> On Tuesday, May 23, 2017 at 1:35:58 AM UTC+12, Jesus Linares wrote:

 You can'

Re: [ossec-list] Re: Rule 510 is triggering events but logtest is not showing any rules that should be triggered

[Jesus Linares]

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)


510
*File is owned by root and has written permissions 
to anyone*
Ignore this rule
rootcheck,


*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:
File is owned by root and has written permissions to 
anyone
good_file.txt

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

I hope it helps.



On Wednesday, May 24, 2017 at 5:32:48 AM UTC+2, Gert Verhoog wrote:
>
> 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:
>
>   
> 510
> /var/lib/docker/volumes/\S+/_data
> Ignore this rule
> rootcheck,
>   
>
>
> But this one doesn't:
>
>   
> 510
> is owned by root and has written permissions to anyone
> Ignore this rule
> rootcheck,
>   
>
>
> 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
>
>
>
> On Wednesday, May 24, 2017 at 1:02:24 PM UTC+12, Gert Verhoog wrote:
>>
>> 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:
>>
>>   
>> 510 
>> is owned by root and has written permissions to anyone 
>> Ignore this rule 
>> rootcheck, 
>>   
>>
>> 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!
>>
>>
>> On Tuesday, May 23, 2017 at 1:35:58 AM UTC+12, Jesus Linares wrote:
>>>
>>> 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.
>

Re: [ossec-list] Re: Rule 510 is triggering events but logtest is not showing any rules that should be triggered

[Gert Verhoog]

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:

  
510
/var/lib/docker/volumes/\S+/_data
Ignore this rule
rootcheck,
  


But this one doesn't:

  
510
is owned by root and has written permissions to anyone
Ignore this rule
rootcheck,
  


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



On Wednesday, May 24, 2017 at 1:02:24 PM UTC+12, Gert Verhoog wrote:
>
> 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:
>
>   
> 510 
> is owned by root and has written permissions to anyone 
> Ignore this rule 
> rootcheck, 
>   
>
> 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!
>
>
> On Tuesday, May 23, 2017 at 1:35:58 AM UTC+12, Jesus Linares wrote:
>>
>> 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.
>>
>>
>> On Saturday, May 20, 2017 at 3:04:44 AM UTC+2, dan (ddpbsd) wrote:
>>>
>>> On Thu, May 18, 2017 at 4:51 PM, Gert Verhoog  
>>> 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: 
>>> > 
>>> >   >> ignore="600"> 
>>> > 510 
>>> > /var/lib/docker

Re: [ossec-list] Re: Rule 510 is triggering events but logtest is not showing any rules that should be triggered

[Gert Verhoog]

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:

  
510 
is owned by root and has written permissions to anyone 
Ignore this rule 
rootcheck, 
  

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!


On Tuesday, May 23, 2017 at 1:35:58 AM UTC+12, Jesus Linares wrote:
>
> 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.
>
>
> On Saturday, May 20, 2017 at 3:04:44 AM UTC+2, dan (ddpbsd) wrote:
>>
>> On Thu, May 18, 2017 at 4:51 PM, Gert Verhoog  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: 
>> > 
>> >   > ignore="600"> 
>> > 510 
>> > /var/lib/docker/volumes/\.*/_data/\.* is owned by root and 
>> has 
>> > written permissions to anyone 
>> > Ignore rootcheck warning on world-writable docker 
>> > volumes 
>> >
>> > 
>> > 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. 
>>
>> > 
>> > **Phase 1: Completed pre-decoding. 
>> > 
>> > 
>> >full event: 'File 
>> > 
>> '/var/lib/docker/volumes/81c96e1d9b6a07710dc0ba90daccf5650efe59e213b20354bbb86f4e65929a0e/_data/path/to/static/fonts/icons/glyphico

Re: [ossec-list] Re: Rule 510 is triggering events but logtest is not showing any rules that should be triggered

[Gert Verhoog]

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

On Tuesday, May 23, 2017 at 1:35:58 AM UTC+12, Jesus Linares wrote:
>
> 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*.
>
>

-- 

--- 
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: Rule 510 is triggering events but logtest is not showing any rules that should be triggered

[Jesus Linares]

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.


On Saturday, May 20, 2017 at 3:04:44 AM UTC+2, dan (ddpbsd) wrote:
>
> On Thu, May 18, 2017 at 4:51 PM, Gert Verhoog  > 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: 
> > 
> >
> > 510 
> > /var/lib/docker/volumes/\.*/_data/\.* is owned by root and 
> has 
> > written permissions to anyone 
> > Ignore rootcheck warning on world-writable docker 
> > volumes 
> >
> > 
> > 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. 
>
> > 
> > **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 
> > 
> > 
> > 
> > On Wednesday, April 19, 2017 at 12:14:28 AM UTC+12, Jesus Linares wrote: 
> >> 
> >> Hi Rob, 
> >> 
> >> you need to add the conditions to trigger that rule only for your 
> specific 
> >> files. Use match or regex: 
> >> 
> >>  
> >> 510 
> >>  
> >> Ignore rule 510 for 600 seconds for some 
> >> files. 
> >>  
> > 
> > 
> > 
> > 
> > -- 
> > 
> > --- 
> > 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. 
>

-- 

--- 
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: Rule 510 is triggering events but logtest is not showing any rules that should be triggered

[dan (ddp)]

On Thu, May 18, 2017 at 4:51 PM, Gert Verhoog  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:
>
>   
> 510
> /var/lib/docker/volumes/\.*/_data/\.* is owned by root and has
> written permissions to anyone
> Ignore rootcheck warning on world-writable docker
> volumes
>   
>
> 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.

>
> **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
>
>
>
> On Wednesday, April 19, 2017 at 12:14:28 AM UTC+12, Jesus Linares wrote:
>>
>> Hi Rob,
>>
>> you need to add the conditions to trigger that rule only for your specific
>> files. Use match or regex:
>>
>> 
>> 510
>> 
>> Ignore rule 510 for 600 seconds for some
>> files.
>> 
>
>
>
>
> --
>
> ---
> 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.

[ossec-list] Re: Rule 510 is triggering events but logtest is not showing any rules that should be triggered

[Gert Verhoog]

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:

  
510
/var/lib/docker/volumes/\.*/_data/\.* is owned by root and has 
written permissions to anyone
Ignore rootcheck warning on world-writable docker 
volumes
  

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



On Wednesday, April 19, 2017 at 12:14:28 AM UTC+12, Jesus Linares wrote:
>
> Hi Rob,
>
> you need to add the conditions to trigger that rule only for your specific 
> files. Use match or regex:
>
> 
> 510
> 
> Ignore rule 510 for 600 seconds for some files.
> 
>  
>

 

-- 

--- 
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.

[ossec-list] Re: Rule 510 is triggering events but logtest is not showing any rules that should be triggered

[Jesus Linares]

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.

On Tuesday, April 18, 2017 at 7:45:13 PM UTC+2, Rob Williams wrote:
>
> 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.
>
> On Tuesday, April 18, 2017 at 5:14:28 AM UTC-7, Jesus Linares wrote:
>>
>> Hi Rob,
>>
>> you need to add the conditions to trigger that rule only for your 
>> specific files. Use match or regex:
>>
>> 
>> 510
>> 
>> Ignore rule 510 for 600 seconds for some files.
>> 
>> 
>>
>> I think you can't use *same_id *because the decoders are not extracting 
>> any ID.
>>
>> Regards.
>>
>> On Monday, April 17, 2017 at 6:55:19 PM UTC+2, Rob Williams wrote:
>>>
>>> Hi Jesus, the first rule is what I am trying. You said I can match the 
>>> file in  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!
>>>
>>> 
>>> 510
>>> 
>>> Ignore rule 510 for 600 seconds if the same ID is 
>>> matched.
>>> 
>>>
>>> On Monday, April 17, 2017 at 3:16:48 AM UTC-5, Jesus Linares wrote:

 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.

 On Friday, April 14, 2017 at 12:13:50 AM UTC+2, Rob Williams wrote:
>
> 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:
>>
>> 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/'
>>
>

-- 

--- 
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.

[ossec-list] Re: Rule 510 is triggering events but logtest is not showing any rules that should be triggered

[Rob Williams]

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.

On Tuesday, April 18, 2017 at 5:14:28 AM UTC-7, Jesus Linares wrote:
>
> Hi Rob,
>
> you need to add the conditions to trigger that rule only for your specific 
> files. Use match or regex:
>
> 
> 510
> 
> Ignore rule 510 for 600 seconds for some files.
> 
> 
>
> I think you can't use *same_id *because the decoders are not extracting 
> any ID.
>
> Regards.
>
> On Monday, April 17, 2017 at 6:55:19 PM UTC+2, Rob Williams wrote:
>>
>> Hi Jesus, the first rule is what I am trying. You said I can match the 
>> file in  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!
>>
>> 
>> 510
>> 
>> Ignore rule 510 for 600 seconds if the same ID is 
>> matched.
>> 
>>
>> On Monday, April 17, 2017 at 3:16:48 AM UTC-5, Jesus Linares wrote:
>>>
>>> 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.
>>>
>>> On Friday, April 14, 2017 at 12:13:50 AM UTC+2, Rob Williams wrote:

 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:
>
> 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/'
>


-- 

--- 
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.

[ossec-list] Re: Rule 510 is triggering events but logtest is not showing any rules that should be triggered

[Jesus Linares]

Hi Rob,

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


510

Ignore rule 510 for 600 seconds for some files.



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

Regards.

On Monday, April 17, 2017 at 6:55:19 PM UTC+2, Rob Williams wrote:
>
> Hi Jesus, the first rule is what I am trying. You said I can match the 
> file in  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!
>
> 
> 510
> 
> Ignore rule 510 for 600 seconds if the same ID is 
> matched.
> 
>
> On Monday, April 17, 2017 at 3:16:48 AM UTC-5, Jesus Linares wrote:
>>
>> 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.
>>
>> On Friday, April 14, 2017 at 12:13:50 AM UTC+2, Rob Williams wrote:
>>>
>>> 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:

 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/'

>>>

-- 

--- 
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.

[ossec-list] Re: Rule 510 is triggering events but logtest is not showing any rules that should be triggered

[Rob Williams]

Hi Jesus, the first rule is what I am trying. You said I can match the file 
in  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!


510

Ignore rule 510 for 600 seconds if the same ID is matched.



On Monday, April 17, 2017 at 3:16:48 AM UTC-5, Jesus Linares wrote:
>
> 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.
>
> On Friday, April 14, 2017 at 12:13:50 AM UTC+2, Rob Williams wrote:
>>
>> 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:
>>>
>>> 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/'
>>>
>>

-- 

--- 
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.

[ossec-list] Re: Rule 510 is triggering events but logtest is not showing any rules that should be triggered

[Jesus Linares]

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.

On Friday, April 14, 2017 at 12:13:50 AM UTC+2, Rob Williams wrote:
>
> 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:
>>
>> 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/'
>>
>

-- 

--- 
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.

[ossec-list] Re: Rule 510 is triggering events but logtest is not showing any rules that should be triggered

[Rob Williams]

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:
>
> 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/'
>

-- 

--- 
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: Rule 510 is triggering events but logtest is not showing any rules that should be triggered

[Jesus Linares]

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:


510
your conditions (match the file?)
Ignore rule 510 during 300 seconds.



Example for ignore completely a rootcheck 
event: 
https://github.com/wazuh/wazuh-ruleset/blob/f1e1e46e51faefbe75c79052d63437cc3c1a02b4/rules/0015-ossec_rules.xml#L63

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

I hope it helps.
Regards.

On Thursday, April 6, 2017 at 7:44:57 PM UTC+2, dan (ddpbsd) wrote:
>
> On Thu, Apr 6, 2017 at 1:28 PM, Rob Williams  > 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/' 
> > 
> > -- 
> > 
> > --- 
> > 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. 
>

-- 

--- 
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: Rule 510 is triggering events but logtest is not showing any rules that should be triggered

[dan (ddp)]

On Thu, Apr 6, 2017 at 1:28 PM, Rob Williams  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/'
>
> --
>
> ---
> 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.

[ossec-list] Re: Rule 510 is triggering events but logtest is not showing any rules that should be triggered

[Rob Williams]

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!

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/'
>

-- 

--- 
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.