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>
On Monday, November 20, 2017 at 3:44:16 PM UTC-5, Bruce Westbrook wrote:
>
> 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
>
--
---
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
