Sunday, February 21, 2010

Introduction to OSSEC - Server/Client and OSSEC WUI

In this episode we'll be reviewing the OSSEC Host Intrusion Detection System (HIDS). We will cover the basic steps to installing and configuring both the server and client applications. Additionally, we'll be covering installing and configuring the OSSEC Web User Interface (WUI). We will not be covering how to integrate OSSEC into the BASE management console. That will be addressed in another blog post, to be released shortly.

OSSEC, for those of you who aren't aware of what it is exactly, is a software based system that monitors the host operating system. Like traditional integrity check based systems (tripwire, aide, osiris), ossec performs file and user/group monitoring. One of the major differences between OSSEC and other traditional systems, is that OSSEC can perform the monitoring in real time on designated files and directories. In addition to the file monitoring capabilities, OSSEC has the ability to monitor the registry on Windows systems for alteration to registry keys.

OSSEC also monitors log files in real time, this functionality is typically referred to as a Log Based Intrusion Detection (LIDS) system. The LIDS portion of the application is enabled by default as part of the basic server and client installation. OSSEC exports the client system logs to the central OSSEC server via a secure channel. The server OSSEC then analyzes all entries for questionable entries or known designated "bad" entries. This includes Windows Security, Event and Application logs, IIS logs, database logs, Apache, SQUID, firewalls, routers, switches, snort as well as a slew of others. For a complete list of all supported log files please see the OSSEC list, bearing in mind however that you can use the generic module to inspect log files or create your own to monitor custom log files. In addition to monitoring for known and questionable "bad" traffic, it will also generate alarms for anything it does not understand or underlying operating system errors such as process failures, disk full errors, raid failures to name but a few.

But wait...there's more..

In the typical OSSEC installation, as with most traditional file integrity check based systems, you need to install some type of agent on the client systems. OSSEC has a very useful feature for those systems which may not support a client to be installed. For these you can utilize the agentless configuration for monitoring virtually any type of system, be it a Cisco ASA firewall or an OS/400 system.

The entire OSSEC system is extremely flexible.

In all examples from this point forward, I am basing the installation of both the client and server on the CentOS 5 operating system. The basic setup and design however is generally the same on all *nix based systems. I am also basing the installation on the current version of OSSEC which is v2.3 as of the time I'm writing this. When doing the installation yourself, you may want to refer to the website if you are unable to retrieve the packages using the links I've provided.

Obtain the OSSEC application and the OSSEC WUI

$ wget
$ wget

Untar both the ossec-hids and ossec-wui packages

$ tar zxvf ossec-wui-0.3.tar.gz && tar -zxvf ossec-hids-2.3.tar.gz

Install the OSSEC HIDS application

$ cd ossec-hids-2.3
$ su or sudo ./
$ Select [en] as the default language

Hit -Enter- after the install script displays the host information

1- What kind of installation do you want (server, agent, local or help)?

Enter "server"

2- Setting up the installation environment.

- Choose where to install the OSSEC HIDS [/var/ossec]:

Leave it as the default /var/ossec by selecting [Enter]

3- Configuring the OSSEC HIDS.

3.1- Do you want e-mail notification? (y/n) [y]:

If you want OSSEC to send you emails on alert, select y - if you do not want it to send you emails on alerts select n

If you select yes, you'll be prompted for your email server information.

3.2- Do you want to run the integrity check daemon? (y/n) [y]:

Select y as the default as we want the server and agent processes to perform file integrity checking.

3.3- Do you want to run the rootkit detection engine? (y/n) [y]:

Select y as the default as we want the server and agent processes to check for known malicious software and perform basic checks on our application installations.

3.4- Active response allows you to execute a specific
command based on the events received. For example,
you can block an IP address or disable access for
a specific user.
More information at:

- Do you want to enable active response? (y/n) [y]:

If you want the OSSEC software to actively respond to suspected intrusion, enable this. Otherwise select n for it to operate in a passive monitoring and reporting mode.

3.5- Do you want to enable remote syslog (port 514 udp)? (y/n) [y]:

Enter n here (entering n assumes you already have syslog listening for remote entries - check your syslog conf to be sure), later on in the configuration we'll be specifying the syslog files we want OSSEC to monitor on both the server and client installations.

After entering y or n on the last entry, OSSEC will scan all default log locations for all system log files and automagically begin tailing those files. While OSSEC tails the files, it will be comparing all entries against known malicious or questionable traffic patterns being entered into the logs.

If there are additional logs you want monitored, simply modify the ossec.conf file after the installation has completed. We'll cover this more later.

Once the installation has completed, you'll need to modify the default configuration file to reflect your system configuration and remove some unnecessary lines from the configuration.

If you installed OSSEC to the default location, the configuration file can be found in /var/ossec/etc

To view my sample server configuration template for OSSEC running on CentOS5 or RHEL5, go here

The above configuration will enable the following options:
- file integrity checks to be performed on the server every 14400 seconds
- file integrity checks for all files located in the following location:

The check_all options tells OSSEC to watch all attributes of the file including permission, owner, group etc. There is an additional option to continuously, in real-time, monitor the specific file or directory by using the "realtime" option.


Other optional fields that are recommended to add are as follows:

