Use OSSEC HIDS to monitor logs and the filesystem integrity of your servers and to correlate events.
Securing a server doesn’t end with locking it down. Servers need to be monitored constantly. While network intrusion detection systems are invaluable for alerting you to possible attacks against any number of systems on your network, they should really only be thought of as early warning systems. Ultimately, you’ll need to monitor each of your systems in greater detail. This involves keeping an eye on many different pieces of information for each system, watching multitudes of different log files for evidence of attacks, and inspecting important binaries for signs of tampering.
While you can use a variety of tools to aggregate logs from multiple systems [Hack #79], automatically alert on certain strings [Hack #83], and check for modified files [Hack #122] and rootkits [Hack #124], these tools lack integration and, in the end, become just more things that need to be monitored.
Thankfully, one tool can perform all of these tasks and more: OSSEC HIDS (http://www.ossec.net). This leads to a sort of synergy that is not achievable with the separate monitoring systems without additional integration work. For instance, OSSEC can correlate events across different log files to trigger specialized alerts. You can also deploy OSSEC in a client/server architecture and easily scale it to monitor additional servers as you add them to your infrastructure. And OSSEC is available for both Windows and Unix systems, which enables you to monitor the integrity of all your systems with a single tool.
Getting started with OSSEC is easy. To install it, download the tarball from the OSSEC HIDS web site and unpack it. Then, change into the directory that was created (e.g., ossec-hids-0.8) and run the install.sh script. After being asking which language to use for the installation, you’ll see a prompt like this:
1- What kind of installation do you want (server, agent, local or help)?
If you want to install OSSEC on only a single machine, choose local. Of course, if you want to set up an OSSEC client or a server, choose either agent or server, respectively.
After you’ve chosen the type of installation to perform, the script will ask you where to install it and where to send email alerts. At this point, you can choose whether to install the system integrity checking and rootkit detection components and whether to enable active responses. This feature allows you to react to events automatically as they happen, so you can prevent intrusions from succeeding.
If you chose to do a local installation, all you need to do is configure OSSEC. But before we look at how to do that, let’s look at how to do a client/server installation.
First, you’ll need to perform a server installation on a machine. Then, you’ll need to perform an agent install on one or more hosts. When selecting an agent install, you’ll get this additional prompt:
3.1- What's the IP Address of the OSSEC HIDS server?:
Type the IP address of the machine on which you performed the server installation. The rest of the prompts will be the same. The process that listens for agents, ossec-remoted, uses UDP port 1514, so make sure that your firewall rules will let traffic from the agents reach it.
After you’ve installed an agent, go to the system where you’ve installed the server and add the agent:
#/var/ossec/bin/manage_agents**************************************** * OSSEC HIDS v0.8 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 actions: A,E,L,R or Q:a- Adding a new agent (use '\'' to return to main menu). Please provide the following: * A name for the new agent: spek * The IP Address for the new agent: 192.168.0.62 * An ID for the new agent[001]: Agent information: ID:001 Name:spek IP Address:192.168.0.62 Confirm adding it?(y/n):yAdded.
You’ll then need to extract the key that was generated for the agent and import it into the agent itself, so that it can talk to the server. Do this by running manage_agents again and typing e at the prompt:
... Choose your actions: A,E,L,R or Q:eAvailable agents: ID: 001, Name: spek, IP: 192.168.0.62 Provide the ID of the agent to extract the key (or '\'' to quit):1Agent key information for '001' is: MDAxIHNwZWsgMTkyLjE2OC4wLjYyIDhhNzVmNGY1ZjBmNTIzNzI5NzAzMTRjMTFmNGVlOWZhZDEzY2QxZWY1ODQyZDEyMmFjYjM2YzVmY2JmYTg5OGM= ** Press ENTER to return main menu.
Now, go to the agent and do the following:
#/var/ossec/bin/manage_agents**************************************** * OSSEC HIDS v0.8 Agent manager. * * The following options are available: * **************************************** (I)mport key for the server (I). (Q)uit. Choose your actions: I or Q:i* Provide the Key generated from the server. * The best approach is to cut and paste it. *** OBS: Do not include spaces or new lines. Paste it here (or '\'' to quit):MDAxIHNwZWsgMTkyLjE2OC4wLjYyIDhhNzVmNGY1ZjBmNTIzNzI5NzAzMTRjMTFmNGVlOWZhZDEzY2QxZWY1ODQyZDEyMmFjYjM2YzVmY2JmYTg5OGM=Agent information: ID:001 Name:spek IP Address:192.168.0.62 Confirm adding it?(y/n):yAdded. ** Press ENTER to return main menu.
Then start the server:
# /var/ossec/bin/ossec-control start
Starting OSSEC HIDS v0.8 (by Daniel B. Cid)...
Started ossec-maild...
Started ossec-execd...
Started ossec-analysisd...
Started ossec-logcollector...
Started ossec-remoted...
Started ossec-syscheckd...
Completed.Finally, start the agents:
# /var/ossec/bin/ossec-control start
Starting OSSEC HIDS v0.8 (by Daniel B. Cid)...
Started ossec-execd...
Started ossec-agentd...
Started ossec-logcollector...
Started ossec-syscheckd...
Completed.Unfortunately, the server will not provide any indication that the client can or has connected to it until an alert is generated, so you’ll want to test it out by attempting to generate an alert. For instance, if you’re running an SSH daemon on the agent system, you could try to SSH to the root account (hopefully, you have root logins disabled, so this will be innocuous). If you chose the default installation location for the server, you should be able to find the alerts in /var/ossec/logs/alerts. Alerts are organized into directories by year and month with separate files for each day (e.g., 2006/Jun/ossec-alerts-01.log).
Check the proper alerts file, and you should see something similar to this:
** Alert 1149663466.1082: 2006 Jun 01 00:57:46 (spek) 192.168.0.62->/var/log/messages Rule: 401 (level 5) -> 'User authentication failure.' Src IP: (none) User: (none) sshd(pam_unix)[7917]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=kryten.nnc user=root ** Alert 1149663468.1362: 2006 Jun 01 00:57:48 (spek) 192.168.0.62->/var/log/secure Rule: 1516 (level 5) -> 'SSHD authentication failed.' Src IP: 192.168.0.60 User: root sshd[7917]: Failed password for root from 192.168.0.60 port 64206 ssh2 ** Alert 1149663480.1604: mail 2006 Jun 01 00:58:00 (spek) 192.168.0.62->/var/log/messages Rule: 402 (level 10) -> 'User missed the password more than one time' Src IP: (none) User: (none) sshd(pam_unix)[7917]: 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=kryten.nnc user=root
You should also receive these alerts at the email address you specified on the server during the installation process.
The Windows version of OSSEC supports only the agent installation, which you can set up by simply downloading the installer and launching it. When it starts, it will ask you where to install the files and then execute the manage_agents program. Here, you can import the key that you’ve generated for it the same way you did for the Unix version of the agent. After you’ve entered the key and exited the agent management program, the installer will present you with the OSSEC configuration file ossec.conf, which is stored in the directory into which you chose to install the agent.
Unfortunately, the Windows installer isn’t as automated as the Unix install script is, so you’ll have to enter the IP address of your OSSEC server manually. Locate the line that looks like this:
<server-ip>a.b.c.d</server-ip>
and replace a.b.c.d with the IP address of your server. After the installation has completed, go to the Services Control Panel applet, locate the OSSEC HIDS service, and start it. While you’re at it, you’ll probably want to also set it to start automatically at system boot.
Now you can test it out with an approach similar to the one previously used to test out the Unix agent. If you have account login auditing enabled for the system, you can attempt to log into an account with an incorrect password, which should create something like this in the current log file on your OSSEC server:
** Alert 1149742916.124085: 2006 Jun 02 23:01:56 (blackbird) 192.168.0.67->WinEvtLog Rule: 8005 (level 4) -> 'Windows audit failure event.' Src IP: (none) User: SYSTEM WinEvtLog: Security: AUDIT_FAILURE(680): Security: SYSTEM: NT AUTHORITY: BLACKBIRD: Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Logon account: andrew Source Workstation: BLACKBIRD Error Code: 0xC000006A
OSSEC’s default configuration file is formatted in XML and located at /var/ossec/etc/ossec.conf (on Windows, this file will be in the directory into which you chose to install OSSEC). Sections of particular interest for servers are the <syscheck>, <localfile>, <alerts>, and <global> sections. The <syscheck> section defines what files and directories OSSEC should check for signs of tampering. The <frequency> tag specifies how often to perform the check:
<frequency>7200</frequency>
7200 seconds (every two hours) is the default. If you’re running services that are highly taxing on your disk subsystem, you might want to increase this value, because checksumming files can be quite I/O intensive.
Specify which directories to check with the <directories> tag. The default is to perform all checks on the files in each of the directories enclosed within the tag in a comma-delimited list. This means that OSSEC will compare each file’s MD5 checksum to previous values, as well as its size, owner, group, and permissions. The default configuration file checks in the following directories:
<directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories> <directories check_all="yes">/bin,/sbin</directories>
Turn individual checks on or off by replacing the check_all attribute with any combination of check_sum, check_size, check_owner, check_group, or check_perm and setting them to either yes or no. If you want to ignore a particular file or directory, enclose it in <ignore> tags:
<ignore>/etc/mtab</ignore>
Moving on, <localfile> sections are used to specify log files to monitor. Within them, you can use the <location> tag to specify the full path to the log file. Specify the format of the file with the <log_format> tag. Valid values for the format are syslog, snort-full, snort-fast, squid, or apache. Additionally, Windows users will find the iis and eventlog formats to be of particular interest, because they allow OSSEC to parse your IIS and Event Logs.
When an alert is triggered, OSSEC associates a severity level with it (from 1 to 16). You can use the <alerts> section to set the threshold at which to log an alert or generate an email. Here are the defaults for these settings:
<alerts>
<log_alert_level>1</log_alert_level>
<email_alert_level>7</email_alert_level>
</alerts>Finally, use the <globals> section to define miscellaneous options that affect OSSEC as a whole. For instance, you can modify the email settings that the install script configured for you in this section.
This is also where you can use the <white_list> tag to specify the hosts that should never be blocked with active responses. For instance, to make sure that 10.0.0.123 is never blocked, add a line like this to the <globals> section:
<white_list>10.0.0.123</white_list>
Now, let’s look at how to configure active responses.
Active responses can vary from blocking hosts via firewalls to automatically disabling user accounts. This is a powerful feature, but take special care when using it. An active response might cause you to inadvertently DoS yourself or provide easy means for an attacker to do so. That’s why OSSEC provides a white-listing feature, to make sure dynamically added firewall rules don’t lock out trusted hosts.
Active responses in OSSEC work by tying a command to an alert level and any number of rule IDs. The active response is triggered when an alert for one of the rules you’ve specified is generated and its level meets or exceeds the one specified.
When setting up an active response, you must first define the command to run and its parameters. Within a <command> block, define a name for the command that will be executed when the command is associated with one or more rules in an <active-response> block.
Here’s an example from OSSEC’s default configuration file. The following command locks out a user account that is associated with an alert:
<command>
<name>disable-account</name>
<executable>disable-account.sh</executable>
<expect>user</expect>
<timeout_allowed>yes</timeout_allowed>
</command> You can later reference this <command> block in an <active-response> block, like this:
<active-response>
<command>disable-account</command>
<location>local</location>
<level>10</level>
<rules_id>402</rules_id>
<timeout>900</timeout>
</active-response>This response will cause any accounts that trigger the 'User missed the
password more than one time' alert shown earlier to be locked out for 15 minutes. One thing to note in this example is the <location> tag. This tag lets you specify where you’d like the response to be triggered. Using local will cause the response to be triggered on the machine that generated the alert, whereas analysis-server will cause it to be triggered on the server. Alternatively, you can use all or defined-agent to cause the response to be triggered on all of the systems or a specific agent, respectively. In the latter case you’ll also need to use the <agent_id> tag to specify the agent on which to trigger the response.
When a response is triggered, an entry will appear in /var/ossec/active-response/ossec-hids-responses.log. For instance, when the response shown above is triggered, something similar to this will appear:
Thu Jun 2 04:01:31 MDT 2006 ../active-response/bin/disable-account.sh add andrew
As you can see, OSSEC’s active response feature can be very powerful. You can even write your own active response scripts, which gives you a literally unlimited number of possibilities in automatically reacting to attacks. This and many other features of OSSEC can be replicated by combining other tools. However, OSSEC provides them in an integrated manner and saves you the time spent gluing them together with your favorite scripting language—time that you can spend dealing with actual security issues.