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!

On Tue, Nov 21, 2017 at 9:20 AM, Maarten Broekman <
[email protected]> wrote:

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

-- 

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

Reply via email to