Juan Carlos,
Thanks VERY much for your detailed explanation. I now see where my logical
fallacy was. I had assumed that the purpose of level 0 rules was solely to
discard log lines of no forensic interest but now that I’ve looked at the
rules you pointed out I understand they’re ALSO for routing purposes. Part
of me wonders why those purposes would be conflated, but I (quite
admittedly) don’t have a deep understanding of what’s going on under the
hood with OSSEC so I’ll simply accept it as a fact of life and write my
rules with this information in mind.
Also, thank you for the tips on more efficient rule configuration. I was
hoping originally to simply have one “set it and forget it” rule for all
log data related to vulnerability scans, but with your explanation I see
now how that could be highly inefficient. I’ll have to look at the effects
of my scans in greater detail and see if I can make things more efficient
for the engine without making them a lot LESS efficient for me. :)
Much obliged,
Scott
On Tue, Aug 11, 2020 at 6:01 PM Juan Carlos Tello <
juancarlos.te...@wazuh.com> wrote:
> Hi Scott,
> Indeed all level 0 rules are considered for matching first, but if the
> level is the same, the order will be decided based on the rules list in
> /var/ossec/etc/ossec.conf file.
> In this case it is first matching rule 1 ("*Generic template for all
> syslog rules*" which is in the first file specified in ossec.conf:
> rules_config.xml), then it goes on to test rules which are children of
> rule 1, until it coincides with rule 5700 and finally 5712 which is a child
> of 5700.
>
> Adding the <if_level>1</if_level> makes it so it is included in the
> matching options of every rule with that level, so after matching rules 1
> and 5700 it is taken into consideration before rule 5712. Note that rule
> 5700 is level 0 and is part of the sshd_rules.xml file which is loaded
> 3rd by default, whereas local_rules.xml is loaded last.
>
> A great way to verify what the analysis engine is doing is to use the *-v
> * modifier of *ossec-logtest* which will provide a step-by-step
> explanations of the rules that were attempted to be tested. For example:
> echo 'Jul 17 23:33:06 web1 sshd[12133]: Invalid user OPERATOR from
> 192.168.1.209 port 36916' | /var/ossec/bin/ossec-logtest -v
> 2020/08/11 21:46:23 ossec-testrule: INFO: Reading local decoder file.
> 2020/08/11 21:46:23 ossec-testrule: INFO: Started (pid: 5555).
> ossec-testrule: Type one log per line.
>
> **Phase 1: Completed pre-decoding.
> full event: 'Jul 17 23:33:06 web1 sshd[12133]: Invalid user
> OPERATOR from 192.168.1.209 port 36916'
> hostname: 'web1'
> program_name: 'sshd'
> log: 'Invalid user OPERATOR from 192.168.1.209 port 36916'
>
> **Phase 2: Completed decoding.
> decoder: 'sshd'
> srcip: '192.168.1.209'
>
> **Rule debugging:
> Trying rule: 1 - Generic template for all syslog rules.
> *Rule 1 matched.
> *Trying child rules.
> Trying rule: 5500 - Grouping of the pam_unix rules.
> Trying rule: 5556 - unix_chkpwd grouping.
> Trying rule: 5700 - SSHD messages grouped.
> *Rule 5700 matched.
> *Trying child rules.
> Trying rule: 5709 - Useless SSHD message without an user/ip and
> context.
> * ... removed lines for brevity ...*
> Trying rule: 5710 - Attempt to login using a non-existent user
> *Rule 5710 matched.
> *Trying child rules.
> Trying rule: 5712 - SSHD brute force trying to get access to the
> system.
> Trying rule: 40111 - Multiple authentication failures.
> Trying rule: 51004 - dropbear brute force attempt.
>
> **Phase 3: Completed filtering (rules).
> Rule id: '5710'
> Level: '5'
> Description: 'Attempt to login using a non-existent user'
> **Alert to be generated.
>
>
> Also note that having <if_level>1</if_level> is not ideal because this
> will try to match your custom rule every time a rule level 1 is matched,
> possibly even more than once for each event analyzed.
> Instead I would suggest either making it a child rule of the different
> rules usually triggered by the vulnerability scanner or placing it in a
> file that is loaded after rules_config.xml whilst being a child of rule 1.
>
> For example run the following commands:
> cat > /var/ossec/rules/vulnerability_scanner_custom.xml <<\EOF
> <group name="custom">
> <rule id="100002" level="0">
> <srcip>192.168.1.209</srcip>
> <if_sid>1</if_sid>
> <description>Ignore the local vulnerability scanner</description>
> </rule>
> </group>
> EOF
> chown root:ossec /var/ossec/rules/vulnerability_scanner_custom.xml
>
> And then edit /var/ossec/etc/ossec.conf so your custom rule file is near
> the beginning:
> <ossec_config>
> <global>
> <email_notification>no</email_notification>
> </global>
>
> <rules>
> <include>rules_config.xml</include>
> <include>vulnerability_scanner_custom.xml</include>
> <include>pam_rules.xml</include>
> ...
>
>
> Let me know if this solves your question.
> Best Regards,
> Juan Carlos Tello
>
>
>
>
> On Saturday, July 18, 2020 at 2:14:49 AM UTC+2, Scott Wozny wrote:
>>
>> This topic was addressed on the list earlier this year, but I had a
>> specific question in regards to how I'm implementing it.
>>
>> Based upon the suggestions in the email archive, a howto on this topic
>> and the documentation on ossec.net, I added the following rule to
>> /var/ossec/rules/local_rules.xml which should be pretty self-explanatory.
>>
>> <rule id="100002" level="0">
>> <srcip>192.168.1.209</srcip>
>> <description>Ignore the local vulnerability scanner</description>
>> </rule>
>>
>> After I restarted OSSEC, vulnerability scans kept producing a flood of
>> alerts and emails. I ran some of the log lines produced through
>> /var/ossec/bin/ossec-logtest like this one:
>>
>> Jul 17 23:33:06 web1 sshd[12133]: Invalid user OPERATOR from 192.168.1.209
>> port 36916
>>
>>
>> And I got:
>>
>> **Phase 1: Completed pre-decoding.
>> full event: 'Jul 17 23:33:06 web1 sshd[12133]: Invalid user
>> OPERATOR from 192.168.1.209 port 36916'
>> hostname: 'web1'
>> program_name: 'sshd'
>> log: 'Invalid user OPERATOR from 192.168.1.209 port 36916'
>>
>> **Phase 2: Completed decoding.
>> decoder: 'sshd'
>> srcip: '192.168.1.209'
>>
>> **Phase 3: Completed filtering (rules).
>> Rule id: '5710'
>> Level: '5'
>> Description: 'Attempt to login using a non-existent user'
>> **Alert to be generated.
>>
>> So obviously my ignore rule is not working. I checked
>> https://www.ossec.net/docs/docs/syntax/head_rules.html and it pretty
>> clearly says:
>>
>> First, the rules with 0 levels are tried, and then all the other rules in
>> a decreasing order by their level.
>>
>> So it appears I've done everything right, but it's not working. Looking
>> at the suggestions on how to do this on this list and elsewhere, I decided
>> to add a level check and changed the rule to this:
>>
>> <rule id="100002" level="0">
>> <srcip>192.168.1.209</srcip>
>> <if_level>1</if_level>
>> <description>Ignore the local vulnerability scanner</description>
>> </rule>
>>
>> And now on the same log line I get this:
>>
>> **Phase 1: Completed pre-decoding.
>> full event: 'Jul 17 23:33:06 web1 sshd[12133]: Invalid user
>> OPERATOR from 192.168.1.209 port 36916'
>> hostname: 'web1'
>> program_name: 'sshd'
>> log: 'Invalid user OPERATOR from 192.168.1.209 port 36916'
>>
>> **Phase 2: Completed decoding.
>> decoder: 'sshd'
>> srcip: '192.168.1.209'
>>
>> **Phase 3: Completed filtering (rules).
>> Rule id: '100002'
>> Level: '0'
>> Description: 'Ignore the local vulnerability scanner'
>>
>>
>> And the system no longer generates alerts and emails form the scan.
>>
>> My question is, is this a bug or did I miss something in the documenation
>> that says srcip alone isn't enough to create a rule match (or a level 0
>> rule match) or have I done something else boneheaded? I saw in other
>> examples that if_sid will also make a srcip level 0 match work so are there
>> particular combinations that work or is there a reason srcip alone isn't
>> sufficient (or, as I said, is this just a bug)?
>>
>> I'm running version 3.6.0 installed from the source tarball off the
>> ossec.net website.
>>
>> Any suggestions or advice would be appreciated.
>>
>> Thanks,
>>
>> Scott
>>
> --
>
> ---
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ossec-list/bc292d50-b529-4ce2-9595-087231450d2bo%40googlegroups.com
> <https://groups.google.com/d/msgid/ossec-list/bc292d50-b529-4ce2-9595-087231450d2bo%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
---
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ossec-list/CACUKT_o1bi6Ad_uTieFiGZYqi0AKz%3Dfvgx2W0F4a49QSDrEgaQ%40mail.gmail.com.
