On Tue, Mar 6, 2012 at 2:37 PM, Scott Mace <[email protected]> wrote: > Can't. It's an AlienVault appliance, and upgrading to 2.6 breaks the
Sounds like a problem you should bring to them. The server needs to be the same version or higher than the agents. Always. > SIEM functionality for analyzing Ossec alerts. So I hear you and > agree, but I'm kind of stuck in a situation where I have to roll out > agents, AlienVault tells me they are working to integrate 2.6, and I > can't wait for that to happen, and I don't want to roll out an older > agent, just to have to upgrade later. > > Now, if anyone has been able to get 2.6 working correctly and fully > integrated in Ossim/AlienVault, I'm all ears! > > Scott > > On Tue, Mar 6, 2012 at 1:16 PM, dan (ddp) <[email protected]> wrote: >> On Tue, Mar 6, 2012 at 1:59 PM, Scott Mace <[email protected]> wrote: >>> I've seen this issue raised before, but never answered. There is a >>> firewall between the agent and server, but proper access lists are in >>> place. I used netcat to verify communication is working fine both >>> ways, for udp port 1514, and various random high ports from the server >>> to the client, just in case. Agent is 2.6, server is 2.5.1 >> >> Upgrade your server. Agents shouldn't ever be a later version than the >> server. >> >>> (AlienVault server) >>> >>> The problem even after the above: >>> From agent log, this message repeated: >>> 2012/03/06 11:02:23 ossec-agentd: INFO: Using IPv4 for: 10.10.xxx.51 . >>> 2012/03/06 11:02:24 ossec-agentd(1214): WARN: Problem receiving >>> message from 10.10.xxx.51. >>> 2012/03/06 11:02:33 ossec-agentd(1214): WARN: Problem receiving >>> message from 10.10.xxx.51. >>> 2012/03/06 11:02:38 ossec-agentd(1214): WARN: Problem receiving >>> message from 10.10.xxx.51. >>> 2012/03/06 11:02:44 ossec-agentd(1214): WARN: Problem receiving >>> message from 10.10.xxx.51. >>> 2012/03/06 11:02:44 ossec-agentd(4101): WARN: Waiting for server reply >>> (not started). Tried: '10.10.xxx.51'. >>> >>> Server side, list agents says the client in question has never connected. >>> >>> Solution: >>> I did three things to get this to work: >>> Remove said agent from the sever >>> Recreate agent on server using FQDN as the host name, (originally >>> using short hostname) and >>> IP address in full CIDR format: xxx.xxx.xxx.xxx/32 (originally without /32) >>> >>> Once that was done, re-import the key into the agent box, and restart >>> server and agent processes. Worked fine after that. >>> >>> Scott
