Dropping all log lines related to a vulnerability scanner

[Scott Wozny]

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

[Juan Carlos Tello]

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

[Scott Wozny]

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

--

---
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/ossec-list/bc292d50-b529-4ce2-9595-087231450d2bo%40googlegroups.com.

[juancarl...@wazuh.com]

Hi Scott,

Thank you for your kind words. I'm more than happy to help.

Best Regards,

Juan Carlos Tello