On Wed, Jan 18, 2012 at 10:20 AM, maz <[email protected]> wrote: > 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. >
You skipped over the authentication part. ;) I'm wondering if a password and/or the client key would be enough (agent passing the key to the manager as validation that it is who it says it is). > 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.
