so-allow not allowing 1514 for Wazuh agent

[Cra5hedC0w]

When running so-allow to allow a subnet for wazuh agent connectivity, the logs in the agent still indicate that 1514 is refused by the SO instance. Issuing iptables -L |grep 1514 returns nothing. Upon disabling firewalld, the agent can then connect.

Please let me know if there is a workaround for this, or if this is a known issue.

[weslambert]

What is the output of the following?

so-firewall includedhosts wazuh_endpoint

[pakaremon]

I have the same problem, when I run this comand I have

[dougburks]

@NguyenCong-14 This is an old discussion from 2020 and it has been marked as answered. Instead of replying to old discussions, please start a new discussion with detailed information about your system.

[netsecninja]

I'm on 2.3.2 and having a similar problem with the registration port, 1515. Same issue, both 1515 and 1514 are not listed in the firewall with iptables -L | grep -E "151[4|5]". My so-firewall includedhosts wazuh_endpoint shows 10.0.0.0/8, which is accurate. I've confirmed with network pcaps the traffic is leaving my host, hitting my network firewall, and routed on to the SO box. But a tcpdump on SO shows no packets.

[netsecninja]

Progress! The first command worked to start the service. On my endpoint I ran sudo /var/ossec/bin/agent-auth -m <manager_IP>, which ran without error. I verified the endpoint was listed in SO with so-wazuh-agent-manage.

So I assume if I reboot my SO box, that ossec-authd service will no longer be running. My question is, is it supposed to be?

[weslambert]

Yes, this was just a test. I've put in a fix for this, which will be tracked here: #1810. The next release should have the fix.

[netsecninja]

Thanks for your help tracking this down Wes!

[kiaraho]

It would be inside of the Docker container.

Try this:

sudo docker exec so-wazuh /var/ossec/bin/ossec-authd

If that doesn't work, you can go into the container and execute ossec-authd with:

sudo docker exec -it so-wazuh /bin/bash
cd /var/ossec/bin
./ossec-auth
exit

Then, from your remote machine, try nc -vz <ip> 1515 to test the connection, or try running the agent join command again.

I also ran into the same ossec-authd not running issue as @netsecninja. The temporary fix above also worked for me, once I found this post after hours of troubleshooting. 🤦‍♂️

[manuelplascencia]

This was helpful thank you. Not sure if you answered netsecninja's question. Will a reboot require this to be ran ed again ?

[ozzbrian]

When running so-allow to allow a subnet for wazuh agent connectivity, the logs in the indicate that 1514 is activialy refused by the SO instance. Issuing iptables -L |grep 1514 returns nothing. Upon disabling firewalld, the agent can then connect.

[weslambert]

Try running with -nL, so you are not trying to resolving the raw port to a common service

[Cra5hedC0w]

iptables -nL |grep 1514 shows (redacted IP/Mask):

ACCEPT tcp -- 0.0.0.0/0 172.17.0.9 tcp dpt:1514
ACCEPT udp -- 0.0.0.0/0 172.17.0.9 udp dpt:1514
ACCEPT udp -- 10.x.x.x/xx 0.0.0.0/0 udp dpt:1514
ACCEPT tcp -- 10.x.x.x.x/xx 0.0.0.0/0 tcp dpt:1514
ACCEPT udp -- 127.0.0.1 0.0.0.0/0 udp dpt:1514
ACCEPT tcp -- 127.0.0.1 0.0.0.0/0 tcp dpt:1514

The logs for the agent still shows connection refused. I do see resets in the tcpdump. The rule exists in the DOCKER USER Chain.
The port is labeled as "fujitsu-dtcns" for anyone else searching iptables.

[TOoSmOotH]

What version are you using?

[Cra5hedC0w]

2.3.2

[weslambert]

What version Wazuh agent/server are you running?