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 On Thursday, December 21, 2017 at 10:16:01 AM UTC-5, Bruce Westbrook wrote: > > 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]> >> 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]. >> > 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.
