The complain I hear more often about OSSEC is related to how hard it is to setup the authentication keys between the agents and the manager. Each agent share a key-pair with the manager, so if you have a thousand agents, you need a thousand keys.
To make life easier, we added a new daemon on the manager, called ossec-authd. To get that working, you need the latest snapshot (just get from here:https://bitbucket.org/dcid/ossec-hids (click on get source)).
Once you have the new version running, you need to create the certificate / private key for SSL (note that OSSEC will look at /var/ossec/etc/sslmanager.cert and /var/ossec/etc/sslmanager.key for them).
# openssl genrsa -out /var/ossec/etc/sslmanager.key 2048
# openssl req -new -x509 -key /var/ossec/etc/sslmanager.key -out /var/ossec/etc/sslmanager.cert -days 365
*note that you only need to run this command on the manager (not on the agents)
Once the keys are created, you can start the ossec-authd:
# /var/ossec/bin/ossec-authd -p 1515 >/dev/null 2>&1 &
Setting up the agents
On the agents, the work is minimal. All you have to do is to run the following command:
# /var/ossec/bin/agent-auth -m 192.168.1.1 -p 1515
INFO: Connected to 192.168.1.1:1515
INFO: Using agent name as: melancia
INFO: Send request to manager. Waiting for reply.
INFO: Received response with agent key
INFO: Valid key created. Finished.
INFO: Connection closed.
Where 192.168.1.1 is your manager IP address. Inside the manager, you will also see the logs:
2011/01/19 15:04:40 ossec-authd: INFO: New connection from 192.168.10.5
2011/01/19 15:04:41 ossec-authd: INFO: Received request for a new agent (melancia) from: 192.168.10.5
2011/01/19 15:04:41 ossec-authd: INFO: Agent key generated for melancia (requested by 192.168.10.5)
2011/01/19 15:04:41 ossec-authd: INFO: Agent key created for melancia (requested by 192.168.10.5)
That’s it. The keys are now exchanged and you can start your agent. Note that I don’t recommend to keep the ossec-authd running during “normal” operations, only when you are setting up your agents.
The code is still in alpha/beta mode, so let us know if you find any issues (I have been using for a little while, so should be stable).
Did you mean -p 1514 instead of -p 1515?
No, it is actually 1515 (or any other port). Since it runs on TCP and uses a different channel than the default one…
Thank you so much. This will be of great help to anyone managing more than a handful of agents.
This doesn’t seem to work with the new Windows agent that I can see. Also, the events in the WebGUI seem to get munged with this update.
Will the same Agent command work for Windows Agents?
Hi-
Is this functionality available or is it being planned for the Windows agent?
Thanks
Good daemon. Using it for a Puppet deployment and it makes life a lot easier.
One small thing I noticed was that agent-auth on the agent (v2.6) always seems to return 1, even if the key was successfully received from the server. I think this is due to main_client.c calling exit(1) on Connection Closed. However, on my set up (Debian Squeeze) the agent-auth process always ends with Connection Closed even when successful.
Not a big deal but makes it awkward to programmatically detect whether the update was successful or not.
Hi,
Is agent-auth got an equivilent application for the windows ossec client? I notice you only have the instructions for linux clients, does this mean there is no agent-auth for windows clients?
Jake.
Executing /var/ossec/bin/agent-auth …. gives following error
ERROR: Not compiled. Missing OpenSSL support.
Would appreciate any help.
Running command agent-auth on an agent produces the following error
ERROR: Not compiled. Missing OpenSSL support.
Hi,
you have to install OpenSSL Development Pakage before installing OSSEC
I know I’m dredging up something old here. I have the latest version of ossec compiled on ubuntu 11.10. I can get an agent to authenticate no problems. I’m working in AWS right now and getting prepared for autoscaling certain portions of an application.
I see no easy way to automatically delete agents that have been murdered due to low use from the application stand point. Where as when a new machine in a machine class spins up it will automatically add itself.
What’s the best way to go about auto deletion when an instance is going the way of the do-do?
How does this work in a multi-server fail-over environment?
Do we have to use the same key-certificate for all the servers?
ERROR: Not compiled. Missing OpenSSL support.
install openssl-devel and recompile ossec.
Pingback: Configurando os agentes do Ossec HIDS automaticamente no Linux | Alexos Core Labs