Re: [ossec-list] Re: Rule 510 is triggering events but logtest is not showing any rules that should be triggered
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) > > > 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 >>> <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: >>> >>> >>> 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. @time
Re: [ossec-list] Re: Rule 510 is triggering events but logtest is not showing any rules that should be triggered
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 > <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: > > > 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. >> >> >>
Re: [ossec-list] Re: Rule 510 is triggering events but logtest is not showing any rules that should be triggered
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: 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 <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: >> > >> > > 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 perm
Re: [ossec-list] Re: Rule 510 is triggering events but logtest is not showing any rules that should be triggered
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.
[ossec-list] Re: Rule 510 is triggering events but logtest is not showing any rules that should be triggered
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.