- alert_new_files: This is not a default option and designates that when new files are created, OSSEC will generate alerts for each new file created. This option should be set to "yes".

- scan_on_start: This option should be disabled. It can be disabled by setting the field to "no". If this option is not disabled, each time OSSEC is restarted on the system, OSSEC will rescan the entire file system.

- auto_ignore: By default OSSEC will auto-ignore files that change often and are not acknowledged. In certain environments, this type of behavior is not acceptable and this should be disabled. Disabling this option is accomplished by setting the field to "no".

Rootkit checks and system audits, I perform every 86400 seconds. This can be tuned to whatever value you are comfortable with. Bear in mind however that the rootkit and system level audit checks can be resource intensive.

Once the server configuration has been completed, start the OSSEC process: /var/ossec/bin/ossec-control start

With the OSSEC server portion operating, we will configure the OSSEC WUI before moving onto installing, configuring and integrating a client into the OSSEC syste,

Installing and Configuring the OSSEC WUI

As root, move, rename and change the owner/group of the ossec-wui-0.3 directory as follows:

# mv ossec-wui-0.3 /var/www/html/ossec && chown -R ossec.ossec /var/www/html/ossec
#cd /var/www/html/ossec

Run the setup script in the ossec directory:

# ./

Afer entering the requested information during the script execution, add the "user" apache runs as to the ossec group

#usermod -G ossec apache

Modify the permission on the tmp/ directory in the ossec directory to allow apache to access the contents of tmp

# chmod 770 /var/www/html/ossec/tmp && chgrp apache /var/www/html/ossec/tmp

Restart Apache

By default, OSSEC will authenticate access to the OSSEC directory using Basic htaccess authentication. If you have BASE installed and want to use MySQL authentication from the BASE system, modify the .htaccess directory to use the following:

AuthName "Access Restricted to Authorized Users Only"
AuthType Basic
AuthMySQLEnable on
AuthMySQLHost localhost
AuthMySQLUser snort
AuthMySQLPassword (yoursnortMySQLpasswordhere)
AuthMySQLDB snort
AuthMySQLUserTable base_users
AuthMySQLNameField usr_login
AuthMySQLPasswordField usr_pwd
AuthMySQLPwEncryption md5
require valid-user

Authenticating users from the BASE MySQL table will allow you to permit access to everyone who has access to the BASE console access to OSSEC, without the need for continuously modifying the .htpasswd file each time you want to add a new user.

The OSSEC WUI configuration is now completed, you should now be able to access it via your web broswer by going to https://ipofserver/ossec

-- Note: If you don't have this running under HTTPS, it would be in your best interest to do so.

At this point, you should have the OSSEC server operating as well as the OSSEC WUI, we will now add our first client to the system.

Installing the client is exactly the same except that instead of installing it as a server, we'll be installing it as an agent.

Installing the OSSEC Client

$ tar -zxvf ossec-hids-2.3.tar.gz
$ cd ossec-hids-2.3

su to root to install the software and modify the configuration

# ./

Select en as the default language and enter agent for the install type.

Once you enter agent, take the default installation location which will be /var/ossec

You will then be asked for the IP address of the OSSEC HIDS Server, enter it and hit enter

3- Configuring the OSSEC HIDS.

3.1- What's the IP Address of the OSSEC HIDS server?:

3.2- Do you want to run the integrity check daemon? (y/n) [y]:

Accept the default of "y" here

3.3- Do you want to run the rootkit detection engine? (y/n) [y]:

Accept the default of "y" here

3.4 - Do you want to enable active response? (y/n) [y]:

Select "n" here, at this point OSSEC will now install the agent application on the system.

As with the server side installation, the ossec configuration file needs to be modified. I have made a template available for *nix based systems available by clicking here

Once you've completed the client side configuration we now need to add the client to the server configuration.

Introducing the Client to the Server

All communications between the client and server are encrypted. If for whatever reason the communication path between the client and server becomes interrupted, the client side will queue messages until the server becomes reachable again. At which time it will export all queued messages to the server.

On the server we first need to add the client system, export the encryption key for the client, then restart the ossec process. This all needs to be performed as root or via sudo, whichever method you typically use.

# cd /var/ossec/bin
# ./manage_agents

Select "A" to add an agent
- enter the name of the agent
- enter the ip of the agent
- accept the default value for the ID

Select "E" to extract the key
- enter the ID of the system

Copy the entire key, if any portion of the key is missing, the client will not be able to connect to the server.

Exit from the manage_agents application and restart OSSEC

# /var/ossec/bin/ossec-control restart

On the client, run the manage_agents application. Unlike the server, you will only have the option to import a key via "I" on the client.

Once you enter the IP and paste in the key, exit from the manage_agents application and start the ossec application:

# /var/ossec/bin/ossec-control start

As long as the agent and the server have a clear communication path, the client will begin its first operating system integrity, audit and rootkit checks as well as beginning to export all system logs designated in the client OSSEC configuration file to the server.

To add more systems, simply repeat the "Installing the OSSEC Client" and "Introducing the Client to the Server" steps.

That's all for now folks...check back soon for "How to Integrate OSSEC into BASE"

No comments:

Post a Comment