v3.7.0 issue on RHEL 8 systems

[titleistfour]

Hello,

Thanks for publishing the new 3.7.0 RPM packages. It seems I'm having an issue getting ossec-hids-agent to work on RHEL 8 based systems. Tried on several systems at different locations, even different contracts, and always get these errors. The agent fails to start.

2022/04/11 13:03:16 ossec-agentd: INFO: Trying to connect to server ossec.server.local, port 1514.
2022/04/11 13:03:16 getaddrinfo: System error
2022/04/11 13:03:20 ossec-syscheckd(1210): ERROR: Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
2022/04/11 13:03:20 rootcheck(1210): ERROR: Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
2022/04/11 13:03:25 ossec-logcollector(1210): ERROR: Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
2022/04/11 13:03:25 ossec-logcollector(1211): ERROR: Unable to access queue: '/var/ossec/queue/ossec/queue'. Giving up..
2022/04/11 13:03:28 ossec-syscheckd(1210): ERROR: Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
2022/04/11 13:03:28 rootcheck(1210): ERROR: Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
2022/04/11 13:03:41 ossec-syscheckd(1210): ERROR: Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
2022/04/11 13:03:41 rootcheck(1211): ERROR: Unable to access queue: '/var/ossec/queue/ossec/queue'. Giving up..

Going back to v3.6.0 and have no issues with the exact same configuration.

I have tried this on clean systems that have never had OSSEC installed. Some had SELinux in enforcing mode, and some had SELinux completely disabled. Both exhibit the same problem. Coincidentally, ossec-hids-server package doesn't seem to have this problem.

Has anyone else experienced this with v.3.7.0?

Thanks, J

[atomicturtle]

Can you tell me more about the environment? Im using this on el8 (rocky linux), and I'm trying to reproduce it

[rakyp]

Yes agreed confirmed the issue exists on el8 when upgrading to 3.7.0, downgrading to 3.6.0 with the exact same configuration works fine.

@atomicturtle RHEL8, 64 bit - Kernel 4.18.0-348.20.1.el8_5.x86_64

Machine operating as client only (not server).

Works fine connecting to server and operating on 3.6.0:

DIRECTORY="/var/ossec" VERSION="3.6.0" DATE="Sun Mar 15 14:16:05 EDT 2020" TYPE="agent"

Updated to 3.7.0 RPM packages will break it with the same error as seen by OP.

Happy to organise a teams call so you can view the issue in real-time if it helps.

[driseley]

We get the same issue on RHEL7/Centos 7.

The following is also seen in /var/log/messages:

May 17 13:11:23 localhost kernel: traps: ossec-agentd[17663] general protection ip:7f47cef70b7c sp:7ffe230c4ed8 error:0 in libc-2.17.so[7f47ceeeb000+1c4000]

The problem only seems to occur if we have the server-hostname client option set with 3.7.0, it works fine with 3.6.0 If we use server-ip both 3.6.0 and 3.7.0 work fine

[titleistfour]

Confirmed what @driseley says. Using server-ip does seem to fix the issue with 3.7.0. Good catch!

[atomicturtle]

A ha, and DNS resolution works correctly in your environments?

[titleistfour]

For us yes, we have forward and reverse records that are correct for everything.

[driseley]

And us too - again this all works fine (using server-hostname) on the same hosts with 3.6.0

[titleistfour]

Is this issue going to be fixed soon? Using IP instead of hostname is not really ideal going forward.

[rakyp]

☹ Never heard back on this and just switched everything to using IP. It’s terrible, but it’s also a major bug that has a significant impact on the security of your environment. The lack of movement on it/no response is also a concern.

[titleistfour]

This is still an issue for us in RHEL/OL 9. This bug was reported over a year ago with confirmation from others and since then no real response from anyone about it getting fixed.

[lokalhorstkme]

IP instead of server name has got one serious security relevant advantage:

• in case of non working DNS , SIEM / logging is still working.

Remark: if you want to change your server IP, I hope you have some orchestration tool like Ansible, Puppet,.... in place to change ossec.conf on every client! Peace of cake to change >1k ossec.conf linux clients with one ansible-playbook.