I'm having some trouble with the OSSEC. I contacted Daniel Cid on the OSSEC users mailing list, but the problem isn't reproducible with the latest vanilla OSSEC source. I could reproduce the problem when using the Atomic Corp RPMs.

I have a RHEL6 client running:
ossec-hids-2.6-5.el6.art.x86_64
ossec-hids-client-2.6-5.el6.art.x86_64

I have a RHEL5 server running:
ossec-hids-server-2.6-5.el5.art
ossec-hids-2.6-5.el5.art

I generated my SSL keys and ran
# /var/ossec/bin/ossec-authd -p 1515 >/dev/null 2>&1 &

My client connects and gets its key. The keys match. I restart OSSEC
on server and client.

The client ossec log complains:
ossec-agentd: INFO: Trying to connect to server (1.2.3.4:1514).
ossec-agentd: INFO: Using IPv4 for: 1.2.3.4 .
ossec-agentd(4101): WARN: Waiting for server reply (not started). Tried: '1.2.3.4'.
ossec-agentd: INFO: Trying to connect to server (1.2.3.4:1514).
ossec-agentd: INFO: Using IPv4 for: 1.2.3.4 .

The server ossec log says:
ossec-remoted(1213): WARN: Message from 1.2.3.3 not allowed.
ossec-remoted(1213): WARN: Message from 1.2.3.3 not allowed.
ossec-remoted(1213): WARN: Message from 1.2.3.3 not allowed.
ossec-remoted(1213): WARN: Message from 1.2.3.3 not allowed.
ossec-remoted(1213): WARN: Message from 1.2.3.3 not allowed.

I replaced the Atomic OSSEC packages on BOTH the agent and server with the OSSEC vanilla source. This resulted in successful client -> server communications with no errors.

I've done some more testing. I think the problem lies with the use of "any" when configuring agents, whether by hand, with manage_agents or using the new authd.

When I download and install the client and server from the ossec "nightly" mercurial repo, the client is able to connect to the server when the IP address is set to "any".

When I use your RPMS (client and server) the client is unable to connect to the server when I specify "any" for the IP address. In addition, the remoted fails to log this message on ossec.log. To see this error, I have to run remoted with -d and -f. Then I see error 1213, "Message from x.x.x. not allowed".

Could there be an issue with the RPMs? I noticed a spec file for ossec-hids-2.6-7 but didn't see any rpms yet. I'd be happy to test.

Well Im not using the snapshots any more, so maybe this is related to running a later version than the packages. Did you try your test case with vanilla 2.6? Also ossec-hids-2.6-7 might only be in the ASL channel, they're supposed to get duplicated across both repos but that might have been implemented after 2.6-7 was done

I am experiencing the same issue, when I add an agent using client-authd/ossec-authd and the IP is <any>, it won't connect. If I update the client.keys file and change from <any> to the agent IP, it works fine. Currently, I am using RPM 2.6-5 from the repos which is dated August 19. Any time frame of when the package will get updated?

Im heading out of the country shortly, so probably not until I get back in mid/late-october

So I did some further testing and contacted Daniel Cid of OSSEC. He confirmed the issue when using the Atomic RPMs on the client.

To work around this, manually edit your client.keys file on the server and replace "any" with the IP of the host.

Curious, has anyone been able to fix the OSSEC RPMS yet? Is there anything I can do to help?

Well if you could figure out what the difference is between the build processes that would help a lot. Maybe its a library or something, I'm in the dark on this one too

I don't know how you guys build the rpms. I wonder if there is something that is getting added/modified that is causing this. Does the maintainer of the RPMs visit the forums?

Sure, that would be me. The .spec file is here:


http://www4.atomicorp.com/channels/sour ... -hids.spec

If you look at the %build macro, you'll see how it gets compiled. Above that are the dependencies that get installed into the build environment (called mock).

JFYI, the problem with remoted not logging is because /var/ossec/logs isn't g+w, so remoted can't log there.

Fix that, and you'll at least see the errors.

Awesome! Thanks for the follow up on this