How to troubleshoot "Message from x.x.x.x not allowed"

[Joe S]

How are you to troubleshoot "Message from x.x.x.x not allowed"?

What does it mean? Everything I've found indicates incorrect keys, but
I've recreated and restarted ossec on both ends multiple times.

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

Any suggestions?

[Jeremy Lee]

In my experience, this usually means that a client is trying to contact the OSSEC central server but doesn't have the OSSEC agent installed or it isn't properly configured. You may need to clear out the queue on the client and the server (/var/ossec/queue/rids/# - leave the "sender_counter" alone though) if you do have the agent installed.

[Joe S]

I've figured out the problem. I suspected a problem on the server
side. To troubleshoot, I created different keys on the server for the
same agent, but I changed certain pieces of information on each to
track down the problem.

The first agent added was added via the new authd service. This agent
had the following properties:
ID: 1024
Name: <the fqdn of the agent>
IP: any

The second agent was added manually. I wanted to test manually adding
a key. The agent had the following properties:
ID: 1025
Name: testagent1025
IP: any

The third agent was added manually. I wanted to test a low number. The
agent had the following properties:
ID: 001
Name: testagent001
IP: any

The fourth agent was added manually. I wanted to test setting the IP.
The agent had the following properties:
ID: 002
Name: testagent002
IP: 1.2.3.4

I restarted the server after adding each key.
I restarted the client after adding importing each key.

The fourth agent was the only one that would work. This lead me to
conclude that the "IP: any" functionality seems to be broken. This
prevents me from using authd for large scale deployments which is
exactly what I'm trying to do.

[Joe S]

Ok. So remember the problems I was having with Atomic RPMs?

Specifying the exact IP address fixes the problem there too.

So, the confirmed issues are:

1. OSSEC 2.6 (release) and Atomic RPMs (with nightly patches) do not
seem to honor agents with "IP: any".
2. Atomic RPMs remoted logging is broken. Doesn't WARN about "Message
from x.x.x.x not allowed" when it should.

I tried to post to the Atomic forums yesterday, but my post has yet to
be approved by the moderators.

Daniel, can you forward this off to them? Thanks.

[Daniel Cid]

I am pretty sure the "any" works, because I use it a lot :) I haven't
tested with the Atomic repository, but I don't
see how it can be broken in there without heavily changing the code...

Can you start clean (removing all agents and queues) to see if it works?

Thanks,

[Joe S]

Stopped agent and server.
Removed all agents and queues (client and server).
Created new agent with IP address "any".
Exported agent key from server
Imported agent key on agent
Started server
Started client

Server fails to respond. (not allowed)

Repeated ALL of the above, but set IP address to the real IP address
of the agent.

Agent works. Again, the differentiator is the IP address being set.

Client running:
ossec-hids-2.6-5.el6.art.x86_64
ossec-hids-client-2.6-5.el6.art.x86_64

Server running:
ossec-hids-2.6-5.el5.art
ossec-hids-server-2.6-5.el5.art

[Joe S]

>
> Client running:
> ossec-hids-2.6-5.el6.art.x86_64
> ossec-hids-client-2.6-5.el6.art.x86_64
>
> Server running:
> ossec-hids-2.6-5.el5.art
> ossec-hids-server-2.6-5.el5.art
>

Still doing some tests. This time, installing both client and server
from mercurial repo.
Client complained that SSL not built in.
Installed openssl-devel.
Re-ran client install.

First test was to use agent-auth as described here:
http://dcid.me/2011/01/automatically-creating-and-setting-up-the-agent-keys/

It WORKED.

What changed?

I installed from source and installed openssl-devel on the client.

Was this a SSL issue? If not, what is it? If so, how could one derive
this from the logs?

[Joe S]

>
> It WORKED.
>

The above means that an agent with an IP of "any" works (no errors or
warnings...got agent connected email) when I used the nightly source
from mercurial on both client and server.

[Joe S]

To confirm, i removed OSSEC nightly from the client, installed the
latest Atomic RPMs and did the same exact process, but I'm now getting
error 1213 message not allowed.

[Daniel Cid]

Thanks for the tests. Is anyone using the Atomic packages and the "any" option?

thanks,

[Joe S]

Daniel,

We are still trying to debug this. We noticed a function called
OS_CheckUpdateKeys checks the access time of the client.keys file. Why
do you check this?

[Joe S]

Ok. I think we narrowed down the problem.

When we use the source code install for the client, and we extract the
client key from the server and decode it manually with base64, we see
the desired contents.

When we use the RPM install for the client, and we extract the client
key on from the server and decode it manually with base64, (invalid
input).

So the RPM client is sending a bad base64 string to the server?