Disable mfe 5501 default wazuh Alert

[Saddique Khan]

I am facing the same issue with mfe user. I want to disable mfe logs in wazuh logging as it is creating unnecessary alerts wazuh. This is the full_log for my wazuh.

Aug 25 11:00:02 HOSTNAME sudo[1108373]: pam_unix(sudo:session): session opened for user mfe by (uid=0).

I have deployed the wazuh on kubernetes cluster. It is working fine. There are four pods for it. Manager, worker, indexer and dashboard. I created the following custom rule to disable mfe user alert.

<group name="pam,syslog,"> <rule id="101101" level="0"> <if_sid>5501</if_sid> <regex>^ mfe</regex> <description>Ignore sudo auth for mfe user.</description> <options>no_log</options> <group>pci_dss_10.2.5,pci_dss_10.2.2,gpg13_7.6,gpg13_7.8,gpg13_7.13,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,nist_800_53_AC.6,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3</group> </rule> </group>

I attached to the manager container or pod on /var/ossec/etc/rules/local_rules.xml location. There is no error showing up in the logs as well but i still see mfe user alerts.

If for anyone the custom rule is working, please contribute. Any help will be appreciated. Do i need to add any other configuration? any issue with my custom rule. even alternate solution will be appreciated.

Regards,
Saddique Khan

[Nicolas Osvaldo Fernandez]

Hello, nice to greet you.

The rule you created is fine except for the regex you applied. Note that the ^ character implies that only if the event starts with "mfe" the alert will be executed. For it to work for you, you just have to indicate mfe. For example:

  <rule id="101101" level="0">

    <if_sid>5501</if_sid>

    <regex>mfe</regex>

    <description>Ignore sudo auth for mfe user.</description>
    <options>no_log</options>
    <group>pci_dss_10.2.5,pci_dss_10.2.2,gpg13_7.6,gpg13_7.8,gpg13_7.13,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,nist_8 00_53_AC.6,tsc_CC6.8,tsc_CC7 .2,tsc_CC7.3</group>
  </rule>

Let me know if the help helped you.

Greetings,

Nicolas

[Jorge Eduardo Molas]

Hi  Saddique Khan, 
Nicolas recommended removing the ^ symbol, as it implies that the string must begin with "mfe." Thank you, Nicolas, for the helpful advice. Best regards!

[Saddique Khan]

Hello Jorge and Nicolas,

     Thanks for reply. I have updated the rule and attached to the master pod. I restarted it.  I have enabled the teams notifications for testing purpose. The test is in under progress. I will update you about the results.

Regards,

Saddique Khan

[Saddique Khan]

Hello Nicolas and Jorge,

            I tested the new configurations and it seems that custom rule is not working as I can see the alerts in my teams. I have attached the snapshot for your reference. I can't keep this like that becz it will create alerts after 30 minutes and all of them will be false. 

            For your further knowledge and clarity. 

           1.  I have attached custom rule  configuration only to the master container not to worker container. I believe that this rule will be disturbed to the worker or at least it would be verified from the master pod. However, it is not working. 

           2. I didn't use any custom decoder for it. I suppose that default decoder will handle its logging process. However, If i would need to write custom decoder, please let me know or share the custom decoder which could help me to get the results.

Your help will be appreciated.

Thanks,

Regards,

Saddique Khan 

[Nicolas Osvaldo Fernandez]

Hello,

Could you try logtest to see that the rule is working correctly?

To do it:

1. Open logtest: /var/ossec/bin/wazuh-logtest

2. Test the events that are being fired to see if they are captured by the created rule.

Let me know the result.

Result of my test:

root@wazuh-server:/home/nof# /var/ossec/bin/wazuh-logtest
Starting wazuh-logtest v4.4.4
Type one log per line

Aug 25 11:00:02 HOSTNAME sudo[1108373]: pam_unix(sudo:session): session opened for user mfe by (uid=0)

**Phase 1: Completed pre-decoding.
full event: 'Aug 25 11:00:02 HOSTNAME sudo[1108373]: pam_unix(sudo:session): session opened for user mfe by (uid=0)'
timestamp: 'Aug 25 11:00:02'
hostname: 'HOSTNAME'
program_name: 'sudo'

