Whitelisting the IP of an internal vulnerability scanner

[Olivier Ragain]

Good morning,

I've been trying to whitelist the IP of my scanner so that I never get notifications from it and that alerts are ignored for it.

I've tried adding it to the whitelist in the ossec configuration file (And as I understand, that configuration is not used for the notification whitelisting)

I've tried adding as a list and then added to the ossec configuration

So, what is the best way to whitelist a scanner IP so that nothing sends email for it? Do I need to create a custom rule that matches all rule IDs and the IP of the scanner host to disable email notifications?

Thanks

[Bruce Westbrook]

Morning,

Couple of ways to do this for just a single IP address.  It depends on whether you just want to skip the emails alerts but still keep alerts in your database, or if you want to ignore them completely.

Examples assume you have your email alerts set to level 7 or above.  Note that <if_level> matches rules at the given level or anything above it.

To skip emails but still keep the alert data:

  <rule id="100101" level="15">
    <if_level>7</if_level>
    <options>no_email_alert</options>
    <srcip>10.10.10.10</srcip>
    <description>Do not send emails for our scanner alerts</description>
  </rule>

To ignore all rule matches completely, set your rule to level 0:

  <rule id="100101" level="0">
    <if_level>1</if_level>
    <srcip>10.10.10.10</srcip>
    <description>Ignoring all alerts triggered by our scanner</description>
  </rule>

Personally I use the second example, which ignores sending any alerts and doesn't even log them, but still logs any non-email events (levels 1-6) so I can still prove to an auditor that the scans are actually running against various hosts (some auditors want multiple proof points like that).

Hope that helps!

- Bruce

[Bruce Westbrook]

oops -- I made a typo.  The second example should be <if_level>7</if_level> too, not level 1.  

You can use level 1 but that will ignore everything from the source IP and not log anything at all.

[Olivier Ragain]

Great, thanks.

So I do need to add a rule for them, that is what i was not sure of.

I think I ll go with the second option as I also need to keep a trace for auditors.

Olivier

--

---
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/85801125-b8d7-471b-869c-adea3d36cf2e%40googlegroups.com.

--

Olivier

instream

manager IT Ops and Security

100-5335 Canotek Rd

Ottawa ON  K1J9L4

Phone: 855-521-1121, 126 

Mobile: 343-777-0403

[Binet, Valere (NIH/NIA/IRP) [C]]

The whitelist works with active response. If you have OSSEC blocking misbehaving IPs on your firewall, you definitely have to whitelist the scanner IP. Past experience with one scanner I won’t promote here has shown that you might have to also whitelist its FQDN.

If you just want to stop the deluge of emails, a local rule as shown by Bruce is the way to go.

 

Valère Binet

--

[Olivier Ragain]

Hi,

I ve configured ossec to load rules from a custom folder to avoid having to touch any of the other files and facilitate updates. Some rules that are in that custom folder work properly

So i've added the following in a custom rule file:

----

<group name="global,override,">
        <rule id="110000" level="0">

                <if_level>7</if_level>
                <options>no_email_alert</options>

                <srcip>my_scanner_ip</srcip>

                <description>Ignoring all alerts triggered by our scanner</description>
        </rule>

</group>

---

Unfortunately I am still getting alerts by email. How can I test that rule via the tester ?

Thanks

To view this discussion on the web visit https://groups.google.com/d/msgid/ossec-list/8716F0A9-5475-4E86-B26E-5B0142619AC5%40mail.nih.gov.

[Bruce Westbrook]

Since you created the rule as level="0", the <options>no_email_alert</options> line doesn't matter and you can leave it out.  When you set a rule to level 0 it doesn't log or alert anyway, plus level 0 doesn't get overridden by a higher level rule so that's not the issue.

Check the alert level of the alerts you're getting.  If they are lower than 7 then you have your OSSEC config alerting on lower level rules.  You'll just have to modify the rule's <if_level> to match your global alert level.  If you want to drop and not log anything you could just set it as <if_level>0</if_level>.

To test the rule, copy the content of the alert, and on your OSSEC server execute:

ossec-logtest -v

...then paste the alert content and hit [ENTER].  The output will walk through the rules it is checking against.  Use this output to help troubleshoot.

- Bruce

To unsubscribe from this group and stop receiving emails from it, send an email to ossec...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ossec-list/85801125-b8d7-471b-869c-adea3d36cf2e%40googlegroups.com.

