I think the easiest way to go about this would be to just add a delete flag in the agent-auth binary. I'm not a developer but I can't imagine it would be all that difficult to just reverse the function the addition of an agent.
On Jan 18, 10:06 am, "dan (ddp)" <[email protected]> wrote: > On Wed, Jan 18, 2012 at 9:59 AM, maz <[email protected]> wrote: > > 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? > > I realize it will be an issue more and more. There's currently nothing > planned to deal with this limitation, but it is being thought about. > I like the idea of an independent script querying AWS to see which > instances are still alive. It solves the problem of an "agent" having > to report itself as deceased (and the authentication necessary for > that to happen). > So, it is being thought about, but it isn't considered high priority > (by me anyhow). Any ideas are welcome, especially good ones! ;) > > > > > > > > > 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.
