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.