--

---
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ossec-list/8716F0A9-5475-4E86-B26E-5B0142619AC5%40mail.nih.gov.

[Olivier Ragain]

Hi,

I've changed:

  <alerts>
    <log_alert_level>1</log_alert_level>
    <email_alert_level>8</email_alert_level>
  </alerts>

and i ve changed the rule to :

<group name="global,override,">
        <rule id="110000" level="8">

                <if_level>7</if_level>
                <options>no_email_alert</options>

                <srcip>my_ip_scanner</srcip>

                <description>Ignoring all alerts triggered by our scanner</description>
        </rule>
</group>

----

The alert is triggered by: Mar 10 20:00:13 a-sv-prd-oss-01 sshd[39101]: Bad protocol version identification '\026\003\001\003\241\001' from my_scanner_ip port 36632

----

The result of the test is:

**Phase 1: Completed pre-decoding.
       full event: 'Mar 10 20:00:13 a-sv-prd-oss-01 sshd[39101]: Bad protocol version identification '\026\003\001\003\241\001' from my_scanner_ip port 36632'
       hostname: 'a-sv-prd-oss-01'
       program_name: 'sshd'
       log: 'Bad protocol version identification '\026\003\001\003\241\001' from my_scanner_ip port 36632'

**Phase 2: Completed decoding.
       decoder: 'sshd'

**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: 5700 - SSHD messages grouped.
       *Rule 5700 matched.
       *Trying child rules.
    Trying rule: 5709 - Useless SSHD message without an user/ip and context.
    Trying rule: 5711 - Useless/Duplicated SSHD message without a user/ip.
    Trying rule: 5721 - System disconnected from sshd.
    Trying rule: 5722 - ssh connection closed.
    Trying rule: 5723 - SSHD key error.
    Trying rule: 5724 - SSHD key error.
    Trying rule: 5725 - Host ungracefully disconnected.
    Trying rule: 5727 - Attempt to start sshd when something already bound to the port.
    Trying rule: 5729 - Debug message.
    Trying rule: 5732 - Possible port forwarding failure.
    Trying rule: 5733 - User entered incorrect password.
    Trying rule: 5734 - sshd could not load one or more host keys.
    Trying rule: 5735 - Failed write due to one host disappearing.
    Trying rule: 5736 - Connection reset or aborted.
    Trying rule: 5707 - OpenSSH challenge-response exploit.
    Trying rule: 5701 - Possible attack on the ssh server (or version gathering).
       *Rule 5701 matched.
       *Trying child rules.
    Trying rule: 110000 - Ignoring all alerts triggered by our scanner

**Phase 3: Completed filtering (rules).
       Rule id: '5701'
       Level: '8'
       Description: 'Possible attack on the ssh server (or version gathering).'
**Alert to be generated.

------

So somehow that rule is being triggered but OSSEC does not know the source so it matches it ?

Should I just add a regular expression to the above rule so that it works whether on Source IP or on the text ?

Thanks

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/c71972c9-759a-4594-8d18-01a6d1ab5562%40googlegroups.com.

[Bruce Westbrook]

Olivier,

I tested this and it works just fine.  

Not sure why you decided to change the rule level to 8 -- it should be either 0 to drop and not log, or 15 to log.  The reason is to ensure that the rule doesn't get overridden by another matching rule.  Level 0 always trumps other rules no matter what other rule levels are matched, while level 15 is the highest and should not get overridden unless there's a matching child rule to it at the same level.  Making it level 8 opens up the possibility that it can get overridden by a higher rule level.  

Here's how I explain it in my own documentation.  This explanation may or may not make sense to you, but it works for the way my mind operates.  :-)

Rule Order / Heirachy – The order in which rules are evaluated can seem somewhat complex: 

1.      When a rule matches a log record, if it has no children then that is the final rule match.  Otherwise, the child rules of that rule are evaluated.  

2.      Child rules are evaluated in the order of descending severity level with the exception that level zero child rules are looked at first.

3.      Once a child rule matches, none of the other child rules of the same parent will be considered.  Instead, analysis drops down to the level of checking child rules of the child that just matched.

4.      This process continues until a rule matches that has no children or no matching children.

5.      When multiple children of the same severity level are involved, they are evaluated in load order (the order the rule files are loaded and the order the rules appear in the rule files).

This is what worked for me:

