postfix log not exist

[KevinK Leung]

Dear Team,

 

In the Wazuh setup, I have add a centos linux server which contains postfix service is running, to the dashboard.

However, I can’t see the postfix log are going to the Wazuh server properly. I have done the following check and verification

1.      In local ‘ossec.conf’, there is a section called “localfile” and the syntax were below: (in the client side @ postfix server)

<localfile>

 

        <log_format>syslog</log_format>

        <location>/var/log/maillog</location>

                </localfile>

 

 

2.      In the Wazuh server, there are no logs relate to postfix are being sent to the Wazuh server.

3.      There are postfix decoders were available at /var/ossec/ruleset/decoders/0220-postfix_decoders.xml

 

 

What can I do next to double check the postfix log are correctly send to Wazuh server?

 

Regards

Kevin

 

 

 

[Jonathan Martín Valera]

Hi,

Ok, let’s check that the maillog events are being sent correctly and that the wazuh-manager is processing them.

First, let’s check that the ossec.log of the wazuh-agent (or wazuh-manager if you are monitoring with it) shows that this file is being monitored.

# grep "Analyzing file: '/var/log/maillog'" /var/ossec/logs/ossec.log

2022/08/08 09:11:47 wazuh-logcollector: INFO: (1950): Analyzing file: '/var/log/maillog'.

Once we have verified that the file we want is being monitored, we will check that the events are indeed being sent to the wazuh-manager. To do this, we are going to activate the logging of all the events received by the wazuh-manager. This is done by editing the /var/ossec/etc/ossec.conf file of the wazuh-manager and setting the logall setting to yes.

<ossec_config>
  <global>
    <logall>yes</logall>
    ...

After restarting the wazuh-manager to apply the configuration (systemctl restart wazuh-manager), from now on all events received by the wazuh-manager will be stored in the /var/ossec/logs/archives/archives.log file.

What we can do now is to generate a test event in the /var/log/maillog file and check if this event has been stored in the /var/ossec/logs/archives/archives.log file of the wazuh-manager.

Add a test event to /var/log/maillog:

echo "Aug  8 11:26:19 dv qmail: Test to check if wazuh-manager is receiving events" >> /var/log/maillog

And we check if the wazuh-manager has received and stored the event:

#grep "Test to check" /var/ossec/logs/archives/archives.log 

2022 Aug 08 09:27:37 dv->/var/log/maillog Aug  8 11:26:19 dv qmail: Test to check if wazuh-manager is receiving events

If the event exists, we can be sure that the wazuh-manager is receiving the events correctly, and the reason why you do not see related security alerts is probably that the logs that are being stored do not match with decoders or rules.

From now on you should focus on testing events that you think should generate alerts in the wazuh-manager tool /var/ossec/bin/wazuh-logtest. When you enter the log, it shows you information about whether it has been decoded and whether it has been matched against any rules.

You can find more information about this at https://documentation.wazuh.com/current/user-manual/capabilities/wazuh-logtest/how-it-works.html#use-cases-test-log-from-wazuh-logtest-tool

Note: When you finish checking if the wazuh-manager receives events or not, I recommend you to set the logall setting back to no value and restart the wazuh-manager service, to avoid storing all the events received by the wazuh-manager as it may cause unnecessary disk usage and storage.

I hope you find this information useful.

Best regards.

​

[KevinK Leung]

Thanks Johnathan, 

thanks for your prompt response and help. The log was successfully sent to Wazuh server. Furthermore, I do a comparison of the postfix log before and after it was sent to Wazuh sever. It looks Wazuh server add the <current date>-<Agent_name>-<log file name> before the actual log comes. How Can I remove these fields so that the decoder is working properly?

 

# cat archives.log | grep UAT-SMTP-SVR (Log pattern when Wazuh server receive it)

 

2022 Aug 09 10:04:52 (UAT-SMTP-SVR) any->/var/log/maillog Aug  9 10:05:40 UAT-SMTP-SVR postfix/error[30571]: 45CD8100CD2F9: to=<ro...@test-domain.com>, relay=none, delay=35554, delays=35553/0.07/0/0.04, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to test-domain.com[xxx.yyy.zzz.ddd]:25: Connection timed out)

2022 Aug 09 10:04:52 (UAT-SMTP-SVR) any->/var/log/maillog Aug  9 10:05:40 UAT-SMTP-SVR postfix/error[30579]: 88D81100CD070: to=<ro...@test-domain.com>, relay=none, delay=136354, delays=136354/0.08/0/0.04, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to test-domain.com[aa.bb.cc.dd]:25: Connection timed out)

2022 Aug 09 00:09:48 (UAT-SMTP-SVR) any->/var/log/maillog Aug  9 00:10:36 UAT-SMTP-SVR postfix/qmgr[1436]: E

42F2100CD2D5: from=<ro...@test-domain.com>, size=776, nrcpt=1 (queue active)

2022 Aug 09 00:09:48 (UAT-SMTP-SVR) any->/var/log/maillog Aug  9 00:10:36 UAT-SMTP-SVR postfix/qmgr[1436]: E

