OSSEC HIDS is a Host Instruction Detection System (HIDS) Founded by Daniel, one of our Founders. Most of our installations here run off his version, which is branched and doesn't adopt the latest changes being pushed by the community.
This article will provide some basic orientation information and dive right into the configurations required to ensure website logs are being appropriately logged and how to use OSSEC to manage the integrity of your files and directories.
OSSEC is a daemon that can run on Windows, Linux and most other modern OS'. It lacks a GUI, so assume everything will be done via command line, which is honestly ideal as it makes the entire process so much faster once you have a basic orientation of the platform.
Here are some basic things to know about how OSSEC installs, and where to find information.
| Path | Description |
|---|---|
| /var/ossec/ | Default Installation |
| /var/ossec/bin/ | Contains the OSSEC modules |
| /var/ossec/bin/ | Contains your OSSEC modules |
| /var/ossec/logs/ | It contains logs, but t's not just the logs for the alerts but for the OSSEC install itself. This is important as you'll be using it to troubleshoot when something goes wrong. |
| /var/ossec/etc/ | This will contain your configuration information (e.g., ossec.conf). |
The configuration is typically where folks go wrong, not just with OSSEC. Users will install, but forget that most pieces of software require some form of tuning to ensure it's working as it was intended.
By default, OSSEC will only configure these logs to be monitored:
<location>/var/log/messages</location>
<location>/var/log/secure</location>
<location>/var/log/maillog</location>
<location>/var/log/httpd/access_log</location>
<location>/var/log/httpd/error_log</location>
You need to update the ossec.conf file to include the location of your log files.
You can either update the values in the configuration file, using the path, as shown in the example above (e.g., /path/to/web/log.log) or you can use a nifty little utility shell found in the /bin/ folder: util.sh.
Here is how you the util.sh works. Let's say you have a log located here: /var/log/httpd/somesite.access_log
You can use the util.sh utility like this in your terminal:
# /var/ossec/bin/util.sh addfile /var/log/httpd/somesite.access_log
This utility will add the following entry to your .conf file:
<localfile>
<log_format>apache</log_format>
<location>/var/log/httpd/access_log</location>
</localfile>
You Repeat this as many times as you need, depending on the logs you have. Don't forget to include error logs as well.
If you're not sure what other logs exist, no problem. You can use something like this:
# find / -name *log -type f | grep -v "/var/ossec/"
If you're curious, the grep -v is there to exclude all the references you're including in OSSEC folders. You also have the option to run something like this:
lsof | grep log | grep -v ".so" | egrep -v "ossec|proc|dev"
All we're doing is opening a list of all the open files, but then parsing out the noise like module files and the /proc and /dev directories, as well as OSSEC.
Once you're done, be sure to restart OSSEC:
/var/ossec/bin/ossec-control restart
Now that we're accounting for the logs correctly, let's look at some of the other recommended configurations to ensure that OSSEC is doing what it was designed to do. The most important, in our eyes, is the interigty checking feature.
Integrity checking allows OSSEC to look for changes. Whether they are new files being added, or old files being modified. As you might imagine, this can be huge when you consider how most websites get hacked today and what bad actors are doing to deploy malware and C&C's on existing websites. Integrity checking empowers the administrator to stay ahead of issues as they present themselves. OSSEC allows this, so let's make sure we get this configured correctly.
All changes will occur in this file:
/var/ossec/etc/ossec.conf
You're going to focus in the syscheck section. This section will look something like this:
<!-- Frequency that syscheck is executed - default to every 22 hours -->
<frequency>79200</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>
We like to make a few changes that will notify faster on changes, and will tell OSSEC to notify if an event is triggered.
<!-- Frequency that syscheck is executed - set to every 4 hours -->
<frequency>14400</frequency>
<!-- Directories to check (perform all possible verifications) -->
<directories realtime="yes" check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
<directories realtime="yes" check_all="yes">/bin,/sbin</directories>
<directories realtime="yes" report_changes="yes" restrict=".htaccess|.php|.html|.js">[path to the root of your site]</directories>
<alert_new_files>yes</alert_new_files>
<scan_on_start>no</scan_on_start>
<auto_ignore>no</auto_ignore>
The frequency is in seconds, you can reduce that to whatever value you want. Do realize that depending on how you’re configured running syscheck could kill system resources.
Pay attention to this line here:
<directories realtime="yes" report_changes="yes" restrict=".htaccess|.php|.html|.js">[path to the root of your site]</directories>
We've also set it to notify of any changes and to monitor that directory in real time so that we get notifications. We also use restrict to isolate what to notify on. I don’t want the additional noise of images being added, or text files, things like that. I don’t care about those files because to run them .htaccess would have to be modified and my Linux servers to run and recognize as PHP files.
There is one more change you’ll have to make. Seeing when new files are added is very important to me, which is why we add this line:
<alert_new_files>yes</alert_new_files>
By default, OSSEC will not alert new files (dedicated article to Syscheck and OSSEC), that is intentional because of the amount of noise it can generate. By default it is configured in the following file /var/ossec/rules/ossec_rules.xml. You do not want to edit this file, editing will allow it to be overwritten when you update.
Instead, you want to update this file /var/ossec/rules/local_rules.xml.
Here you will update the original rule with a new rule to alert.
This is what the original rule looks like:
<rule id=”554″ level=”0″>
<category>ossec</category>
<decoded_as>syscheck_new_entry</decoded_as>
<description>File added to the system.</description>
<group>syscheck,</group>
</rule>
This is what the new rule in local_rules.xml will look like:
<rule id=”554″ level=”7″ overwrite=”yes”>
<category>ossec</category>
<decoded_as>syscheck_new_entry</decoded_as>
<match>/var/www/html/[site directory]</match>
<description>File added to the [site] directory.</description>
<group>syscheck</group>
</rule>
This new rule is increasing the level to 7 from 0 which is the alert level required for notifications to work in the ossec.conf file. We're also controlling the noise by specifying which folders to monitor.
With this configuration I will now see only when files are add to my sites directory. This is was the addition here:
<match>/var/www/html/[site directory]</match>
You can immediately see how this can be tailored to your site and associated CMS. For example, if we were managing a WordPress website we might configure directories like /wp-includes and /wp-admin as locations we want to administer as there should never be changes in those directories, with exception to updates. It also so happens to be the location bad actors love to use to hide backdoors.
What is really neat is that once you configure OSSEC you can configure it to send your logs to a log management platform like Trunc for easier visualization and analysis.
Posted in
ossec ossec-configurations
by trunc_team