ossec.conf:  

  <!-- Default Log and Email Alert Levels  -->
  <alerts>
    <log_alert_level>1</log_alert_level>
    <email_alert_level>7</email_alert_level>
  </alerts>

local_rules.xml:  You could set this to <if_level> 1 to match all alerts generated but since you were concerned about the emails I just matched at the email_alert_level that is set in ossec.conf, which is 7.  You could also set the rule level to "0" instead of "15".  Setting to 15 means it will still log but not alert (due to the no_email_alert option), while setting to 0 will not log any matches.

<group name="global,override,">
  <rule id="110000" level="15">

    <if_level>7</if_level>
    <options>no_email_alert</options>

    <srcip>192.168.1.100</srcip>

    <description>Ignoring all alerts triggered by our scanner</description>
  </rule>
</group>

ossec-logtest -v

2020/03/11 09:03:48 ossec-testrule: INFO: Reading decoder file etc/asa_decoder.xml.
2020/03/11 09:03:48 ossec-testrule: INFO: Reading decoder file etc/decoder.xml.
2020/03/11 09:03:48 ossec-testrule: INFO: Reading the lists file: 'etc/lists/nessus_cloud.whitelist'
2020/03/11 09:03:48 ossec-testrule: INFO: Started (pid: 20120).
ossec-testrule: Type one log per line.


Mar 10 20:00:13 a-sv-prd-oss-01 sshd[39101]: Bad protocol version identification '\026\003\001\003\241\001' from 192.168.1.100 port 36632




**Phase 1: Completed pre-decoding.
       full event: 'Mar 10 20:00:13 a-sv-prd-oss-01 sshd[39101]: Bad protocol version identification '\026\003\001\003\241\001' from 192.168.1.100 port 36632'
       hostname: 'a-sv-prd-oss-01'
       program_name: 'sshd'
       log: 'Bad protocol version identification '\026\003\001\003\241\001' from 192.168.1.100 port 36632'

**Phase 2: Completed decoding.
       decoder: 'sshd'

       srcip: '192.168.1.100'
       srcport: '36632'

**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.
    Trying rule: 5711 - Useless/Duplicated SSHD message without a user/ip.
    Trying rule: 5721 - System disconnected from sshd.
    Trying rule: 5722 - ssh connection closed.
    Trying rule: 5723 - SSHD key error.
    Trying rule: 5724 - SSHD key error.
    Trying rule: 5725 - Host ungracefully disconnected.
    Trying rule: 5727 - Attempt to start sshd when something already bound to the port.
    Trying rule: 5729 - Debug message.
    Trying rule: 5732 - Possible port forwarding failure.
    Trying rule: 5733 - User entered incorrect password.
    Trying rule: 5734 - sshd could not load one or more host keys.
    Trying rule: 5735 - Failed write due to one host disappearing.
    Trying rule: 5736 - Connection reset or aborted.

    Trying rule: 5750 - sshd could not negotiate with client.
    Trying rule: 5756 - sshd subsystem request failed.
    Trying rule: 100101 - Ignoring rules triggered by Nessus scanning server
    Trying rule: 110000 - Ignoring all alerts triggered by our scanner
       *Rule 110000 matched.

**Phase 3: Completed filtering (rules).

       Rule id: '110000'
       Level: '0'
       Description: 'Ignoring all alerts triggered by our scanner'

Now if I set the rule to level="8" like you have, it still works for me just fine.  Since you're using a separate rule file and both rules 5701 and 11000 are set to the same level, my guess is that it's the order in which your rules are loading - but I can't say for sure.  But simply set your rule to either level="0" or level ="15" and you should be fine.

- Bruce

To view this discussion on the web visit https://groups.google.com/d/msgid/ossec-list/c71972c9-759a-4594-8d18-01a6d1ab5562%40googlegroups.com.

[Olivier Ragain]

Hi Bruce,

Thanks for the clarifications, got mixed up a bit on the if_level and log level. I've set it back to 0.

So now the funny thing is as follow:

* I know my rules work because some of the test actually trigger the rule,

* But the ssh one does not for some reason

The only difference i see is that somehow your decoder is finding the source ip on the SSH string test but not mine.

Best regards,

Config:

  <alerts>
    <log_alert_level>1</log_alert_level>
    <email_alert_level>8</email_alert_level>
  </alerts>