6C6E100CD07D: from=<ro...@test-domain.com>, size=777, nrcpt=1 (queue active)

2022 Aug 09 00:10:48 (UAT-SMTP-SVR) any->/var/log/maillog Aug  9 00:11:36 UAT-SMTP-SVR postfix/smtp[26475]:

connect to test-domain.com[zz.vv.ss.gg]:25: Connection timed out

2022 Aug 09 00:10:48 (UAT-SMTP-SVR) any->/var/log/maillog Aug  9 00:11:37 UAT-SMTP-SVR postfix/smtp[26476]:

connect to test-domain.com[zzz.xxx.ccc.bbb]:25: Connection timed out

2022 Aug 09 00:10:48 (UAT-SMTP-SVR) any->/var/log/maillog Aug  9 00:11:38 UAT-SMTP-SVR postfix/smtp[26474]:

connect to test-domain.com[hh.bb.ff.xxx]:25: Connection timed out

 

 

 

 

# cat /var/log/maillog (At agent side)

 

Aug  9 10:15:40 UAT-SMTP-SVR postfix/qmgr[1436]: 1CC2E100CEE75: from=<>, size=2642, nrcpt=1 (queue active)

Aug  9 10:15:40 UAT-SMTP-SVR postfix/qmgr[1436]: 12980100CEE79: from=<>, size=2637, nrcpt=1 (queue active)

Aug  9 10:15:40 UAT-SMTP-SVR postfix/error[30624]: A0DED100CEE71: to=<ro...@test-domain.com>, relay=none, delay=14550, delays=14550/0.03/0/0.04, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to test-domain.com[aaa.bb.cc.dd]:25: Connection timed out)

Aug  9 10:15:40 UAT-SMTP-SVR postfix/error[30625]: 4528C100CD2DA: to=<ro...@test-domain.com>, relay=none, delay=266554, delays=266554/0.03/0/0.04, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to test-domain.com[ccc.ddd.fff.eee]:25: Connection timed out)

Aug  9 10:15:40 UAT-SMTP-SVR postfix/error[30627]: 475C1100CD07A: to=<ro...@test-domain.com>, relay=none, delay=316954, delays=316954/0.04/0/0.04, dsn=4.4.1, status=deferred]:25: Connection timed out)

[Jonathan Martín Valera]

Hi,

Sorry for the late reply (vacation period :P)

Don’t worry about the header you comment in the archives.log file, since it is internally decoded using only the original log, i.e:

In archives.log you see the following content

2022 Aug 09 10:04:52 (UAT-SMTP-SVR) any->/var/log/maillog Aug  9 10:05:40 UAT-SMTP-SVR postfix/error[30571]: 45CD8100CD2F9: to=<ro...@test-domain.com>, relay=none, delay=35554, delays=35553/0.07/0/0.04, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to test-domain.com[xxx.yyy.zzz.ddd]:25: Connection timed out)

But internally it is treated as:

Aug  9 10:05:40 UAT-SMTP-SVR postfix/error[30571]: 45CD8100CD2F9: to=<ro...@test-domain.com>, relay=none, delay=35554, delays=35553/0.07/0/0.04, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to test-domain.com[xxx.yyy.zzz.ddd]:25: Connection timed out)

If you want to build decoders and rules for such a log, you have to do so for:

Aug  9 10:05:40 UAT-SMTP-SVR postfix/error[30571]: 45CD8100CD2F9: to=<ro...@test-domain.com>, relay=none, delay=35554, delays=35553/0.07/0/0.04, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to test-domain.com[xxx.yyy.zzz.ddd]:25: Connection timed out)

Besides that in the /var/ossec/bin/wazuh-logtest tool you would also have to enter only the original log:

Aug  9 10:05:40 UAT-SMTP-SVR postfix/error[30571]: 45CD8100CD2F9: to=<ro...@test-domain.com>, relay=none, delay=35554, delays=35553/0.07/0/0.04, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to test-domain.com[xxx.yyy.zzz.ddd]:25: Connection timed out)

The info of the headers that you mention is used as extra information to be able to attach them later to the alerts. Maybe you can see this more clearly if instead of consulting the archives.log, you do it with archives.json (<logall_json> should be activated in ossec.conf). In this case, all the information is sorted into different fields, and the log would correspond to the full_log field.

If you are having trouble with the decoder, share a sample log and decoder you are using, and I’ll show you an example.

I hope this information is helpful.

Regards.

​

[Jonathan Martín Valera]

Hi,

In response to the private message you sent me (remember to always reply all so that the answer is public in the initial thread of the forum), yes, the events stored in the archives.json have a normal structure. Note what I said, that really the log that will be processed with the decoders and rules is contained in the full_log field, and there it appears without headers or anything, but it is the original log.

You say your decoder or ruler is not working for you, do you need help with that? If so, share a sample log, along with the decoder and ruler you are using so we can help you.

Regards.

​