ossec-authd or agent-auth is not creating valid keys

[Joe S]

After numerous days of testing, I can confirm that invalid keys are
getting created when I use the process described here:

http://dcid.me/2011/01/automatically-creating-and-setting-up-the-agent-keys/

I rolled out the Atomic ossec-client RPM to 10 clients. The clients
keys get populated in the OSSEC server. After restarting the server,
my logs are filled with ERROR 1213 (host x.x.x.x not allowed). When I
delete the key and recreate it, it works.

Note: When I run base64 -d and paste the base64 key, I get the same
string in the client.keys file, but at the end is says:

"base64: invalid input"

That ^^ appears to be a problem.

[Joe S]

On Oct 4, 11:22 am, Joe S <js.li...@gmail.com> wrote:
> After numerous days of testing, I can confirm that invalid keys are
> getting created when I use the process described here:
>

> http://dcid.me/2011/01/automatically-creating-and-setting-up-the-agen...

>
> I rolled out the Atomic ossec-client RPM to 10 clients. The clients
> keys get populated in the OSSEC server. After restarting the server,
> my logs are filled with ERROR 1213 (host x.x.x.x not allowed). When I
> delete the key and recreate it, it works.
>
> Note: When I run base64 -d and paste the base64 key, I get the same
> string in the client.keys file, but at the end is says:
>
> "base64: invalid input"
>
> That ^^ appears to be a problem.

I don't know what to do. I can't undertand why I'm getting:

2011/10/04 11:40:44 ossec-remoted(1213): WARN: Message from x.x.x.x
not allowed.

I've used keys with or via:

* the authd/agent-auth registration
* short hostname
* short id number (001 instead of 1024)

Each time I import the key and restart the client and server, I still
get these messages.

Then I create the key, with long hostname, key id of 1040, BUT I SET
THE IP ADDRESS, and it WORKS.

IP of ANY is still not working of me on the following setup:

* Clients (multiple RHEL 6.1 AMD64) using Atomic ossec-hids-client
* Server (RHEL 5.7 AMD64) using OSSEC tar.gz with patches from
mercurial.

I know this is an open source project and I intend to make no demands
of anyone's time. I don't know if this is a bug or an undocumented
feature. It seems like a bug, but the last email thread I had with
Daniel indicated that this couldn't be a bug and that significant code
would have had to have been changed for this to be true.

So I don't know what to do.

:-\

[Joe S]

> IP of ANY is still not working of me on the following setup:
>
> * Clients (multiple RHEL 6.1 AMD64) using Atomic ossec-hids-client
> * Server (RHEL 5.7 AMD64) using OSSEC tar.gz with patches from
> mercurial.
>
> I know this is an open source project and I intend to make no demands
> of anyone's time. I don't know if this is a bug or an undocumented
> feature. It seems like a bug, but the last email thread I had with
> Daniel indicated that this couldn't be a bug and that significant code
> would have had to have been changed for this to be true.
>
> So I don't know what to do.

Here's what works.

Manually edit the client.keys file. Replace "ANY" with the IP Address
of the host. Save file. Extract key and restart server.
Import key on client, restart client.
It works.

What is the string after the IP/any field in client.keys? What is it
used for? Is it some kind of hash used for authentication?

[dan (ddp)]

Yes, that is the key.

