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 
> <https://documentation.wazuh.com/current/user-manual/ruleset/dynamic-fields.html>.
>  
> 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.
>
>
>
> 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:
>>
>>   <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
>>
>>
>>
>> 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 
>>> <https://github.com/wazuh/wazuh-ruleset/blob/f1e1e46e51faefbe75c79052d63437cc3c1a02b4/rules/0015-ossec_rules.xml#L63>,
>>>  
>>> 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!
>>>
>>>
>>> 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 <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. 
>>>>>
>>>>> > 
>>>>> > **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: 
>>>>> >> 
>>>>> >> <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> 
>>>>> > 
>>>>> > 
>>>>> > 
>>>>> > 
>>>>> > -- 
>>>>> > 
>>>>> > --- 
>>>>> > 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.

Reply via email to