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.
