Hello , we have a running versión 4.1.4 wazuh.
We have different system devices reporting in realtime, such as Sonicwall Firewall 3600, in this case any failed login even good ones, are detected, and wazuh send an e-mail to “alarms.notifications@xxxxxxxxx” etc…
In this way, everything works fine, but we have experiencing problems to register, and process the same with an SQL server.
The fact, is we have been required to register LOGINS failed or OK in one MSQL server…
We have to clarify that our logfile archive.log is receiving infos perfectly, as example below, where a user “axe” try to make a LOGIN into SQL Management Studio with wrong password, and returns:
2021 May 04 00:14:02 (IPASRV_VPS001) 172.19.10.10->EventChannel {"win":{"system":{"providerName":"MSSQL$SQLEXPRESS","eventID":"18456","level":"0","task":"4","keywords":"0x90000000000000","systemTime":"2021-05-04T00:14:02.000000000Z","eventRecordID":"11930713","channel":"Application","computer":"IPASRV-VPS001","severityValue":"AUDIT_FAILURE","message":"\"Login failed for user 'axe'. Reason: Password did not match that for the login provided. [CLIENT: 172.19.10.10]\""},"eventdata":{"binary":"184800000E000000190000004900500041005300520056002D005600500053003000300031005C00530051004C0045005800500052004500530053000000070000006D00610073007400650072000000","data":"axa, Reason: Password did not match that for the login provided., [CLIENT: 172.19.10.10]"}}}
But when we use ossec-logtest, we ever get same result:

Except in case we just select the exact JSON chain (without date part) so since {“win ) :
{"win":{"system":{"providerName":"MSSQL$SQLEXPRESS","eventID":"18456","level":"0","task":"4","keywords":"0x90000000000000","systemTime":"2021-05-04T00:14:02.000000000Z","eventRecordID":"11930713","channel":"Application","computer":"IPASRV-VPS001","severityValue":"AUDIT_FAILURE","message":"\"Login failed for user 'axe'. Reason: Password did not match that for the login provided. [CLIENT: 172.19.10.10]\""},"eventdata":{"binary":"184800000E000000190000004900500041005300520056002D005600500053003000300031005C00530051004C0045005800500052004500530053000000070000006D00610073007400650072000000","data":"axe, Reason: Password did not match that for the login provided., [CLIENT: 172.19.10.10]"}}}
In this case, we get a perfect interpretation/segmentation or decoded JSON as shown below, and we can see a Rules_id:’60003’ detected and working, instead the Rule_id:’2501’ that we understand it’s processed through 0020-syslog_rules.xml we have attached too.

Our 0575-win-base_rules.xml is modified as shown, due to a recommendation found here –> https://groups.google.com/g/wazuh/c/PpiUMAvi_ac

To summit up, we are able to see archive.logs receiving infos, but nothing seems to be “processed” to execute the required ALARM and MAIL. In fact in alerts.log we never have seen NOTHING.
For the 0020-syslog_rules.xml , we have already tested even a 2401 RULE (before 2501) just to be processed first… But it doesn’t work.
<!-- Access control messages -->
<!-- By INGENS-NETWORKS ORIGINAL level "5"-->
<group name="syslog,access_control,">
<!--By INGENS NETWORKS -->
<rule id="2401" level="12" ignore="2501">
<field name="win.system.eventID">^18456$</field>
<options>alert_by_email</options>
<description>Password did not match that for the login provided</description>
</rule>
<!--By INGENS NETWORKS -->
<rule id="2501" level="5">
<match>FAILED LOGIN |authentication failure|</match>
<match>Authentication failed for|invalid password for|</match>
<match>LOGIN FAILURE|auth failure: |authentication error|</match>
<match>authinternal failed|Failed to authorize|</match>
<match>Wrong password given for|login failed|Auth: Login incorrect|</match>
<match>Failed to authenticate user</match>
<group>authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,gpg13_7.8,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
<description>syslog: User authentication failure.</description>
</rule>
<!-- By INGENS-NETWORKS -->
Even we tried to do it with 0395-sqlserver_decoders.xml but without success… (file added in this e-mail too)
REMEMBER THAT OUR SONICWALL ALARMS AND MAILS ARE WORKING PERFECT… 😊
Thanks in advance, and in case someone was experiencing something similar, we will be really grateful to be guided!
GRACIAS!
Maximo Dominguez
IT Manager | Barcelona
maximo.d...@ingens-networks.com
![]()
Telefono: +34 93 422 6655 ·· Fax: +34 93 422 6105
Ciutat de la Justicia –Edifici D
Avinguda Carrilet, 3, Planta 5
08902 Hospitalet de Llobregat - Barcelona
WEB | twitter | Linkedin | YouTube | Blog |