Wazuh error: connection refused with new SecureStack Base CentOS 7 install

[6mile]

I added this ticket for a customer 17/3/2018

Hello,
our customer ask us to try SecureStack solution and then implement as one of the security layers. I was able to setup server from Your's ami, hovewer when i'm trying to setup worker from Centos 7 AMI https://aws.amazon.com/marketplace/pp/B0777BXSLW?qid=1521212736914&sr=0-3&ref_=srh_res_product_title (I'm getting errors from wazzuh deamon:

mar 16 15:02:30 securestack01 wazuh-agent[2679]: Starting OSSEC: 2018/03/16 15:02:30 ossec-agentd: INFO: Using notify time: 600 and max time to reconnect: 1800
mar 16 15:02:33 securestack01 wazuh-agent[2679]: 2018/03/16 15:02:33 ossec-syscheckd: ERROR: (1210): Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
mar 16 15:02:33 securestack01 wazuh-agent[2679]: 2018/03/16 15:02:33 rootcheck: ERROR: (1210): Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
mar 16 15:02:41 securestack01 wazuh-agent[2679]: 2018/03/16 15:02:41 ossec-syscheckd: ERROR: (1210): Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
mar 16 15:02:41 securestack01 wazuh-agent[2679]: 2018/03/16 15:02:41 rootcheck: ERROR: (1210): Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
mar 16 15:02:54 securestack01 wazuh-agent[2679]: 2018/03/16 15:02:54 ossec-syscheckd: ERROR: (1210): Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
mar 16 15:02:54 securestack01 wazuh-agent[2679]: 2018/03/16 15:02:54 rootcheck: CRITICAL: (1211): Unable to access queue: '/var/ossec/queue/ossec/queue'. Giving up..
mar 16 15:02:54 securestack01 wazuh-agent[2679]: [FAILED]
mar 16 15:02:54 securestack01 systemd[1]: wazuh-agent.service: control process exited, code=exited status=1
mar 16 15:02:54 securestack01 systemd[1]: Failed to start SYSV: Starts and stops Wazuh (Host Intrusion Detection System).
earlier steps like update, and setup were ok. Could You tell me how can i fix that error? If the tests will be successful our customer will use Your solution to protect whole infrastructure.

[6mile]

That error usually means that the SecureStack Base instance can’t connect to the SecureStack SIPServer. Here’s what you need to do:

1. Find the IP address for the SIPServer and for the Cent7 Base instance
   On the SIPServer verify that the firewall allows access:
   ufw status

2. Normally, if all your instances are going to be in the same subnet I allow say the 10.0.0.0/24 subnet with a:
   ufw allow proto tcp from 10.0.0.0/24 to any port 1514
   and a:
   ufw allow proto tcp from 10.0.0.0/24 to any port 1515

3. On the Cent7 Base instance make sure its pointing at the your SIPServer:
   grep server-ip /var/ossec/etc/ossec.conf
   Change this IP address to point at your SIPServer.

4. Lastly, make sure that they are both using the same authd password. So, on both machines do:
   cat /var/ossec/etc/authd.pass
   to verify this. If they aren’t using the same key, update them to do so.

5. Once all that is done do a: systemctl restart wazuh-agent on the Base instance and you should be talking to the SIPServer. You will be able to verify this in the SIPServer web UI under Agents or at the command line with a: /var/ossec/bin/list-agents -a and you should see your new SecureStack Base instance

Cheers,
Support @ SecureStack

[6mile]

If for some reason the SecureStack Base and SIPServer won't communicate and you've verified that there is no firewall or other connectivity issue, then run these steps:

1. If you haven’t done a systemctl restart wazuh-agent then do one and see if that fixes it.
2. If you have, then do this: /var/ossec/bin/agent-auth -m <server_ip_address> # this will reset the key that the server and the agent use to verify their identity
3. You will then have to restart the agent on the Base instance again: systemctl restart wazuh-agent
4. It should be working now, but if for some reason it’s not, you might have to restart the control agent on the server with a: /var/ossec/bin/ossec-control restart # Again, this step probably won’t be necessary.

This will reset the key that the server and the Base image use to communicate. When a key is reset you need to restart the agent on the Base instance always. Only occasionally, do you need to restart the agent on the SIPServer.