I just setup to CentOS 6.0 x86_64 systems.
I installed OSSEC on each (post 2.6 source, but I don't think anything
has really changed in the auth stuff).
One system became an OSSEC server.
The other an agent.
I setup ossec-authd, and then ran agent-auth (copy & pasted most of it
from dcid's blog post).
No errors so far.

So the problem seems to either be your systems, or the atomic RPMs.

[dan (ddp)]

It doesn't seem to work for me with atomic RPMs either, but I don't
get any errors. Just no connection.

[Joe S]

On Oct 4, 12:42 pm, "dan (ddp)" <ddp...@gmail.com> wrote:

> On Tue, Oct 4, 2011 at 3:17 PM, Joe S <js.li...@gmail.com> wrote:
>
> >> IP of ANY is still not working of me on the following setup:
>
> >> * Clients (multiple RHEL 6.1 AMD64) using Atomic ossec-hids-client
> >> * Server (RHEL 5.7 AMD64) using OSSEC tar.gz with patches from
> >> mercurial.
>
> >> I know this is an open source project and I intend to make no demands
> >> of anyone's time. I don't know if this is a bug or an undocumented
> >> feature. It seems like a bug, but the last email thread I had with
> >> Daniel indicated that this couldn't be a bug and that significant code
> >> would have had to have been changed for this to be true.
>
> >> So I don't know what to do.
>
> > Here's what works.
>
> > Manually edit the client.keys file. Replace "ANY" with the IP Address
> > of the host. Save file. Extract key and restart server.
> > Import key on client, restart client.
> > It works.
>
> > What is the string after the IP/any field in client.keys? What is it
> > used for? Is it some kind of hash used for authentication?
>
> Yes, that is the key.
>

So when I looked at the server code, it appears that it checks the key
first, then if that fails it checks the IP, and if the IP doesn't
match, it gives the 1213 error. It can't match the IP because we are
using "any".

Could this be a problem with how the key is created in the first
place? Does the key creation rely on some library? Perhaps it's
failing because my systems are not the exact same systems the RPMs
where created on?

These are just theories. Let me know if you want me to try anything.

[Joe S]

>
> > So the problem seems to either be your systems, or the atomic RPMs.
>
> It doesn't seem to work for me with atomic RPMs either, but I don't
> get any errors. Just no connection.

The atomic RPMs remoted logging seems broken. Install the server from
source and you'll get the 1213 errors

[dan (ddp)]

I do not. See the email I sent earlier. It worked fine for me when I
compiled the source.

[dan (ddp)]

On Tue, Oct 4, 2011 at 6:35 PM, Joe S <js.l...@gmail.com> wrote:
>
> So when I looked at the server code, it appears that it checks the key
> first, then if that fails it checks the IP, and if the IP doesn't
> match, it gives the 1213 error. It can't match the IP because we are
> using "any".
>

'any' is supposed to mean any. So any ip will match.

[Joe S]

So, would you agree that OSSEC 2.6 is just fine and the problem is
with the Atomic RPMs?

Do you know if the rpm spec files will be updated anytime soon?

[dan (ddp)]

On Tue, Oct 11, 2011 at 5:19 PM, Joe S <js.l...@gmail.com> wrote:
> So, would you agree that OSSEC 2.6 is just fine and the problem is
> with the Atomic RPMs?
>

Yes. I've notified them (via IRC) that there is an issue.

> Do you know if the rpm spec files will be updated anytime soon?
>

In the OSSEC source or Atomic's spec files? If you mean the OSSEC
ones, probably whenever someone sends in an update.
They're not something that's high on the priority list, especially
since they're in the "contrib" directory.
I am kind of looking at them though. :P

[Kat]

Anyone every come up with a solution to this? I built rpms from the
Atomic SPEC (modified) and same issue - if I replace "any" with the
IP, it works, and I don't have to extract or reset the client end, it
just magically starts working with I replace "any" with the IP.

Trying to figure out what, in the SPEC file/build, might be causing
this.

Going to start looking through the build process and the SPEC file and
see if I can figure it out, unless someone already has.

thanks

On Oct 11, 4:35 pm, "dan (ddp)" <ddp...@gmail.com> wrote:

[Joe S]

I wanted to look into this further, but I haven't had a lot of time.
Please let us know what you find. I think we're on our own as far as
getting working RPMs are concerned.

[dan (ddp)]

On Thu, Oct 27, 2011 at 12:50 AM, Joe S <js.l...@gmail.com> wrote:
> I wanted to look into this further, but I haven't had a lot of time.
> Please let us know what you find. I think we're on our own as far as
> getting working RPMs are concerned.
>

What do you mean you're on your own?

[dan (ddp)]

I created some RPMs (based on Atomic's I think, but without the mysql
crap and extras, and based on more current source). Unfortunately I
haven't put enough time into it to figure out how to get decent
ossec.confs in each package. It's kind of annoying.

I created 2 virtual Centos 6 systems to test them.

1 system got the -server, and the other -client. This combination did not work.
The server side does not even seem to recognize the client.
list_agents -a didn't show the agent until I changed the any to an IP.
I was also getting the not allowed error.

Using manage_agents to extract the key and import it into the agent
did not solve the issue.

I then used an lxc installed debian with ossec installed via source.
The agent-auth worked just fine, the agent connected with no errors.

So the issue seems to be in the RPM's agent-auth?

Thoughts? Ideas?

[Joe S]

On Thu, Oct 27, 2011 at 5:36 AM, dan (ddp) <ddp...@gmail.com> wrote:
> On Thu, Oct 27, 2011 at 12:50 AM, Joe S <js.l...@gmail.com> wrote:
>> I wanted to look into this further, but I haven't had a lot of time.
>> Please let us know what you find. I think we're on our own as far as
>> getting working RPMs are concerned.
>>
>
> What do you mean you're on your own?

I mean, it's up to us to figure it out why the RPMs don't work. I said
that because no one at Atomic has been able to assist up to this
point. The only response I got was to 'look at the the spec file' and
"I'm in the dark on this one too". Was I incorrect? Were you able to
muster some support from Atomic?

[dan (ddp)]

Beyond reporting it to them, I haven't really tried.

[Kat]

I am taking this up on my own to resolve this... Pretty good at RPMs -
working on a solution and a new SPEC file..

More to follow
-K

[Joe S]

I'm happy to help test.

[dan (ddp)]

I'll delete what I've got then.