The standalone or local configuration is perfect for managing a single server. If you have multiple servers, you'll want to use OSSEC in the server-agent model. Utilizing a server-agent model will allow agents to aggregate events and the server to make more informed decisions when alerting or taking an action.
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 have an external MS Exchange server at 1.2.3.4
We also assume that you have successfully installed OSSEC. Otherwise, you can install it from the source or with a binary installer. To install from a source, use the install.sh
command and select server
as the installation type in the first step. Binary installers will label their server packages as ossec-hids-server
.
In order to run OSSEC in server mode, you need to open up the UDP port 1514 on your firewalls from and to your OSSEC server.
Now that the server is ready, we'll have to double-check the remote namespace in the /var/ossec/etc/ossec.conf
file:
To configure the remote daemon and to communicate with them, we just need to make sure that we implement the following configuration:
<remote> <connection>secure</connection> <allowed-ips>192.168.0.0/23</allowed-ips> </remote>
Another key setting in server mode is the whitelist for active response. Set it up now as illustrated in the following configuration, even if you don't plan on utilizing the active response:
<global> <!—Our LAN --> <white_list>192.168.0.0/23</white_list> <!-- MS Exchange Server --> <white_list>1.2.3.4</white_list> </global>
We will then verify and configure our e-mail settings as follows:
<global> <email_notification>yes</email_notification> <email_to>[email protected]</email_to> <smtp_server>localhost</smtp_server> <email_from>[email protected]</email_from> </global>
We can then establish our basic e-mail and log thresholds as follows:
<alerts> <log_alert_level>1</log_alert_level> <email_alert_level>7</email_alert_level> </alerts>
Don't forget to restart the server for the changes to take effect:
$ sudo /var/ossec/bin/ossec-control restart
The simple configuration options we've specified for our server simply enable the secure communication over the UDP port 1514 between OSSEC clients and the server. We also configured the server to accept connections from our internal networks.
The best practice is to whitelist any IP addresses of potential agents as well as any known external business-critical resources. By whitelisting critical resources, we can ensure that OSSEC never interrupts service to those resources. Any resource that is critical in an emergency should be whitelisted, which is why we have whitelisted the external mail server.
Imagine being under attack and suddenly losing access to e-mail! The last two blocks configure OSSEC to send an e-mail on our network. If we need a specific SMTP server, we can tweak it here. Once we have our e-mail configured, we establish the thresholds for alerting at events whose level is 7
or higher. We will log any events whose level is 1
or higher.