ossec-maild not sending emails

[Doug OLeary]

Hi;

Scenario:  ossec ver 2.9.3 installed from atomic repo.  ossec.maild is running as shown by 'ossec-control status' and process pid.  Nothing ossec-maild related shows up in ossec.log unless I enable debug and then it's only:

# grep maild ossec.log
2018/02/08 10:20:41 ossec-maild: DEBUG: Starting ...
2018/02/08 10:20:41 ossec-maild: INFO: Chrooted to directory: /var/ossec
2018/02/08 10:25:56 ossec-maild: DEBUG: Starting ...
2018/02/08 10:25:56 ossec-maild: INFO: Chrooted to directory: /var/ossec

Email alerts are configured thusly:

  <global>
    <email_notification>yes</email_notification>
    <email_to>doug....@myco.com</email_to>
    <smtp_server>mpismtp.myco.com</smtp_server>
    <email_from>os...@myco.com</email_from>
  </global>
[[snip]]
  <alerts>
    <log_alert_level>1</log_alert_level>
    <email_alert_level>7</email_alert_level>
  </alerts>

The server is receiving alerts from close to 500 clients so plenty of chances to send emails.  

I've verified email from the command line works and is receivable off the system.  I've tried running logging packets to port 25 via tcpdump.  When I send an email from the command line, expected results.  Dead silence while ossec should be sending.  One post suggested that postfix had to be listening on port 25... it is...

# netstat -an | grep :25
tcp        0      0 127.0.0.1:25                0.0.0.0:*                   LISTEN    

I tried running a trace on the pid (strace -p ${pid}) and saw successive iterations of:

stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
read(3, "** Alert 1518104702.94473971: ma"..., 4096) = 639
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
read(3, "", 4096)                       = 0
select(0, NULL, NULL, NULL, {5, 0})     = 0 (Timeout)
read(3, "", 4096)                       = 0
select(0, NULL, NULL, NULL, {5, 0})     = 0 (Timeout)
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
read(3, "", 4096)                       = 0
select(0, NULL, NULL, NULL, {5, 0})     = 0 (Timeout)
read(3, "", 4096)                       = 0
select(0, NULL, NULL, NULL, {5, 0})     = 0 (Timeout)
read(3, "", 4096)                       = 0
select(0, NULL, NULL, NULL, {5, 0})     = 0 (Timeout)
read(3, "", 4096)                       = 0
select(0, NULL, NULL, NULL, {5, 0})     = 0 (Timeout)
read(3, "", 4096)                       = 0
select(0, NULL, NULL, NULL, {5, 0} <detached ...>

The last time I did any C programming, java didn't exist so that, unfortunately, is meaningless to me.

Last item: I have a couple of dozen or so agents reporting to a ossec server 2.8.3 to support OS versions that won't run 2.9.3 (don't ask).  That server has the exact same set up for ossec mail and it's working fine.  Getting plenty of mail from that beastie.  

So, any ideas what I can do to get mail alerts working and/or troubleshoot this further?  

Thanks for your time and any hints/tips/suggestions.

Doug O'Leary

[Nathan Buuck]

Have you reviewed alerts.log to verify that at least one alert that exceeds your configured email alert threshold of 7 has been fired?

--

---
You received this message because you are subscribed to the Google Groups "ossec-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ossec-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Doug OLeary]

On Thursday, February 8, 2018 at 8:13:08 PM UTC-6, Nathan Buuck wrote:

Have you reviewed alerts.log to verify that at least one alert that exceeds your configured email alert threshold of 7 has been fired?

Oh yea.  That's what I was alluding to when I said that there were plenty of chances for alerts.  While troubleshooting this, I found a misconfiguration that would have resulted in thousands of emails.  While I'm glad to have avoided the mail bomb, I also missed at least two issues that were the reason for my implementation of ossec.  

Thanks for the reply.

Doug O'Leary

[Nathan Buuck]

Have you tried running ossec-maild with multiple instances of -d? OS_RecvMailQ() uses debug2() and requires at least two -d param instances in order for the debug message to be emitted.

It may be helpful - if also time intensive - to compile that version of OSSEC from source while outputting symbols and then attach gdb to ossec-maild, setting one or more breakpoints to allow you to step through the mail logic like the call to OS_RecvMailQ at https://github.com/ossec/ossec-hids/blob/master/src/os_maild/os_maild_client.c#L18.

- Nathan Buuck

--

[Doug OLeary]

Hey;

On Friday, February 9, 2018 at 7:12:24 AM UTC-6, Nathan Buuck wrote:

Have you tried running ossec-maild with multiple instances of -d? OS_RecvMailQ() uses debug2() and requires at least two -d param instances in order for the debug message to be emitted.

I had tried debug in the foreground but that got closed the first time a mail was supposed to be sent.  I then tried adding mail.debug=2 to internal_options.conf which didn't appear to have any affect.  

Just now realizing it may have been the foreground that was the issue, I tried debug again with no noticeable output to the ossec.log

# ossec-maild -d -d
2018/02/09 09:26:54 ossec-maild: DEBUG: Starting ...


2018/02/09 08:01:51 ossec-syscheckd: INFO: Ending syscheck scan.
2018/02/09 09:26:54 ossec-maild: DEBUG: Starting ...
2018/02/09 09:26:54 ossec-maild: INFO: Chrooted to directory: /var/ossec

Interestingly enough, I ran a process stat at just the right time to catch this:

# ps -ef | grep maild

ossecm   15099     1  0 09:26 ?        00:00:00 ossec-maild -d -d

ossecm   15253 15099  0 09:29 ?        00:00:00 [ossec-maild] <defunct>

It may be helpful - if also time intensive - to compile that version of OSSEC from source while outputting symbols and then attach gdb to ossec-maild, setting one or more breakpoints to allow you to step through the mail logic like the call to OS_RecvMailQ at https://github.com/ossec/ossec-hids/blob/master/src/os_maild/os_maild_client.c#L18.

- Nathan Buuck

That time intensive part is what I was hoping to avoid through the use of packages.   Don't suppose the defunct maild process gives a clue?

Thanks again for the replies.

Doug O'Leary