Friday, 12 April 2013

Open Source Security (OSSEC) Installation and Configuration

Greetings, yet again we have different Host-Based Intrusion Detection System following AIDE

The Open Source Security (OSSEC) is HIDS application which is multiplatform and supports centralised monitoring system. It has various rich features and had powerful log analysis engine. It is capable of logging and supporting different protocols, servers and application. It has amazing active response and alert notification to any security violation occurred within OS. The most important thing to understand is its policy which is in XML format, very simple to understand and implement. It has quite intriguing monitoring system which runs itself as daemon process and records any unusual behaviour.

Its doesn't matter which Linux Distro your using either RedHat, Debian, Ubuntu, openSuse, Slackware etc.

# wget 
# wget
or download it from OSSEC Download 

# tar -zxvf ossec-hids-2.7.tar.gz
# cd ossec-hids-2.7
# ./

The interactive installation begins and during this process it prompts for installation type either server or agent or local. However, installation path for OSSEC can be defined but by default it installs in (/var/ossec) directory. It is advised to select default settings and follow accordingly till the end of the installation. Finally, it is complied and installed successfully according to the specification provided.  

Understanding OSSEC

This is the most important and crucial stage of OSSEC, if you understand what OSSEC is, How it works and what are its necessary file then your 50% done with OSSEC.

All the necessary files that are within OSSEC directory are listed below:

Files and Directory
Contains all necessary binaries used by OSSEC HIDS
Contains all necessary configuration files
The main configuration file
Contains all necessary logs
It is main log files for OSSEC
High level alert information are stored
Contains all required and necessary rules
Contains statistical information of logs per second etc.

The “/var/ossec/etc/ossec.conf” is the main configuration file which is based on Extensible Markup Language (XML). All configuration and rules files are based on XML, it is because it easier to understand than normal text files. XML allows easy hierarchical nesting of tags and due to this it is very easy to understand the flow of the configuration file. The configuration option are stored within <ossec_config> </ossec_config> format then within this option there are subelements tags. 

Followings are OSSEC alert notification

Files and Directory
Extra configuration options regarding active response
Options for email and log alerts
Configuration options regarding active response
Database output information
Options for Granular email alerts
General configuration options for local installation
Options for Monitored log files
Options for detection of rootkit and policy monitoring
Shows rules that are included
Options for integrity check

First of all, email notification must be properly configured and it can be either configured manually or the interactive installation will configure it. 

It is very important to understand email alert notification system. Unlike other HIDS application OSSEC has alert severity level from 0 to 15. The 15 is the highest level of alert whereas, 0 is the lowest level alert and mostly it is avoided. By default each and every rules have alert severity level from 1 to 15. Even though OSSEC has alert level from 0 to 15, the email is send only when then alert severity level is above 7 and logs are logged only if it is level 1 alert but it can be customised as required. 


Level 0
Usually ignored, not much of threat.
Level 2
Low priority alert
Level 3
Successful and authorised events.
Level 4
Error within the system detected
Level 5
Errors generated by users
Level 6
Small attacks such as: virus, worms etc
In other words, attacks generated but minimum threat
Level 7

Level 8
Small attack on the system
Level 9
Login attempt via unknown source or invalid source
Level 10
Error generated due to multiple break in attempts
Level 11

Level 12
System kernel level threat, warning or error
Level 13
Buffer overflow attempt, attack warning
Level 14
Multiple attack on the system
Level 15
System compromised, attack successful

OSSEC has introduced to granular email notification which is very intriguing. It has capability of sending alert notification via short message service (SMS) on mobile cellular phones. This is can increase incident response time.

The rules are one of the fundamental configuration parts of OSSEC (ossec.conf). By default all rules are declared within ossec.conf files. These rules are included within the <rules> option and automatically loaded when OSSEC starts. The rules must be kept within <include></include> tag and these rules are located in (/var/ossec/rule) directory. It is possible to customise our own rules and include it in rules option. According to this project few of these rules will be discussed such as: sshd_rules.xml, telnetd_rules.xml, syslog_rules.xml, ftpd_rules.xml, apache_rules.xml, mysql_rules.xml and ossec_rules.xml. It is advised to use all of these rules instead of keeping only the necessary ones. It is unknown to us when a hacker might attack using new attack vectors therefore; using the default rules without altering any would be best suggestion.

Possible attack on SSH server
Possible false login attempts via SSH server
Possible scan or break in attempt
OpenSSH challenge-response exploit
Authentication failure
Possible brute-force attack
SSH CRC-32 Compensation attacks.
SSHD authentication failure
Multiple login attempts
Connection refused by TCP Wrappers
Remote host connection established
Reverse lookup error
Multiple connection attempt
Possible scan attempt
File missing
Non standard syslog message
Syslog exited
FTP connection refused
File created and deleted via FTP
User upload and download file to server
Connection refused by TCP Wrappers
Reverse lookup error
Multiple FTP login attempt
Attempt to login with disabled account
Trying to connect to forbidden file or directory
Apache segmentation fault
Code red attack
Authentication failure
Multiple invalid URI request
Invalid URI
Multiple attacked blocked by mod security
Apache without resource to run
Database authentication
Database shutdown message
Database error
Database fatal error
Multiple database error
OSSEC server started
Host based anomaly detection event (rootcheck)
Integrity checksum changed
Disk space use reached 100%
File deleted
Host information added and changed.
Log file size reduced



