high availability solution

[Panom.Na...@gmail.com]

Dear all,

Please help me on how to provide high availability, active-active or
active-standby, to OSSEC solution. I need to focus on client
server ;-)

thank you in advance

Panom N.

[carlopmart]

Use Redhat Cluster Suite, also on CentOS ....

--
CL Martinez
carlopmart {at} gmail {d0t} com

[Gansert, Matthew A]

Horrible answer. I'd like an answer on this as well. Does OSSEC have
any high availability functionality or should an administrator leave it
up to the operating system? I'm not able to find anything in wiki...

The difference will dictate how OS licensing fees will appear in a
proposal.

Matthew

------------------------------------------
The contents of this message, together with any attachments, are
intended only for the use of the person(s) to which they are
addressed and may contain confidential and/or privileged
information. Further, any medical information herein is
confidential and protected by law. It is unlawful for unauthorized
persons to use, review, copy, disclose, or disseminate confidential
medical information. If you are not the intended recipient,
immediately advise the sender and delete this message and any
attachments. Any distribution, or copying of this message, or any
attachment, is prohibited.

[Michael Starks]

Gansert, Matthew A wrote:
> Horrible answer. I'd like an answer on this as well. Does OSSEC have
> any high availability functionality or should an administrator leave it
> up to the operating system? I'm not able to find anything in wiki...

It may have not been the answer you were looking for, but please
remember that this is a community mailing list supported by volunteers.

From: http://www.ossec.net/announcements/v1.5-2008-05-02.txt

-Added support for multiple servers per agent. If one server is not
available, the agent will fall back to the second one.

I haven't personally tested it so I can't say how well it works.

[ItsMikeE]

Has anyone set up a high-availability solution?

[Daniel Cid]

Yes, and it has worked well for me.

One caveat is that the rids (message ids) will have to be
exchanged/synced between each manager in the
HA. A simple solution is to disable the id check, so it should just
work without any sync...

A good setup is like this:

[group of agents 1] -> manager 1 (backing up to manager 2 if 1 goes offline)
[group of agents 2] -> manager 2 (backing up to manager 3 if 2 goes offline)
[group of agents 3] -> manager 3 (backing up to manager 1 if 3 goes offline)

So on the agent group 1, I add the following to the config:
<server_ip>manager_1_ip</server_ip>
<server_ip>manager_2_ip</server_ip>

To disable the rids check, just edit the internal_options.conf:
# Verify msg id (set to 0 to disable it)
remoted.verify_msg_id=0

thanks,

--
Daniel B. Cid
dcid ( at ) ossec.net

[ItsMikeE]

Interesting, but not the method I had in mind. Your method would have the data split between two locations.

I was thinking along the lines of:

1 server as master with a volume containing /var/ossec which is mirrored/copied to 2nd site.

A second standby  server with the mirrored disk mounted read-only.

Both IP addresses specified in ossec.conf 

If the master fails or is unavailable, then re-mount the ossec volume as read/write, and start the ossec daemons and this becomes the new master

That way I would have all ossec info in a single place.

If the data was copied (as opposed to mirrored) then the rids issue would be the same.

Are you aware of anyone with this kind of configuration? Can you see any drawbacks?

[carlopmart]

On 01/12/2011 06:44 PM, Daniel Cid wrote:
> Yes, and it has worked well for me.
>
> One caveat is that the rids (message ids) will have to be
> exchanged/synced between each manager in the
> HA. A simple solution is to disable the id check, so it should just
> work without any sync...
>
> A good setup is like this:
>
> [group of agents 1] -> manager 1 (backing up to manager 2 if 1 goes offline)
> [group of agents 2] -> manager 2 (backing up to manager 3 if 2 goes offline)
> [group of agents 3] -> manager 3 (backing up to manager 1 if 3 goes offline)
>
> So on the agent group 1, I add the following to the config:
> <server_ip>manager_1_ip</server_ip>
> <server_ip>manager_2_ip</server_ip>
>
>
> To disable the rids check, just edit the internal_options.conf:
> # Verify msg id (set to 0 to disable it)
> remoted.verify_msg_id=0
>
>

Interesting Daniel, but where is need to disable rids check: agent, server or both??

And another question. Exists some problem to sync client.keys file between all the
servers that makes HA??

Thanks.

[loyd. darby]

DRBD is a little tricky to set up but once you do , it is rock solid.
http://www.drbd.org/

--
R. Loyd Darby, OSSIM-OCSE
Project Manager DOC/NOAA/NMFS
Infrastructure coordinator
Southeast Fisheries Science Center
305-361-4297

[dan (ddp)]

You should disable it on the manager.

[Jason 'XenoPhage' Frisvold]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jan 12, 2011, at 12:44 PM, Daniel Cid wrote:
> Yes, and it has worked well for me.
>
> One caveat is that the rids (message ids) will have to be
> exchanged/synced between each manager in the
> HA. A simple solution is to disable the id check, so it should just
> work without any sync...

I was planning on syncing the RIDs .. The RIDs shouldn't change unless a new agent is added, right?

What's the security impact of disabling the RIDs? What does that open me up for?

> Daniel B. Cid

Thanks,

- ---------------------------
Jason 'XenoPhage' Frisvold
xeno...@godshell.com
- ---------------------------
"Any sufficiently advanced magic is indistinguishable from technology."
- - Niven's Inverse of Clarke's Third Law

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)

iEYEARECAAYFAk06TlwACgkQ8CjzPZyTUTRJVwCcCESUSZOaqlv9ERfDLGXMa/0R
7xEAn2Ud2WvHEHO79mq2odb6wDm6Z1JF
=I1RZ
-----END PGP SIGNATURE-----

[dan (ddp)]

Hi Jason,

On Fri, Jan 21, 2011 at 10:26 PM, Jason 'XenoPhage' Frisvold
<xeno...@godshell.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Jan 12, 2011, at 12:44 PM, Daniel Cid wrote:
>> Yes, and it has worked well for me.
>>
>> One caveat is that the rids (message ids) will have to be
>> exchanged/synced between each manager in the
>> HA. A simple solution is to disable the id check, so it should just
>> work without any sync...
>
> I was planning on syncing the RIDs ..  The RIDs shouldn't change unless a new agent is added, right?
>
> What's the security impact of disabling the RIDs?  What does that open me up for?
>

The RIDs help protect against replay attacks. I think they're
incremented with every new message from an agent.

[Holger Gläß]

hi

this setup ist quiet simple.

use carp ( available at the most BSD like system , as FreeBSD or OpenBSD )

and ifstated ( should be also available on all BSD like system. )

you can also mirror the data with HAST on freebsd . or, in my mind best
way , mount the data volume by nfs from a storage , NAS or fileserver
system.

so looks like for example

2 freebsd systems as ossec server with one HA ip ( with carp ) and a
running ifstated daemon that he do what you want at the
failover scenario.

and , if possible , an nas / fileserver / storage for the data.
if this box not possible , do an mirror for an data volume with hat (
is include d by default in freebsd 8.1 and no additional packages
necessary ).

if you like you can crypt the whole disk,

holger glaess