Rule: (Have not changed the email alert yet, still pondering logging everything or just logging 1-6 for auditors)

        <rule id="110000" level="0">

                <if_level>8</if_level>
                <options>no_email_alert</options>
                <srcip>172.17.0.101</srcip>

                <description>Ignoring all alerts triggered by our scanner</description>
        </rule>

Test 1: (triggers the rule)

172.17.0.101 - - [10/Mar/2020:20:00:10 +0000] "GET / HTTP/1.1" 200 11229 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0"


**Phase 1: Completed pre-decoding.
       full event: '172.17.0.101 - - [10/Mar/2020:20:00:10 +0000] "GET / HTTP/1.1" 200 11229 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0"'
       hostname: 'a-sv-prd-oss-01'
       program_name: '(null)'
       log: '172.17.0.101 - - [10/Mar/2020:20:00:10 +0000] "GET / HTTP/1.1" 200 11229 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0"'

**Phase 2: Completed decoding.
       decoder: 'web-accesslog'
       srcip: '172.17.0.101'
       url: '/'
       id: '200'

**Rule debugging:
    Trying rule: 4 - Generic template for all web rules.
       *Rule 4 matched.
       *Trying child rules.
    Trying rule: 31100 - Access log messages grouped.
       *Rule 31100 matched.
       *Trying child rules.
    Trying rule: 31108 - Ignored URLs (simple queries).
       *Rule 31108 matched.

       *Trying child rules.
    Trying rule: 110000 - Ignoring all alerts triggered by our scanner

       *Rule 110000 matched.

**Phase 3: Completed filtering (rules).
       Rule id: '110000'
       Level: '0'
       Description: 'Ignoring all alerts triggered by our scanner'

Test 2:

Mar 10 20:00:13 a-sv-prd-oss-01 sshd[39101]: Bad protocol version identification '\026\003\001\003\241\001' from 172.17.0.101 port 36632


**Phase 1: Completed pre-decoding.
       full event: 'Mar 10 20:00:13 a-sv-prd-oss-01 sshd[39101]: Bad protocol version identification '\026\003\001\003\241\001' from 172.17.0.101 port 36632'
       hostname: 'a-sv-prd-oss-01'
       program_name: 'sshd'
       log: 'Bad protocol version identification '\026\003\001\003\241\001' from 172.17.0.101 port 36632'

**Phase 2: Completed decoding.
       decoder: 'sshd'

**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: 5700 - SSHD messages grouped.
       *Rule 5700 matched.
       *Trying child rules.
    Trying rule: 5709 - Useless SSHD message without an user/ip and context.
    Trying rule: 5711 - Useless/Duplicated SSHD message without a user/ip.
    Trying rule: 5721 - System disconnected from sshd.
    Trying rule: 5722 - ssh connection closed.
    Trying rule: 5723 - SSHD key error.
    Trying rule: 5724 - SSHD key error.
    Trying rule: 5725 - Host ungracefully disconnected.
    Trying rule: 5727 - Attempt to start sshd when something already bound to the port.
    Trying rule: 5729 - Debug message.
    Trying rule: 5732 - Possible port forwarding failure.
    Trying rule: 5733 - User entered incorrect password.
    Trying rule: 5734 - sshd could not load one or more host keys.
    Trying rule: 5735 - Failed write due to one host disappearing.
    Trying rule: 5736 - Connection reset or aborted.

    Trying rule: 110000 - Ignoring all alerts triggered by our scanner

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/7441f0ee-9326-4e3d-980d-5da9dc5111ca%40googlegroups.com.

[Olivier Ragain]

Hi,

I've tried adding the following decoder:

<decoder name="ssh-source-ip-decoder">
  <prematch>\s</prematch>
  <regex >^from (\S+) port (\S+)$</regex>
  <order>srcip,dstport</order>
</decoder>

But I end up with the following errors in the log:

2020/03/11 14:28:37 ossec-testrule: INFO: Reading decoder file decoders/ssh_decoder.xml.
2020/03/11 14:28:37 ossec-analysisd(2106): ERROR: Error adding decoder plugin.
2020/03/11 14:28:37 ossec-testrule: INFO: Reading the lists file: 'lists/approved_scanners_list'
2020/03/11 14:28:37 ossec-analysisd: Invalid decoder name: 'pam'.
2020/03/11 14:28:37 ossec-testrule(1220): ERROR: Error loading the rules: 'pam_rules.xml'.

How can I get more information?

Thanks