the client.keys file is managed by puppet which uses Puppet
storeconfigs, i.e. PuppetDB, to pass them around. Basically the client
comes up creates it's key and sends it off to the puppet server which
in turn sends it to the ossec server. It's entirely hands off and
requires no intervention.
--
Later,
Darin


On Mon, Apr 7, 2014 at 11:36 AM, Joshua Garnett <josh.garn...@gmail.com> wrote:
> Kai,
>
> I would argue yes.  Unless your development environment is 100% isolated
> from production it could be used to compromise other systems.  That said,
> there is auto-scaling to keep in mind also.  You may spin up 50 extra web
> servers during peak traffic on a daily basis.
>
> Darin, how do you get the keys on the server without explicitly adding them
> to your server manifest?
>
> Here is the design I've roughed out using Serf:
>
> General Notes
>
> OSSEC requires a shared secret to be installed on both the client and server
>
> /var/ossec/etc/client.keys format:   <agent id> <agent name> <ip range>
> <cipher>
>
> cipher is 2 md5sum concatenated
>
> Build base AMI, which includes OSSEC Agent & Serf, teams should use this
> base AMI
>
> Script this with packer, provide interface for getting latest AMI
>
> Most likely run OSSEC servers with an Auto Scale Group with the settings
> 1/1/1
>
> Agent Instance Start Workflow
>
> On instance start, using AWS tags, look for a running OSSEC server
>
> If no OSSEC server found, look for a running agent
> If no Agent found, error and wait X minutes to retry
>
> Instance joins serf cluster
> OSSEC server sees member-join event
>
> Generates client.keys entry
> Sends user event INSTALL_CLIENT_KEYS to agent
> Agent installs client.keys and restarts service
>
> OSSEC server sees member-leave event
>
> Removes server from client.keys
>
> Server Instance Start Workflow
>
> On instance start, using AWS tags, look for a running Agent
>
> If found, instance joins serf cluster
> If not found, instance starts serf cluster
>
> Running agents see member-join event, member is the new OSSEC Server
>
> Stops OSSEC
> Deletes client.keys
> Agent sends user event REQUEST_CLIENT_KEY to OSSEC server
> OSSEC server generates key, sends user event INSTALL_CLIENT_KEYS to agent
> Agent installs client.keys and starts service
>
> --Josh
>
>
>
> On Mon, Apr 7, 2014 at 9:07 AM, Darin Perusich <da...@darins.net> wrote:
>>
>> If you're using Puppet to manage the configuration of your systems the
>> ossec puppet module I wrote does just what you're looking for.
>>
>> https://github.com/deadpoint/ossec
>> --
>> Later,
>> Darin
>>
>>
>> On Sun, Apr 6, 2014 at 1:14 PM, Joshua Garnett <josh.garn...@gmail.com>
>> wrote:
>> > All,
>> >
>> > I'm looking for best practices for rolling out OSSEC to cloud based
>> > environments such as AWS.  One of the biggest problems I'd like to
>> > address
>> > is developer environments that may be constantly going up and down.
>> > Ideally
>> > I'd be able to put together a prebaked AMI that has an OSSEC agent
>> > already
>> > installed and preconfigured to talk to an OSSEC server.
>> >
>> > One idea I had was to setup a Serf cluster, http://www.serfdom.io/, for
>> > OSSEC, which would use a shared secret and monitor join/leave events to
>> > correctly populate the client.keys.
>> >
>> > --Josh
>> >
>> > --
>> >
>> > ---
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "ossec-list" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an
>> > email to ossec-list+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ossec-list" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to ossec-list+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to