**Phase 2: Completed decoding.
name: 'pam'
parent: 'pam'
dstuser: 'mfe'
uid: '0'

**Phase 3: Completed filtering (rules).
id: '101101'
level: '0'
description: 'Ignore sudo auth for mfe user.'
groups: '['local', 'syslog', 'sshd']'
firedtimes: '1'
gdpr: '['IV_32.2']'
gpg13: '['7.6', '7.8', '7.13']'
hipaa: '['164.312.b']'
mail: 'False'
nist_800_53: '['AU.14', 'AC.7', 'AC.6']'
pci_dss: '['10.2.5', '10.2.2']'
tsc: '['CC6.8', 'CC7.2', 'CC7.3']'

Greetings,

Nicolas

[Saddique Khan]

Hello Nicolas,

       I am sharing my wazuh-logtest result here. 

wazuh-manager-master-0:/var/ossec/bin# ./wazuh-logtest
Starting wazuh-logtest v4.5.0

Type one log per line

Aug 25 11:00:02 HOSTNAME sudo[1108373]: pam_unix(sudo:session): session opened for user mfe by (uid=0)

** Wazuh-Logtest: WARNING: (7616): List 'etc/lists/amazon/aws-eventnames' could not be loaded. Rule '80202' will be ignored.
** Wazuh-Logtest: WARNING: (7617): Signature ID '80202' was not found and will be ignored in the 'if_sid' option of rule '80203'.
** Wazuh-Logtest: WARNING: (7619): Empty 'if_sid' value. Rule '80203' will be ignored.
** Wazuh-Logtest: WARNING: (7617): Signature ID '80203' was not found and will be ignored in the 'if_sid' option of rule '80250'.
** Wazuh-Logtest: WARNING: (7619): Empty 'if_sid' value. Rule '80250' will be ignored.
** Wazuh-Logtest: WARNING: (7617): Signature ID '80202' was not found and will be ignored in the 'if_sid' option of rule '80251'.
** Wazuh-Logtest: WARNING: (7619): Empty 'if_sid' value. Rule '80251' will be ignored.
** Wazuh-Logtest: WARNING: (7620): Signature ID '80251' was not found. Invalid 'if_matched_sid'.Rule '80252' will be ignored.
** Wazuh-Logtest: WARNING: (7617): Signature ID '80202' was not found and will be ignored in the 'if_sid' option of rule '80253'.
** Wazuh-Logtest: WARNING: (7619): Empty 'if_sid' value. Rule '80253' will be ignored.
** Wazuh-Logtest: WARNING: (7617): Signature ID '80253' was not found and will be ignored in the 'if_sid' option of rule '80254'.
** Wazuh-Logtest: WARNING: (7619): Empty 'if_sid' value. Rule '80254' will be ignored.
** Wazuh-Logtest: WARNING: (7620): Signature ID '80254' was not found. Invalid 'if_matched_sid'.Rule '80255' will be ignored.
** Wazuh-Logtest: WARNING: (7616): List 'etc/lists/audit-keys' could not be loaded. Rule '80780' will be ignored.
** Wazuh-Logtest: WARNING: (7617): Signature ID '80780' was not found and will be ignored in the 'if_sid' option of rule '80781'.
** Wazuh-Logtest: WARNING: (7619): Empty 'if_sid' value. Rule '80781' will be ignored.
** Wazuh-Logtest: WARNING: (7617): Signature ID '80780' was not found and will be ignored in the 'if_sid' option of rule '80782'.
** Wazuh-Logtest: WARNING: (7619): Empty 'if_sid' value. Rule '80782' will be ignored.
** Wazuh-Logtest: WARNING: (7616): List 'etc/lists/audit-keys' could not be loaded. Rule '80783' will be ignored.
** Wazuh-Logtest: WARNING: (7617): Signature ID '80783' was not found and will be ignored in the 'if_sid' option of rule '80784'.
** Wazuh-Logtest: WARNING: (7619): Empty 'if_sid' value. Rule '80784' will be ignored.
** Wazuh-Logtest: WARNING: (7617): Signature ID '80783' was not found and will be ignored in the 'if_sid' option of rule '80785'.
** Wazuh-Logtest: WARNING: (7619): Empty 'if_sid' value. Rule '80785' will be ignored.
** Wazuh-Logtest: WARNING: (7616): List 'etc/lists/audit-keys' could not be loaded. Rule '80786' will be ignored.
** Wazuh-Logtest: WARNING: (7617): Signature ID '80786' was not found and will be ignored in the 'if_sid' option of rule '80787'.
** Wazuh-Logtest: WARNING: (7619): Empty 'if_sid' value. Rule '80787' will be ignored.
** Wazuh-Logtest: WARNING: (7617): Signature ID '80786' was not found and will be ignored in the 'if_sid' option of rule '80788'.
** Wazuh-Logtest: WARNING: (7619): Empty 'if_sid' value. Rule '80788' will be ignored.
** Wazuh-Logtest: WARNING: (7616): List 'etc/lists/audit-keys' could not be loaded. Rule '80789' will be ignored.
** Wazuh-Logtest: WARNING: (7610): Group 'audit_watch_write' was not found. Invalid 'if_group'. Rule '80790' will be ignored.
** Wazuh-Logtest: WARNING: (7610): Group 'audit_watch_write' was not found. Invalid 'if_group'. Rule '80791' will be ignored.
** Wazuh-Logtest: WARNING: (7616): List 'etc/lists/audit-keys' could not be loaded. Rule '80792' will be ignored.

