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 http://www.ossec.net/files/ossec-hids-2.7.tar.gz 
# wget http://www.ossec.net/files/ossec-hids-2.7-checksum.txt
or download it from OSSEC Download 


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


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
Information
/var/ossec/bin
Contains all necessary binaries used by OSSEC HIDS
/var/ossec/etc
Contains all necessary configuration files
/var/ossec/etc/ossec.conf
The main configuration file
/var/ossec/logs
Contains all necessary logs
/var/ossec/logs/ossec.log
It is main log files for OSSEC
/var/ossec/logs/alerts/alerta.log
High level alert information are stored
/var/ossec/rules
Contains all required and necessary rules
/var/ossec/stats
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
Information
<active-response>
Extra configuration options regarding active response
<alerts>
Options for email and log alerts
<command>
Configuration options regarding active response
<database_output>
Database output information
<email_alerts>
Options for Granular email alerts
<global>
General configuration options for local installation
<localfile>
Options for Monitored log files
<rootcheck>
Options for detection of rootkit and policy monitoring
<rules>
Shows rules that are included
<syscheck>
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. 



<global>
            <email_to>example@gmail.com</email_to>
            <email_to>example@localhost.com</email_to>
            <email_maxperhour>30</email_maxperhour>
        </global>
 
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. 


            <log_alert_level>1</log_alert_level>
            <email_alert_level>7</email_alert_level>

Level
Description
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.

Rules
Description
sshd_rules.xml
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
telnetd_rules.xml
Connection refused by TCP Wrappers
Remote host connection established
Reverse lookup error
Multiple connection attempt
Possible scan attempt
syslog_rules.xml
File missing
Non standard syslog message
Syslog exited
ftpd_rules.xml
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
apache_rules.xml
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
mysql_rules.xml
Database authentication
Database shutdown message
Database error
Database fatal error
Multiple database error
ossec_rules.xml
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>

Parameters
Description
check_sum
Checks the integrity of file using MD5/SHA1 checksum
check_size
Monitors changes in any files and directories
check_owner
Monitors changes for ownership
check_group
Monitors changes for group ownership
check_perm
Monitors changes for permission within files and directories
check_all
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###
<ossec_config>
  <global>
    <email_notification>yes</email_notification>
    <email_to>example@gmail.com</email_to>
    <smtp_server>127.0.0.1</smtp_server>
    <email_from>ossecm@dragon.com</email_from>
  </global>

<rules>
    <include>rules_config.xml</include>
    <include>pam_rules.xml</include>
    <include>sshd_rules.xml</include>
    <include>telnetd_rules.xml</include>
    <include>syslog_rules.xml</include>
</rules> 

  <syscheck>
    <!-- Frequency that syscheck is executed - default to every 22 hours -->
    <frequency>300</frequency>
   
    <!-- 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 -->
    <ignore>/etc/mtab</ignore>
    <ignore>/etc/mnttab</ignore>
    <ignore>/etc/hosts.deny</ignore>

  <rootcheck>
    <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>
    <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>
    <system_audit>/var/ossec/etc/shared/system_audit_rcl.txt</system_audit>
    <system_audit>/var/ossec/etc/shared/cis_debian_linux_rcl.txt</system_audit>
    <system_audit>/var/ossec/etc/shared/cis_rhel_linux_rcl.txt</system_audit>
    <system_audit>/var/ossec/etc/shared/cis_rhel5_linux_rcl.txt</system_audit>
  </rootcheck>

  <alerts>
    <log_alert_level>2</log_alert_level>
    <email_alert_level>6</email_alert_level>
  </alerts>

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/dpkg.log</location>
  </localfile>
</ossec_config>


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
Description
ossec-analysisd
It is responsible for analysis of logs, syscheck, rootcheck files
ossec-execd
It is responsible for executing active response.
ossec-maild
It is used for sending alerts notification via email
ossec-monitord
It is used to monitor agent (useful only if u have sever/agent)
ossec-logcollector
Monitor log files.
ossec-syscheckd
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

Enjoy

10 comments:

  1. Thank You & have a lucky day!

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

    ReplyDelete
    Replies
    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.

      Cheers,

      Delete
    2. Enter in local_rules else upgrades will overwrite.

      Mileage varies...

      Delete
  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!

    ReplyDelete
    Replies
    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" ?

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

      <\alert_new_files>yes<\/alert_new_files>

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

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

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

    ReplyDelete
  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

    ReplyDelete