Multi server ossec cluster with shared NFS

[89be...@gmail.com]

Hi, I have 5 servers sharing the same NFS folder for /var/ossec, and it seems to be working. I've inherited this architecture. 

Right now, we have about 3000 clients that connect to an F5 vip, and then each client reports to this VIP. In the vip are 5 servers sharing the same /var/ossec nfs folder.

My question is, does this architecture work? I mean, Im having issues with some clients not connecting and I'm not sure that the correlation would work properly, it depends if all the ossec correlation reads always from disk and does not save information to memory.

This is a good setup to have HA.

Thanks!

[Michael Starks]

The only thing I can think of that might be a problem is the rids. Check
ossec.log to see if anything is being denied.

[89be...@gmail.com]

Hi,

I checked and the only thing I can find is that every second this messages appear:

2013/11/19 21:12:05 ossec-authd: INFO: New connection from x.y.c.10

2013/11/19 21:12:06 ossec-authd: ERROR: SSL read error (-1)

2013/11/19 21:12:07 ossec-authd: ERROR: SSL Accept error (0)

2013/11/19 21:12:07 ossec-authd: INFO: New connection from x.y.c.11

2013/11/19 21:12:08 ossec-authd: ERROR: SSL read error (-1)

2013/11/19 21:12:08 ossec-authd: ERROR: SSL Accept error (0)

2013/11/19 21:12:08 ossec-authd: ERROR: SSL Accept error (0)

2013/11/19 21:12:08 ossec-authd: INFO: New connection from x.y.c.11

2013/11/19 21:12:08 ossec-authd: INFO: New connection from x.y.c.10

2013/11/19 21:12:09 ossec-remoted(1213): WARN: Message from x.y.c.11 not allowed.

Could this be related?

[Michiel van Es]

Op woensdag 20 november 2013 02:14:39 UTC+1 schreef 89be...@gmail.com:

Hi,

I checked and the only thing I can find is that every second this messages appear:

2013/11/19 21:12:05 ossec-authd: INFO: New connection from x.y.c.10

2013/11/19 21:12:06 ossec-authd: ERROR: SSL read error (-1)

2013/11/19 21:12:07 ossec-authd: ERROR: SSL Accept error (0)

2013/11/19 21:12:07 ossec-authd: INFO: New connection from x.y.c.11

2013/11/19 21:12:08 ossec-authd: ERROR: SSL read error (-1)

2013/11/19 21:12:08 ossec-authd: ERROR: SSL Accept error (0)

2013/11/19 21:12:08 ossec-authd: ERROR: SSL Accept error (0)

2013/11/19 21:12:08 ossec-authd: INFO: New connection from x.y.c.11

2013/11/19 21:12:08 ossec-authd: INFO: New connection from x.y.c.10

2013/11/19 21:12:09 ossec-remoted(1213): WARN: Message from x.y.c.11 not allowed.

Could this be related?

This is strange as the agents connect 1 time to get a valid key (client.keys file) and don't have to authenticate anymore.

Since /var/ossec (and thus /var/ossec/etc/client.keys) is stored on all machines, this should allow all the agents connect to every ossec server.

I am also looking into the HA OSSEC setup and am not sure if OSSEC is HA load balancing ready.

I am looking into heartbeat with a master/slave scenario and see if that works for HA. (clients always connect to 1 server and not several different servers).

Michiel

[Roy Feintuch]

Just saw this thread and wish to add my 2 cents:
- Syscheck: there is a state that is in both memory and file system regarding the agents that finished creating the initial baseline and are ready. I suspect it might not trigger FIM alerts for new agents.
- Complex events (correlation). I'm not sure here but think there might be some state in the servers' memory. Does anyone have idea on that?
- Rids - as Michael said, it would be best to get rid of the rids check in this setup.

Cheers,
Roy


Anyway, if you have the opportunity to use some stickiness / consistent hashing so each client would be served by the same server, it would probably solve all of that.

[Topper Bowers]

Old thread. Did it end up working out? We're having trouble with the sockets being on NFS even just restarting ossec on the same host (let alone on 5).

[Sandeep C H]

Hello ,
        May i know the steps to Configure Ossec under cluster ..

Regards
Sandeep CH

[Marta Gómez]

Hello all,

I think this approach can be a little dangerous because of the race conditions. For example, if authd is running on several managers, the client.keys file will have inconsistent data.

An architecture to synchronize the client.keys and agent-info files would be enough since it is all an agent needs to report to a manager.

The "cluster of managers" is being developed by the Wazuh team for the incoming release Wazuh v3. The goal is to synchronize every file needed by a manager to work: client.keys, agent-info, fts, rids, rootcheck, syscheck, diff, custom rules and decoders and the shared directory.

Best regards,
Marta