**Phase 1: Completed pre-decoding.
        full event: 'Aug 25 11:00:02 HOSTNAME sudo[1108373]: pam_unix(sudo:session): session opened for user mfe by (uid=0)'
        timestamp: 'Aug 25 11:00:02'
        hostname: 'HOSTNAME'
        program_name: 'sudo'

**Phase 2: Completed decoding.
        name: 'pam'
        parent: 'pam'
        dstuser: 'mfe'
        uid: '0'

**Phase 3: Completed filtering (rules).
        id: '101101'
        level: '0'
        description: 'Ignore sudo auth for mfe user.'

        groups: '['pam', 'syslog']'

        firedtimes: '1'
        gdpr: '['IV_32.2']'
        gpg13: '['7.6', '7.8', '7.13']'
        hipaa: '['164.312.b']'
        mail: 'False'
        nist_800_53: '['AU.14', 'AC.7', 'AC.6']'
        pci_dss: '['10.2.5', '10.2.2']'
        tsc: '['CC6.8', 'CC7.2', 'CC7.3']'

It looks same like yours. Is this fine? I am looking for your expert suggestion.

Regards,

Saddique 

[Saddique Khan]

Hello Nicolas,

       The local rules looks working while i run the wazuh-logtest script from the backend. However, i could still the logs on wazuh dashboard. Please check the screenshot.

Regards,

Saddique

[Nicolas Osvaldo Fernandez]

Hello, The logtest result is correct. 

I was going through the documentation and you need to restart the master node and the worker manually for the worker to apply the rule changes.

 For more information, you can review the following documentation. Check this warning: When rules, decoders, or CDB lists are synchronized, the worker nodes are not restarted. They must be restarted manually in order to apply the received configuration.

Let me know if the help provided helped you.

Greetings, 

Nicolas

[Saddique Khan]

Hello Nicolas,

       Thanks for the reply and documentations.

 

       I have read the documents. yes I understood this. After custom rule, i have restarted both the manager and worker pods. I also restarted the dashboard and indexer pod. However, the impact is same. I also run the wazuh-logtest script for testing on worker pod and the result is fine. However, I could still see the logs on the dashboard. 

      The impact is not going from the backend to the Wazuh dashboard. Any suggestion?

       One more thing for your information, the pod doesn't come up by only attaching the custom rule. What I did, i have attached the agent.conf file in the default group directory and it is working for me. Shall I put something in agent.conf?

Greetings,

