Rule Exception - How?

[Bruce Westbrook]

Looking for help on making an exception for a specific username that's continually failing logons to a database.  The DBAs are slammed and unable to get to this for a few days.  In the meantime, I'm getting slammed with an excessive amount of email alerts (500+) from rule #18180 every day.

My goal is to:

1. Stop this one "USERNAME" on this one "SERVER" from triggering email alerts
2. Still continue logging the alerts (just not emailing)
3. Still allow all other failed logons to count up and email alerts

As such, I can't just simply stop sending emails from rule #18180 since that would stop alerts on all other activity, not just this one. 

I cannot find a way to overwrite rule #18180 with a <match> exception, as there doesn't appear to be a way to make exceptions for anything but source and destination IP addresses.  Nor can I find a way to remove a <group> from a matched rule so I could <match> on the "USERNAME" and "SERVER" and remove it from the "win_authentication_failed" group, thereby keeping #18180 from seeing it.

Here are some details:

Rule #18180 is first triggered by failed logins and adds the group "win_authentication_failed":

  <rule id="18180" level="5">
    <if_sid>18105</if_sid>
    <id>^18456$</id>
    <group>win_authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,</group>
    <description>MS SQL Server Logon Failure.</description>
  </rule>

  

Here's a sample (sanitized) actual alert from rule #18180:

 ** Alert 1510854237.1318112395: - windows,win_authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,
 2017 Nov 16 12:43:57 (SERVER) any->WinEvtLog
 Rule: 18180 (level 5) -> 'MS SQL Server Logon Failure.'
 User: (no user)
 2017 Nov 16 12:43:56 WinEvtLog: Application: AUDIT_FAILURE(18456): MSSQLSERVER: (no user): no domain: SERVER.DOMAIN.LOCAL: Login failed for user 'USERNAME'. Reason: Failed to open the explicitly specified database 'DATABASE'. [CLIENT: nnn.nnn.nnn.nnn]  

   

Once OSSEC sees six of these "win_authentication_failed" alerts within four minutes, rule #18152 triggers:

  <rule id="18152" level="10" frequency="6" timeframe="240">
    <if_matched_group>win_authentication_failed</if_matched_group>
    <description>Multiple Windows Logon Failures.</description>
    <group>authentication_failures,pci_dss_10.2.4,pci_dss_10.2.5,pci_dss_11.4,</group>
  </rule>

  

Can anyone point me in the right direction on excluding this particular alert (still logging though) from being seen by rule #18152, without impacting that rule's ability to email alerts for all other activity?

- Bruce

[Maarten Broekman]

What you probably want to do is override 18180 by having it set the level below the email threshold and NOT add the win_authentication_failed group for that particular alert and then have a new rule that adds the win_authentication_failed group for any alerts that still match 18105.

  <rule id="18180" level="1">

    <if_sid>18105</if_sid>
    <id>^18456$</id>

    <match>BAD_NOT_BAD_USERNAME</match>
    <group>pci_dss_10.2.4,pci_dss_10.2.5,</group>
    <description>MS SQL Server Logon Failure by known 'not bad'</description>
  </rule>

  <rule id="18180+n" level="5">

    <if_sid>18105</if_sid>
    <id>^18456$</id>

    <group>win_authentication_failure,</group>

    <description>MS SQL Server Logon Failure.</description>
  </rule>

[Bruce Westbrook]

Okay, thanks for the idea Maarten.  It didn't occur to me to try reversing the logic like that and overwriting the original rule like that, then creating a new rule that essentially does the same thing as the original rule.  Assuming there's not an order of operation issue with this, I expect that would do the trick.

I'll report back one way or the other.  It happens so frequently that I'm sure to know the result soon.  Thanks!

--

---
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bruce Westbrook]

Unfortunately that didn't work Maarten.  After following that logic I am still getting all the email alerts for that account again.  And yes, I restarted the OSSEC daemons after adding the rules  :-)

However, when I run the log entry against ossec-logtest, it appears to do what I want by matching my overwritten #18180 rule -- yet in reality it still sends an email due to it matching the #18152 composite rule (I'm not sure how to use ossec-logtest to test a composite rule with multiple log entries).

