Using Bigfix for Mass Deployments of OSSEC agents for Windows

Ok, say you want to deploy 100 or more agents of OSSEC. Connecting to each one, manually installing the agent, pasting your ossec agent key in, and then starting the agent can take quite some time.

Using a Systems Management product such as Bigfix can make this task much easier. However, I would be remiss if I didn't point out that there are trade-offs using this deployment approach. The client key for ossec is what the system uses to sign/encrypt the log messages from agent to server (and vice versa I imagine as well), and the deployment options I am showing do present some risk of that client key being potentially revealed to an attacker. You will have to evaluate your own risk tolerance on this.

The method I showed in my previous blog post worked for one computer at a time, since you had to paste the line for the agent you are wanting to install at the time of deployment. This method will allow you to deploy to as many computers as you want.

The process involves these steps:

1. Add your agents to the ossec server (either via manage_agents or other import method).

2. Created a hidden "null" share somewhere on your network. Bigfix runs as SYSTEM, so the share will have to be assigned Everyone:Read permissions. Copy the client.keys file from your ossec server to this hidden null share. If you recognized the first trade-off to security, congratulations! You should delete this client.keys file from the share as soon as your deployment is done.

3. Run your Bigfix task to deploy the ossec agent. Each agent will query the clients.key file and extract their own key from it.

The Bigfix task should be built similiarly to my previous post on this subject, but substitute the following action script (after the extract statement):

wait __Download\ossec-agent-win32-2.5.1.exe /S

copy "\\SERVER01\OSSEC$\client.keys" "__Download\client.keys"
appendfile {line whose (it as lowercase contains computer name as lowercase) of file "__Download\client.keys"}

delete "C:\Program Files\ossec-agent\client.keys"
copy __appendfile "C:\Program Files\ossec-agent\client.keys"

delete "C:\Program Files\ossec-agent\ossec.conf"
copy __Download\ossec.conf "C:\Program Files\ossec-agent\ossec.conf"

wait "SC" start OssecSvc

The magic is done in this line:

appendfile {line whose (it as lowercase contains computer name as lowercase) of file "__Download\client.keys"}

which searches the client.keys file downloaded from your hidden share and builds the proper client.keys file for each computer deployed to.

Security wise, this task is a little better than the previous task, as the client key will only be leaked to the local Bigfix client log file on each computer where the OSSEC agent is deployed to (not counting the everyone read hidden share where ALL client keys will exist for the length of your deployment, because you will delete it promptly afterwards, right?).

Well, there is a second method for deploying the OSSEC agent, and this one will deploy to 10, 100 or even 1000 computers in 5-10 minutes (assuming a healthy Bigfix setup.) Nice! Just remember that this flexibility is coming at some reduced security, and take that increased risk into account. I won't be held responsible if things don't work out. :)

In the next day or two, I'll try to find the time to write a blog about mass deployments for Windows using just batch files, and other poor man's tools. Using the same techniques, you can easily build a deployment script based on the psexec tool and batch files.

Update: there are some ways to increase the security of this task. Instead of using the fancy relevance substitution shown above to extract the client key, using something like: find "{computer name}" > client.keys will solve the problem of the client key being written to the Bigfix client log (which will exist until the logs roll over-about 7 days.) Then you are left only with the open share and potentialy clear text transfer of the client.keys to your computers (depending on how your network is configured). Setting up auditing on the share folder is one method to identify if unauthorized parties accessed your client.keys file while your deployment was running. The man-in-the-middle attack is another thing though... but not a problem unique to this method.