Saddique

[Nicolas Osvaldo Fernandez]

Hello,

You can try the following operation:

systemctl restart wazuh-manager

Thank you

Greetings,

Nicolas

[Saddique Khan]

Hello Nicolas,

    I tried it and  systemctl is not inside my container. I believe that killing the pod bring the effect. I tried it with other wazuh solutions and it worked for me. My only challenge is to enable local_rules.xml rule in the dashboard.. 

Greetings,

Saddique

[Nicolas Osvaldo Fernandez]

Hello, what SO you have installed in the container?
You could try with:

service wazuh-manager stop
service wazuh-manager start

Greetings,

Nicolas

[Saddique Khan]

Hello Nicolas,

       I could restart the wazuh-manager using your command. Thanks for that. However, I still could see mfe events in my dashboard..

    I have attached the dashboard screenshot for your reference. 

  Greetings,

Saddique

[Nicolas Osvaldo Fernandez]

Hello, check, did you restart the manager on the main server or where is the worker?

Try doing it on the worker's server please.

Greetings,

Nicolas

[Saddique Khan]

Hello Nicolas,

I'd like to share with you the structure of my cluster. I've provided a screenshot for your reference. My main concern revolves around receiving alerts for "Root user" logins on my agents' machines. Currently, these alerts are appearing on the Wazuh dashboard, which is perfectly fine. However, there's an issue with additional or default alerts generated by the "mfe user" in Wazuh. This user generates alerts every 30 minutes. If these alerts continue, it will become cumbersome to manage notifications on my mobile device. Therefore, my objective is to prevent these alerts from reaching my phone.

To address this, I've created a rule as described above, and it's functioning properly with the backend `wazuh-logtest` script. However, despite the rule's functionality in the backend, it continues to trigger alerts for rule ID 5501 on my team's devices. I would greatly appreciate it if you could suggest an alternative custom rule that achieves the desired outcome.

I've taken several steps to troubleshoot this issue. I've restarted the Wazuh manager multiple times in an attempt to activate the changes, but the alerts persist within the actual alert system. I've even tried killing my worker nodes, but unfortunately, the results have not been satisfactory. At this point, I don't mind if these alerts appear on the Wazuh dashboard; my primary concern is to prevent them from generating notifications on my teams which is on my cellphone.

Thank you for your assistance and guidance.

Greetings,

Saddique

[Nicolas Osvaldo Fernandez]

Hello, thanks for the context detail. I ask you a question, you created the rule in the master node, right?

We are verifying with the specialized team what the problem may be.

Regards, 

Nicolas

[Saddique Khan]

Hello Nicolas,

      Yes I have created the rule in master node.  Thanks for the reply.

Greetings,

Saddique

[Nicolas Osvaldo Fernandez]

Hello, ok, let me carry out some tests with the equipment and I'll get back to you. 

Greetings

Nicolás

[Saddique Khan]

Hello Nicolas,

        Thanks for your effort. I appreciate it. I will be waiting for your response. I am also testing it on my end. If I find anything useful. I will update you. I

 

    Just to clear the IDEA:-):  just need to get the Root user login or sudo alert  and I don't want any other user alert about login.

   I will request you to check it on wazuh cluster which is deployed on kubernetes..:-)

  Thanks in advance.

  Greetings,

 Saddique

[Nicolas Osvaldo Fernandez]

Hello, could we check if the rules file with the updated rule is found in the worker node?

This to check that we do not have a synchronization problem between the nodes.

Greetings,

Nicholas

[Saddique Khan]

Hello, yes I checked both the pods and both have the same configurations for the file. I have attached the screenshot for you.

Greetings,

Saddique

[Nicolas Osvaldo Fernandez]

Hello, perfect, we are ruling out scenarios. The problem is the rule, could you try running the logtest but on the worker node?

Greetings,

Nicolas

[Saddique Khan]

Hello Nicolas,

  

  Good Morning!

  I have run it on the both master node and worker node. Ran logtest 19 hour of running the system. You can check the logs yourself. I think It didn't work on worker node.However, I am not sure that it will either work after restarting the worker pod or not. Please find the attachements.

 Greetings,

