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 <[email protected]> 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 <[email protected]>
> 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 [email protected].
> > 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 [email protected].
> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
