Now that the server has been configured, this recipe covers how one can configure the clients to connect to the server to increase the intelligence and relevance of alerts.
In this example, we assume that the:
OSSEC server is 192.168.0.1
Our servers live on 192.168.0.0/23 (192.168.0.1 to 192.168.1.254)
We also assume that you have successfully installed OSSEC. You can install it from the source or with a binary installer. To install from a source, use the install.sh command and select agent as the installation type in the first step. Binary installers will label their agent packages as either agent or client. The Debian package is labeled ossec-hids-agent and the Red Hat package is labeled ossec-hids-client.
If you're using a binary package, the ossec.conf file will need to be updated. We need to point the OSSEC agent process to the correct server. For our example network, we'd modify the /var/ossec/etc/ossec.conf file to have its client section look similar to the following:
<client>
<server-ip>192.168.0.1</server-ip>
</client>The only other thing we need to do is to set up the client and server keys.
If you were to start OSSEC at this point, the ossec-agentd component would fail to start while the rest of the components would function. This is because you have not told the OSSEC server about the existence of this new agent. To do that, we need to create keys and import them on the client:
On the server, perform the following:
$ sudo /var/ossec/bin/manage_agents **************************************** * OSSEC HIDS v2.7.1 Agent manager. * * The following options are available: * **************************************** (A)dd an agent (A). (E)xtract key for an agent (E). (L)ist already added agents (L). (R)emove an agent (R). (Q)uit. Choose your action: A,E,L,R or Q:
Select
Ato add an agent. You will be prompted for that agent's fully qualified domain name and IP address. Once you've confirmed adding the agent, you'll receive the menu again. This time, you need to extract the agent key for importing the client, so selectEand enter the ID of the agent you just created. You'll be presented with an output that looks similar to the following:Agent key information for '001' is: MDAxIHNlcnZlci5leGFtcGxlLm5ldCAxOTIuMTY4LjAuMTUyIDgyZTZjNjI1ZDQ2ZmI2MDlkYTFmMDkxNDA2NTYwNTU2YWQyZGZhMTBmZGYwMGJlODcwNTAxYTcxNDY5MWMxMmY=
The agent key is Base64 encoded and in this case starts with
MDAx. Copy that key to your clipboard; on the client, run themanage_clientscript to import it:$ sudo /var/ossec/bin/manage_client **************************************** * OSSEC HIDS v2.7.1 Agent manager. * * The following options are available: * **************************************** (I)mport key from the server (I). (Q)uit. Choose your action: I or Q:
Choose
Ito import the key and paste the Base64-encoded string into the prompt. You should now see the key information decoded as:Agent information: ID:001 Name:server.example.net IP Address:192.168.0.152
If everything looks correct, press Y to import the key. At this point, the client and server are aware of each other, and you may start (or restart) OSSEC on the client as follows:
$ sudo /var/ossec/bin/ossec-control restart
This process creates the shared secret key between the OSSEC server and the client. With this key, and a combination of the ID and IP of the client, messages may pass safely between the server and client. This ensures that the commands coming in over UDP are legitimate commands from the server and not an attacker masquerading as the OSSEC server.
The /var/ossec/etc/client.keys key file on the OSSEC server should be considered sensitive and any unauthorized access to it should prompt serious actions, such as resetting the keys on all the clients. The client.keys file should be as restricted as possible on every system to prevent tampering. The default permissions allow only the group ossec to read the file.
Key management can slow down the automated deployments. Luckily, OSSEC fixed this in the version 2.5 with the introduction of the authentication daemon.
The manual key setup process is burdensome, especially if you'd like to deploy to hundreds or thousands of servers. To fix this, the ossec-authd file was introduced to provide a mechanism for an agent to request a key if one does not exist.
On the server, /var/ossec/bin/ossec-authd is installed with the server profile. And on the client, /var/ossec/bin/agent-auth is installed as a part of the agent profile.
The ossec-authd file is a simple daemon that has a single configurable option and the port to use, which is specified on the command line via the -p option (the default is 1515):
$ sudo /var/ossec/bin/ossec-authd -p 1515
You may also need to create the SSL keys for ossec-authd. To do so:
$ 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
On the client, we use the agent-auth command to request a key from the OSSEC server. The -m option manages the keys and the OSSEC server in our example. The -A option is the agent name, which defaults to the hostname (as does our example):
$ sudo /var/ossec/bin/agent-auth -m 192.168.0.1 -A $(hostname)
If this is successful, you should be able to view the contents of the client file:
$ sudo cat /var/ossec/etc/client.keys
Tip
Downloading the example code
You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.