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.  :-)*



On Wednesday, November 22, 2017 at 6:45:32 AM UTC-5, Maarten Broekman wrote:
>
> 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
>
> On Tuesday, November 21, 2017 at 10:42:23 AM UTC-5, Bruce Westbrook wrote:
>>
>> 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?
>>
>>

-- 

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