If the agent is already registered with the hub, please follow the troubleshooting steps in this article:
Step 1) Confirm the process ossec-remoted process is running on the hub, and listening on port 1514. Run the following command as the root user:
netstat -pan |grep remoted
Should return a result similar to this:
udp 0 0 0.0.0.0:1514 0.0.0.0:* 15258/ossec-remoted
If ossec-remoted is not running, follow this procedure to start the OSSEC services:
Note: Multiple instances of ossec-remoted will be running if the system is also configured to receive syslog traffic.
Step 2) Confirm UDP port 1514 is allowed by the local hubs firewall rules by running the following command:
grep FW_INBOUND_UDP_SERVICES /var/awp/etc/config
Acceptable return examples:
FW_INBOUND_UDP_SERVICES=”no”
FW_INBOUND_UDP_SERVICES=”1514,”
Note: if a list is returned (example 2) then 1514 should be included in the list. If 1514 is NOT included, add 1514 at the end of the list and reload the security policy by running the following command:
awp -s -f
Step 3) Confirm UDP traffic port 1514 is getting to the system by running the following command, replacing "ens33" with the correct interface name for the network interface with the IP address configured to match the IP address that the agents have configured for the OSSEC server.
Note: tshark must be installed on the system prior to running this command:
tshark -i ens33 port 1514 -n
Troubleshooting tip: Rerun the agent installer script and change the port in the command above to 1515, you should see TCP 1515 traffic immediately. For example:
tshark -i ens33 port 1515 -n
If you do not see packets from the agent, this means that an upstream firewall or filter is blocking traffic, or that the agent is configured to use the wrong IP address for the hub, or that the virtual machine has been configured for NAT mode and not bridge mode.
Step 4) Confirm the ossec.conf on the agent has the correct <server-ip> field set to the <hub ip>
Comments
0 comments
Please sign in to leave a comment.