Saddique

[Nicolas Osvaldo Fernandez]

Hi, as far as you can see from the logs, the worker is not working correctly.

You could run the following command on the worker:

cat /var/ossec/logs/ossec.log | grep -i -E "error|warning|critical"

Greetings,

Nicolas

[Saddique Khan]

Hello Nicolas,

 

      Good Morning!

     

     I ran the given command and attached the logs for your reference. I had restarted the worker and manager pod on Friday. I could see that the worker node result is also coming up. I have attached the logs and screenshot for your reference. 

    

     Thanks nicolas for your cooperation.

   Regards,

   Saddique Khan

[Nicolas Osvaldo Fernandez]

Hello, ok perfect, could you try running the logtest on the worker node again?

Greetings,

Nicolas

[Saddique Khan]

Hello Nicolas,

    I have already tested it and it was working fine on worker pod . However still the impact was not coming on wazuh dashboard. Today I saw a GitHub post and some referred the Solution of hostname. In my case, I don’t know what is it. I could also see the custom rules in wazuh management rules on dashboard. The only problem is that it is not working on incoming logs from different agents.

Greetings,

Saddique 

--
You received this message because you are subscribed to a topic in the Google Groups "Wazuh | Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wazuh/CkN2LaAXOcQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wazuh+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/cacf50a1-c35b-46f6-8b51-82a36d938d89n%40googlegroups.com.

[Saddique Khan]

Hello Nicolas,

           here is the wazuh worker nodes logs.

root@wazuh-manager-worker-0:/# /var/ossec/bin/wazuh-logtest -vv

Starting wazuh-logtest v4.5.0
Type one log per line

Sep  5 15:00:01 hostname sudo[1324846]: pam_unix(sudo:session): session opened for user mfe by (uid=0)

        full event: 'Sep  5 15:00:01 hostname sudo[1324846]: pam_unix(sudo:session): session opened for user mfe by (uid=0)'
        timestamp: 'Sep  5 15:00:01'
        hostname: 'hostname'

        program_name: 'sudo'

**Phase 2: Completed decoding.
        name: 'pam'
        parent: 'pam'
        dstuser: 'mfe'
        uid: '0'

**Rule debugging:
        Trying rule: 1 - Generic template for all syslog rules.
                *Rule 1 matched
                *Trying child rules
        Trying rule: 600 - Active Response Messages Grouped
        Trying rule: 650 - Active Response JSON Messages Grouped
        Trying rule: 200 - Grouping of wazuh rules.
        Trying rule: 400 - Rules for Wazuh API events.
        Trying rule: 420 - Rules for Wazuh API events.
        Trying rule: 2100 - NFS rules grouped.
        Trying rule: 2507 - OpenLDAP group.
        Trying rule: 2550 - rshd messages grouped.
        Trying rule: 2701 - Ignoring procmail messages.
        Trying rule: 2800 - Pre-match rule for smartd.
        Trying rule: 5100 - Pre-match rule for kernel messages.
        Trying rule: 5200 - Ignoring hpiod for producing useless logs.
        Trying rule: 2830 - Crontab rule group.
        Trying rule: 5300 - Initial grouping for su messages.
        Trying rule: 5905 - useradd failed.
        Trying rule: 5400 - Initial group for sudo messages.
        Trying rule: 9100 - PPTPD messages grouped.
        Trying rule: 9200 - Squid syslog messages grouped.
        Trying rule: 2900 - Dpkg (Debian Package) log.
        Trying rule: 2930 - Yum logs.
        Trying rule: 2931 - Yum logs.
        Trying rule: 2940 - NetworkManager grouping.
        Trying rule: 2943 - nouveau driver grouping.
        Trying rule: 2962 - Perdition custom app group.
        Trying rule: 3100 - Grouping of the sendmail rules.
        Trying rule: 3190 - Grouping of the smf-sav sendmail milter rules.
        Trying rule: 3300 - Grouping of the postfix reject rules.
        Trying rule: 3320 - Grouping of the postfix rules.
        Trying rule: 3390 - Grouping of the clamsmtpd rules.
        Trying rule: 3395 - Grouping of the postfix warning rules.
        Trying rule: 3500 - Grouping for the spamd rules
        Trying rule: 3600 - Grouping of the imapd rules.
        Trying rule: 3700 - Grouping of mailscanner rules.
        Trying rule: 3800 - Grouping of Exchange rules.
        Trying rule: 3900 - Grouping for the courier rules.
        Trying rule: 4500 - Grouping for the Netscreen Firewall rules
        Trying rule: 4700 - Grouping of Cisco IOS rules
        Trying rule: 4800 - SonicWall messages grouped.
        Trying rule: 5500 - Grouping of the pam_unix rules.
                *Rule 5500 matched
                *Trying child rules
        Trying rule: 5552 - PAM and gdm are not playing nicely.
        Trying rule: 101101 - Ignore sudo auth for mfe user.
                *Rule 101101 matched

