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. On Thursday, December 21, 2017 at 8:21:27 AM UTC-5, dan (ddpbsd) wrote: > > 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> > > > On Tue, Dec 5, 2017 at 1:55 PM, Bruce Westbrook <[email protected] > <javascript:>> wrote: > > 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 > > > > > > On Wednesday, November 22, 2017 at 2:54:35 PM UTC-5, Maarten Broekman > wrote: > >> > >> 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 > >> > >> On Wednesday, November 22, 2017 at 2:02:28 PM UTC-5, Bruce Westbrook > >> wrote: > >>> > >>> 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] <javascript:>. > > 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.
