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.