**Phase 3: Completed filtering (rules).
        id: '101101'
        level: '0'
        description: 'Ignore sudo auth for mfe user.'
        groups: '['pam', 'syslog']'
        firedtimes: '1'
        gdpr: '['IV_32.2']'
        gpg13: '['7.6', '7.8', '7.13']'
        hipaa: '['164.312.b']'
        mail: 'False'
        nist_800_53: '['AU.14', 'AC.7', 'AC.6']'
        pci_dss: '['10.2.5', '10.2.2']'
        tsc: '['CC6.8', 'CC7.2', 'CC7.3']'

Greetings,

Saddique

[Nicolas Osvaldo Fernandez]

Hello, could you send me the alert that you want to delete from the dashboard in json format to analyze it?

Greetings!

Nicolas

[Saddique Khan]

Hello Nicolas,

            Sure, I have attached the json file logs for you. It is mfe user which is sending alerts in the wazuh dashboard and teams on rule.id 5501. Unfortunately my root and other user are using the same ID. I want the alert for my users not the mfe default user. I enabled these alerts with audit rules mentioned on wazuh documentations. Now I want to make mfe alert disappear from the dashboard. That's the idea. I have already shared the custom rule above. Please note that i didn't write any custom decoder for it.

Greetings,

Saddique 

[Nicolas Osvaldo Fernandez]

Hello, thanks for the information.

We were able to find the problem. If you look at the event you gave me as an example:

Sep 6 14:30:02 Hostname sudo[1342112]: pam_unix(sudo:session): session opened for user mfe by (uid=0)

You can see that the date has this value: Sep 6 14:30:02, however, this format is not compatible with syslog, for this reason, the event is not being decoded correctly.

If you do the test, you can test this same event in wazuh-logtest and you will see that it is not treated in the same way as the original event with which we started the tests.

In order for the event to be processed, it should have this format:

Sep 06 14:30:02 Hostname sudo[1342112]: pam_unix(sudo:session): session opened for user mfe by (uid=0)

To fix the problem you should modify the configuration of the process that uploads these events so that it formats the date in a way that is compatible with syslog.

Let me know if the help helped you.

Greetings,

Nicolas

[Saddique Khan]

Hello Nicolas,

          I hope you are doing good today. 

          

          I checked both the logs but result is same. Even I checked the format in the log file for "06". For example, right now, my logs are showing up "11". It suppose not come for the dashboard but still i could see. I have attached screenshot for your reference. 

  Regards,

Saddique 

[Saddique Khan]

Hello Nicolas,

          If you don't mind, could you please give me the decoder for my custom rule which being executed when my custom rule executed? I want put that in the custom decoder and try it once.

Greetings,

Saddique 

[Nicolas Osvaldo Fernandez]

Hello, the decoder that is executed is the following:

<decoder name="pam">
  <program_name></program_name>
  <prematch>^pam_unix|^\(pam_unix\)</prematch>
</decoder>

Greetings!

Nicolas

[Nikola Tepavac]

Hello  Saddique,

I'm having the same issue.
Where you able to solve this?

Greetings,

Nikola Tepavac