Now that you have a functional OSSEC installation it’s time to start configuring it. Proper configuration is really the heart and soul of OSSEC and will be the primary focus for the next few days. The primary OSSEC configuration files use an XML format. If you’re not familiar with XML, don’t worry too much. It’s a pretty easy format to wrap your head around, as you’ll see.
The primary configuration file is the /var/ossec/etc/ossec.conf file. The only exception to this is when you are using centralized agent configuration, which I highly recommend for large deployments. For a centralized setup, the server configuration is located in ossec.conf and the agent configuration is located in /var/ossec/etc/shared/agent.conf. All agents are configured using a single agent.conf file. I’ll explain how this works in a bit.
Before I get to the standard configuration options available to ossec.conf and agent.conf, let’s talk briefly about agents and centralized agent configurations. When using a centralized configuration, I recommend minimizing what you place in the agent’s ossec.conf file. The centralized agent.conf file overrides any conflicting option listed in the agent’s ossec.conf file. Besides, lingering configuration options in the agent’s ossec.conf can result in confusion when you’re not aware of those settings. To make general configuration simple and straightforward, the only option that should be present in the agent’s ossec.conf is the address of the server or servers to use.
<ossec_config>
<client>
<server-ip>192.168.0.1</server-ip>
</client>
</ossec_config>
The agent.conf file contains all of the configuration for every agent in the network. An agent will receive all of the configuration information relevant to that specific agent. The agent.conf file is actually sent to every agent in the network and each agent parses the file looking for configuration settings relevant to that local agent. This means that you can define an initial “generic” configuration block that will apply to all agents, and then use successive configuration blocks to define additional configuration options. Note: Configurations are cumulative.
It’s a bit easier to look at a simple configuration as an example. For now, don’t worry too much about what these options do, instead, concentrate on seeing how the agent builds its configuration.
<agent_config>
<syscheck>
<!– Frequency that syscheck is executed — default every 2 hours –>
<frequency>7200</frequency><!– Directories to check (perform all possible verifications) –>
<!– Files/directories to ignore –>
<directories check_all=”yes”>/etc</directories>
<ignore>/etc/adjtime</ignore>
</syscheck>
</agent_config>
<agent_config name=”agent1″>
<syscheck>
<directories check_all=”yes”>/usr/agent1</directories>
</syscheck>
</agent_config>
The above configuration is *very* tiny and very basic. However, it should help to illustrate how the agent config works. The first agent_config block defines a generic configuration that will be used for every agent in the network. The subsequent agent_config block defines an additional directory to check for agent1. So agent1 will run with the primary configuration from the first block, plus the configuration from the second block.
Each agent_config block can be defined specifically for an agent or os using the agent and os attributes. The agent attribute is simple the name (or names separates by a |) of the agent(s) to apply that agent_config block to. The os attribute is based on the uname of the agent operating system. Some examples include Linux, FreeBSD, Windows, and Darwin.
The only other real difference between a standalone or server config and an agent config is that there are some options that belong in the server config as opposed to the agent config. For instance, when we talk about active response later in the week, the active response settings are placed in the server config. Likewise, the rules are detailed in the server config and not in the agent config. This will make more sense when we cover these topics. For now, if you’re unsure as to where a particular configuration option belongs, be sure to check the OSSEC manual.
That’s all for now. Check in tomorrow when we’ll make OSSEC do something more than just sit there!