Thanks for the offer. Status update:
(1) Problem agent 1: ran the "route" commmand and found that someone presumably on the customer's staff had added an Ethernet interface with a public address without telling us. I ran "traceroute" and found that the Linux host was shipping the OSSEC packets through the public Ethernet interface. It's a big "ouch!" since the OSSEC packets had been assigned as destination the internal IP address of the OSSEC server and they were supposed to go through the VPN, which is programmed to direct them to the internal IP of the OSSEC server. Public addresses, of course, don't understand private IP's.Once I changed the destination of the OSSEC packets to the external IPof the OSSEC server, everything went hunky dory. That's what happens when we have the teamwork without the coordination :) (2) Problem agent 2: I am guessing at this point that the customer changed the external IP address of the NATted interface of the OSSEC agent's host to some other external IP address without telling us. Or he screwed around with the config of the network firewall to block UDP traffic from port 1514 without telling us. Sometimes, being in charge means that we are the last ones to be notified of anything :) This takes care of our issue:) On Aug 17, 10:29 pm, Joe Gedeon <[email protected]> wrote: > Blacklight, > > I sent you an email off the list offering assistance with a web based > screen sharing tool. > > Joe > > > > On Wed, Aug 17, 2011 at 18:12, blacklight <[email protected]> wrote: > > I ran tcpdump on both the agent and the server. tcpdump is not picking > > up any OSSEC traffic at either end. The only traffic from the OSSEC > > server that tcpdump is picking up at the agent - that traffic is SNMP > > traffic > > > I also ran the route and traceroute command at both the server and > > agent end to make sure that it was being routed properly. > > > One thing I notice is that the rids file at both the server and agent > > end - that rids file is empty and stays empty Unusual.. > > > On Aug 15, 8:01 pm, "dan (ddp)" <[email protected]> wrote: > >> Use tcpdump to make sure packets are making it to the manager from the > >> agent, and to the agent from the manager. > > >> On Mon, Aug 15, 2011 at 3:43 PM, blacklight <[email protected]> wrote: > >> > The agent ossec.log files for the two agents show that the agents are > >> > operational and ready to go: > > >> > Typical example: > > >> > 2011/08/15 11:59:33 ossec-agentd(1410): INFO: Reading authentication > >> > keys file. > >> > 2011/08/15 11:59:33 ossec-agentd: INFO: Assigning sender counter: > >> > 7731:6770 > >> > 2011/08/15 11:59:33 ossec-agentd: INFO: Started (pid: 30229). > >> > 2011/08/15 11:59:33 ossec-agentd: INFO: Server IP Address: > >> > 10.80.80.100 > >> > 2011/08/15 11:59:33 ossec-agentd: INFO: Trying to connect to server > >> > (10.80.80.100:1514). > >> > ... > >> > 2011/08/15 12:06:42 ossec-agentd(4101): WARN: Waiting for server reply > >> > (not started). Tried: '10.80.80.100'. > >> > 2011/08/15 12:08:32 ossec-agentd: INFO: Trying to connect to server > >> > (10.80.80.100:1514). > > >> > On the other hand, at the server, either there is a failure to assign > >> > a sender counter i.e. the "ossec-agentd: INFO: Assigning sender > >> > counter:" does not appear, or we get > > >> > 2011/08/12 12:40:12 ossec-remoted: INFO: No previous counter available > >> > for 'vapp022.crickabold.com'. > >> > 2011/08/12 12:40:12 ossec-remoted: INFO: Assigning counter for agent > >> > vapp022.crickabold.com: '0:0'. > > >> There are no other logs related to this agent? The above messages > >> shouldn't be preventing the agent from connecting. > > >> > Under either scenario, the status of the agents is "Disconnected" > > >> > Obviously, we'd like to fix that. > > >> > On Aug 12, 2:13 pm, "dan (ddp)" <[email protected]> wrote: > >> >> On Thu, Aug 11, 2011 at 1:07 PM, blacklight <[email protected]> wrote: > >> >> > Hello Folks, > > >> >> > One of our agents is listed in the list of "Available Agents" in the > >> >> > OSSEC GUI as "Inactive" > > >> >> > Attempted Resolution: > > >> >> > (1) I logged into the OSSEC server host, ran /var/ossec/bin/ > >> >> > manage_agents to get the index ID of the host - say 140 > >> >> > (2) On the OSSEC server host, I went into /var/ossec/queue/rids and > >> >> > deleted the file 140 > > >> >> Why did you delete the rids? > > >> >> > (3) I restarted OSSEC on the OSSEC server host > > >> >> > (4) On the OSSEC agent host, I went into /var/ossec/queue/rids and > >> >> > deleted the file 140 > >> >> > (3) I restarted OSSEC on the OSSEC agent > > >> >> > This procedure works 100% of the time. Until today i.e. running /var/ > >> >> > ossec/bin/agent_control -i 140 still shows the agent as "Disconnected" > > >> >> > As a side note, I don't think anyone screwed with firewall access > >> >> > lists because our SNMP polling still correctly shows the agent host as > >> >> > operational. How should I troubleshoot this> > > >> >> > Thanks, > > >> >> You could start by looking at the ossec.log files on the agent and the > >> >> manager. > > -- > Registered Linux User # 379282