Here are the rules I added:

  <!-- Rewrite rule #18180 to narrow down to bad SQL account and not add the 'win_authentication_failed' group -->

  <rule id="18180" level="5" overwrite="yes">

    <if_sid>18105</if_sid>
    <id>^18456$</id>

    <match>Login failed for user 'USERNAME'</match>
    <group>pci_dss_10.2.4,pci_dss_10.2.5,</group>
    <description>MS SQL Server Logon Failure for 'dpa' only</description>
  </rule>

  <!-- Add new rule to take the place of rule #18180 after matching our bad SQL account -->
  <rule id="100150" level="5">

    <if_sid>18105</if_sid>
    <id>^18456$</id>
    <group>win_authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,</group>

    <description>MS SQL Server Logon Failure for 'dpa' only</description>
  </rule>

Here's the output from ossec-logtest:

2017/11/21 10:31:13 ossec-testrule: INFO: Reading local decoder file.
2017/11/21 10:31:13 ossec-testrule: INFO: Started (pid: 27437).
ossec-testrule: Type one log per line.


2017 Nov 16 12:43:56 WinEvtLog: Application: AUDIT_FAILURE(18456): MSSQLSERVER: (no user): no domain: SERVER: Login failed for user 'USERNAME'. Reason: Failed to open the explicitly specified database 'DATABASE'. [CLIENT: nnn.nnn.nnn.nnn]

**Phase 1: Completed pre-decoding.
       full event: '2017 Nov 16 12:43:56 WinEvtLog: Application: AUDIT_FAILURE(18456): MSSQLSERVER: (no user): no domain: SERVER: Login failed for user 'USERNAME'. Reason: Failed to open the explicitly specified database 'DATABASE'. [CLIENT: nnn.nnn.nnn.nnn]'
       hostname: 'SERVER'
       program_name: '(null)'
       log: '2017 Nov 16 12:43:56 WinEvtLog: Application: AUDIT_FAILURE(18456): MSSQLSERVER: (no user): no domain: SERVER: Login failed for user 'USERNAME'. Reason: Failed to open the explicitly specified database 'DATABASE'. [CLIENT: nnn.nnn.nnn.nnn]'


**Phase 2: Completed decoding.
       decoder: 'windows'
       status: 'AUDIT_FAILURE'
       id: '18456'
       extra_data: 'MSSQLSERVER'
       dstuser: '(no user)'
       system_name: 'SERVER'


**Phase 3: Completed filtering (rules).
       Rule id: '18180'
       Level: '5'
       Description: 'TEMP NOISE REDUCTION: MS SQL Server Logon Failure for 'USERNAME''
**Alert to be generated.

What am I still missing?  Any ideas?

[Maarten Broekman]

Two questions...

 At what level do you get emails from the alerts? I noticed you didn't change the level of the 18180 from a '5'.

 Do you have a sanitized version of the 'new' alert from the alert log (as opposed to the ossec-logtest output)? That will show the groups on the alert.

 I ask because the ossec-logtest output seems to show a different description of 18180 than what should be there from the configured (and displayed) rules you pasted.

Maarten

[Bruce Westbrook]

My apologies, you're right -- I pasted the wrong info, sorry about that.  I was also editing things like the description at the same time, therefore the lack of consistency you identified.

First answer -- alerts are sent at level 7 or above.  The parent rule #18180 is not the one sending the alert as it's already a lower alert level (level=5).  It's the composite child rule #18152 that does that, which is set to level=10.  That rule is looking for <if_matched_group>win_authentication_failed</if_matched_group>, which based on your suggestion I removed by overwriting rule #18180.  Yet it's still alerting.

Second answer -- here's a recent alert directly from the alerts.log file, showing rule #18152 still triggering.

** Alert 1511375499.1421236953: - local,syslog,authentication_failures,pci_dss_10.2.4,pci_dss_10.2.5,pci_dss_11.4,
2017 Nov 22 13:31:39 (SERVER) any->WinEvtLog
Rule: 18152 (level 10) -> 'Multiple Windows Logon Failures.'
User: (no user)
2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): MSSQLSERVER: (no user): no domain: SERVER: Login failed for user 'USERNAME'. Reason: Failed to open the explicitly specified database 'DATABASE'. [CLIENT: nnn.nnn.nnn.nnn]
2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): MSSQLSERVER: (no user): no domain: SERVER: Login failed for user 'USERNAME'. Reason: Failed to open the explicitly specified database 'DATABASE'. [CLIENT: nnn.nnn.nnn.nnn]
2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): MSSQLSERVER: (no user): no domain: SERVER: Login failed for user 'USERNAME'. Reason: Failed to open the explicitly specified database 'DATABASE'. [CLIENT: nnn.nnn.nnn.nnn]
2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): MSSQLSERVER: (no user): no domain: SERVER: Login failed for user 'USERNAME'. Reason: Failed to open the explicitly specified database 'DATABASE'. [CLIENT: nnn.nnn.nnn.nnn]
2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): MSSQLSERVER: (no user): no domain: SERVER: Login failed for user 'USERNAME'. Reason: Failed to open the explicitly specified database 'DATABASE'. [CLIENT: nnn.nnn.nnn.nnn]
2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): MSSQLSERVER: (no user): no domain: SERVER: Login failed for user 'USERNAME'. Reason: Failed to open the explicitly specified database 'DATABASE'. [CLIENT: nnn.nnn.nnn.nnn]
2017 Nov 22 13:31:36 WinEvtLog: Application: AUDIT_FAILURE(18456): MSSQLSERVER: (no user): no domain: SERVER: Login failed for user 'USERNAME'. Reason: Failed to open the explicitly specified database 'DATABASE'. [CLIENT: nnn.nnn.nnn.nnn]

