Unfortunately this is something that will keep coming up because of
cloud architecture and devops projects that move forward at a somewhat
fast pace.  What you're saying right now is that there is no way to
really work around this limitation?

On Jan 18, 8:35 am, "dan (ddp)" <[email protected]> wrote:
> On Wed, Jan 18, 2012 at 7:49 AM, maz <[email protected]> wrote:
> > I'm glad that there is now a way for ossec clients to automatically
> > register with the server.  This is great within any cloud
> > architecture.  While auto scaling is not ready to be implemented
> > within the application I'm currently helping design (I do all the back
> > end linux/cloud stuff, not the coding of the application) one of our
> > contracts requires that we have some form of IDS.  This is what
> > brought me to ossec in the first place.  I can auto add agents as they
> > spin up through my configuration management by utilizing agent-auth
> > and it works wonderfully.  The down side is I see no way to actually
> > have an agent tell the server daemon to remove itself.
>
> > ./agent-auth -h
>
> > OSSEC HIDS ossec-authd: Connects to the manager to extract the agent
> > key.
> > Available options:
> >        -h                  This help message.
> >        -m <manager ip>     Manager IP Address.
> >        -p <port>           Manager port (default 1515).
> >        -A <agent name>     Agent name (default is the hostname).
> >        -D <OSSEC Dir>      Location where OSSEC is installed.
>
> > For now I have been having to manually remove each agent within a test
> > environment which I find endlessly annoying.  Starting to seem like I
> > need to write a script that occasionally goes through /var/ossec/etc/
> > client.keys and then utilize an AWS query to gather information
> > regarding which instances of a machine class are running then remove
> > the lines that are no longer relelvant what so ever?
>
> > Has someone come up with a solution for having completely stateless
> > machines that can come up and disappear at the notice of a moment?
>
> I think authenticating the removal is the hard part. Adding a new
> agent isn't generally a big deal, removing one is huge.

Reply via email to