The syscheck is a file integrity checker which monitors for possible computer system compromise. It monitors every possible changes occurred within the host environment like other HIDS application. It checks for permission, ownership, sizes and checksum (md5 and sha1).  The desired directories which are required to be checked must be kept within directories (<directories> </directories>) tag.
<directories check _all= “yes”> /etc,/bin,/sbin </directories>
<directories check_owner= “yes”> /var/log </directories>

Checks the integrity of file using MD5/SHA1 checksum
Monitors changes in any files and directories
Monitors changes for ownership
Monitors changes for group ownership
Monitors changes for permission within files and directories
Finally, it monitors everything from check_sum to check_perm

The directories which change frequently can obviously cause false positive. Therefore, we use ignore tag (<ignore> </ignore>) tag.
<ignore> /etc/mtab </ignore>
<ignore> /var/ossec/logs </ignore>
The time limitation can be set to automatically execute and scans the required system. It is done by setting value in frequency (<frequency> </frequency>) tag. By default OSSEC HIDS sets to 79200 seconds or 22 hours. It should be always set in seconds and not in minutes or hours.
<frequency> 3600 </frequency>
The rootcheck tags are dedicated to monitor high level threats like rootkit and possible trojans. There are two types of rootkit detection mechanism: application-level detection and kernel level check. The application-level detection mechanism works by referring to rootkit_files.txt and rootkit_trojan.txt. These two text files can be found in (/var/ossec/etc/shared/) directory. The other kernel level check relies on anomaly detection technology.

###OSSEC configuration###


    <!-- Frequency that syscheck is executed - default to every 22 hours -->
    <!-- Directories to check  (perform all possible verifications) -->
    <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
    <directories check_all="yes">/bin,/sbin</directories>

    <!-- Files/directories to ignore -->




OSSEC Implementation

Lets start OSSEC and it can be started and stop and restarted

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

Using following command it starts various monitoring processes of OSSEC for any potential threats. It can be restarted and as well as stopped if required. Once the OSSEC daemons started, it will automatically run in background and start monitoring. First, it will start initialising database (syscheckd) then start scanning for file integrity. Once it is finished with syscheckd, rootcheck will commence. Rootcheck monitors for potential threats like: rootkit or rootkit trojan by performing application-level and kernel level check.

Monitoring Processes
It is responsible for analysis of logs, syscheck, rootcheck files
It is responsible for executing active response.
It is used for sending alerts notification via email
It is used to monitor agent (useful only if u have sever/agent)
Monitor log files.
Performs file integrity check and initialises database at first scan

Lets see using Hydra Bruteforce Attack

Bruteforce attack on ssh server


 That's it guys, this was quite long, wow finally finished it.

I am no expert but this way you can install configure and implement



  1. Thank You & have a lucky day!

  2. When configure a rule,we add it in ossec server or in ossec local agent?

    1. Bro, basically rules are pre-defined, until unless your creating a new one. If indeed your creating a new rule of your own then its obvious it will go on OSSEC Server.


    2. Enter in local_rules else upgrades will overwrite.

      Mileage varies...

  3. I know this is kind of an old posting... but I am using OSSEC and having a little trouble. I have the server running and the agent running on a test box which is a replica of our production web server. I installed an agent on the test server and configured it to connect with the OSSEC server. Gave it a new key and it connects just fine to the server. Within the agent config on the test server, I modified the config file to watch a folder that has a few text files in it just for testing. I restarted the agent after adding the directory and then the line in the config. After I did this, I changed the name of the test text files within the directory and for some reason I am not receiving any alarms from OSSEC. I know the email are configured properly because I receive emails whenever I make updates or changes to the system. Is there something I am missing? Thanks!

    1. Make your alert settings in server. Works fine for me. I have different agents monitoring and alerting on different directory structures, i.e web servers vs. ftp servers vs app servers vs utility servers.

      Did you set yes on the agent?

      Then in the agent's parameter: realtime="yes" report_changes="yes" ?

    2. That first question did not post properly....Let's try a backslash within the <...


    3. D'oh, nor the second question...another backslash...

      Then in the agents <\directory> parameter......

  4. Hey man! I want to just write 1 decoder parameters, then we can change this parameter to become decoder others how.

  5. Daily I receive "no processor found " string to my email ID from ossec.conf which i configured locally . how to write a rule such a way above string will not come to email ID
    . Please help me in writing a rule in ossec. please give me example to implement