Hi Scott,
Thank you for your kind words. I'm more than happy to help.
Best Regards,
Juan Carlos Tello
On Friday, August 14, 2020 at 9:01:10 PM UTC+2 saw...@gmail.com wrote:
> 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 <juancarl...@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+...@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/700bd7e9-cc5a-421d-a1a2-73760b9492a3n%40googlegroups.com.