If the first line of the alert is an indication of the groups it triggered on, I'm even more confused as it doesn't list the group that the rule is configured to trigger from, win_authentication_failed.  I'm obviously not understanding something here.

Here are the rules I created, based on your suggestion to overwrite #18180 to match only to the problematic log entry and NOT give it the group triggered by rule #18152, then add a custom rule that is a replacement for the original #18180 rule:

  <rule id="18180" level="5" overwrite="yes">
    <if_sid>18105</if_sid>
    <id>^18456$</id>

    <match>Login failed for user 'USER'</match>
    <group>pci_dss_10.2.4,pci_dss_10.2.5,</group>
    <description>TEMP NOISE REDUCTION: MS SQL Server Logon Failure for 'USER'</description>
  </rule>

  <rule id="100150" level="5">
    <if_sid>18105</if_sid>
    <id>^18456$</id>
    <group>win_authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,</group>

    <description>MS SQL Server Logon Failure - custom rule for #18180</description>
  </rule>

From what I can see, it looks like the problematic log entries are indeed hitting the revised rule #18180, which means they should not be getting tagged with the group win_authentication_failed -- yet rule #18152 still fires off based on these events still somehow being tagged with that group.  I'm obviously not understanding something about how this is working since it's still triggering emails.

I appreciate any further insight you or anyone can provide, thanks!

As a heads up, if you're not in the USA we have a 4-day weekend with Thanksgiving starting, so I don't plan to be looking at this again until Monday.  :-)

[Maarten Broekman]

That's bizarre. You can see in the group list in the alert that the win_authentication_failed group isn't listed so I'm not sure why it would end up in the aggregate. Very odd. I know it's going even further afield, but changing the aggregate from if_matched_group to <if_matched_sid>100150</if_matched_sid> might be needed. It might be possible to just add if_matched_sid as another condition, but I'm not sure.

--Maarten

[Bruce Westbrook]

Just to put some closure to this thread, I had to resort to simply ignoring emails for rule #18152, the rule triggered by excessive win_authentication_failed group hits.  I simply overwrote that rule and added the <options>no_email_alert</options> option to it.  Although not what I was hoping to achieve it has stemmed the large amount of alert emails until the underlying issue on the database is resolved.  It does add more overhead in that I have to check the console periodically since no emails for this are being sent, but good enough as a temporary workaround.

I didn't want to change the aggregate to a SID, as there are other win_authentication_failed hits from other sids that I didn't want to end up missing.

If anyone does have an answer to making this one-off exception successfully work, I'm all ears - but for now it's good enough.  Thanks for your input Maarten.

- Bruce

[dan (ddp)]

I don't have a way to test this nicely, but this seems to be ok with
ossec-logtest:
<rule id="900002" level="5">
<if_sid>18180</if_sid>

<match>Login failed for user 'USERNAME</match>

<description>Ignore this guy.</description>
</rule>

> --
>
> ---
> 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.

[Bruce Westbrook]

Thanks Dan, but unfortunately it didn't work for me.  That's actually what I originally tried to do and it does look like it works with log-test, but when put into production it still somehow triggered rule 18152.  Although 18180 was ignored it was like the counter for the composite rule 18152 still incremented from it.

I might revisit this again at some point in the future but for now I'm good with the way it is.  Thanks.

[Maarten Broekman]

Bruce,

  If there's no requirement for the level 5 in the rule, I would suggest trying to set the ignorable event a level 0. Level 0 will be dropped on the floor. Almost anything higher will continue to be processed. I forget if you had tried this already though.

--Maarten