I recently saw some discussion in the OSSEC distribution list of someone having an issue with getting OSSEC syscheck to work right in real-time. It reminded me of a similar issue I had with my own configuration and others I have read about, so I figured I’d write something to shed light on how OSSEC’s syscheck works in real-time. Thanks ofcourse to Dani for the assist.
Syscheck – Integrity Checking Daemon
If you’re familiar with OSSEC, then you know syscheck, if you’re not then this section will get you caught up – I hope.
Syscheck is the integrity checking daemon within OSSEC. It’s purpose is simple, identify and report on changes within the system files. The way it works is simple, when you first install OSSEC it runs an initial syscheck scan, this scan will go through and capture the check sum of every file on the system (every file you have identified in your configuration file – /var/ossec/etc/ossec.conf). Once the baseline is set, syscheck is able to perform change detection by comparing all the checksums on each scan. If it’s not a 1 for 1 match, it reports it as a change. If new files are added, it identifies it as new, and reports it.
Simple, right? Right…
By default when you first install OSSEC your configuration file will look something like this:
<syscheck> <!-- Frequency that syscheck is executed - default set to every 22 hours --> <frequency>79200</frequency> <!-- Directories to check (perform all possible verifications) --> <directories</etc,/usr/bin,/usr/sbin</directories> <directories</bin,/sbin</directories> <!-- Files/directories to ignore --> <ignore>/etc/mtab</ignore> <ignore>/etc/mnttab</ignore> <ignore>/etc/hosts.deny</ignore> <ignore>/etc/mail/statistics</ignore> <ignore>/etc/random-seed</ignore> <ignore>/etc/adjtime</ignore> <ignore>/etc/httpd/logs</ignore> <ignore>/etc/utmpx</ignore> <ignore>/etc/wtmpx</ignore> <ignore>/etc/cups/certs</ignore> <ignore>/etc/dumpdates</ignore> >ignore>/etc/svc/volatile&lgt;/ignore> </syscheck>
There are a couple of things to note here.
First, the frequency option is in seconds and is defaulted to 22 hours (or 79,200 seconds). I configure this to 4 hours (14,400 seconds) in my configurations.
Second, syscheck by default doesn’t scan the entire box, you have to define your directories and you separate using a comma – “,”. Note that you don’t have to monitor al your directories, which is why it’s designed like this.
Third, if you’re going to try to use this on your website directories then you have to add it to your ossec.conf file:
<directories>/var/www/html</directories> ignore does exactly as it implies, it'll skip over a specified directory. If you're using this for websites this is especially helpful if you have a cache folder or an uploads folder, this can get a bit crazy.
Configuring for Real-Time
Now that we know the basics, a very obvious question that comes to mind is how to go about to get the system to report when a new file is added to the system. By default, based on the terminology, you would expect things like “real-time” would be what you’re looking for, but it’s not unfortunately. First, You do want to enable a few things, so within your syscheck section of the ossec.conf configuration file you want to set the following:
<alert_new_files>yes</alert_new_files> local_rules.xml file, usually here /var/ossec/rules/local_rules.xml and add the following:
<rule id="554" level="10" overwrite="yes"> <category>ossec</category> <decoded_as>syscheck_new_entry</decoded_as> <description>File added to the system.</description> <group>syscheck,</group>
What that rule is doing is elevating the existing severity level for rule 554, which is the rule that captures those additions, from 0 to 10 or any severity level which you have set to alert on here:
<alerts> <log_alert_level>1</log_alert_level> <email_alert_level>7</email_alert_level> </alerts>
I could set it to 7 if I like, just depends on how you do that, just set it to a value that will alert you.
Now, you would think you were done here, but you’re not.
Real Time vs Alert On New
The mistake I made was confusing the real_time attribute with the report on new file addition feature. Real time is not synonymous with new file and is not an attribute to new files; this where folks go wrong.
Real-time works great, but it only works against established check sums in the environment. So, think back to what I described above, on install it’ll create a scan on the environment and create a baseline of the files. This is a prerequisite, so it’s not until the next scan, in my example in 4 hours, that I’ll know what is new in the environment. It also leverages the inotify system calls as its detection engine. Although outlined in the documentation, it’s not really called out and most people look right over it.
inotify is a file change notification system—a kernel feature that allows applications to request the monitoring of a set of files against a list of events. When the event occurs, the application is notified.
What this really means is a New File doesn’t fall into this category. Inotify works only if the file exists, so with a New File, it’ll only be reported when the syscheck runs at your interval, for me that is 4 hours. At the 4 hour mark, it should scan and create a new checksum, it should also send you a notification that a new file was added to the system. So to really get a real-time report of new files being add you’d have to set your syscheck to scan every second, and that’s highly impractical.
Once that baseline is created, if you were to go and modify the file, then, and only then, would it report in real-time that there had been a change. This is very important distinction that everyone should be making. So no, it will not report, in real time, that a new file was added, only on the scan will it report a change and only after that initial scan will it report real-time changes. But do realize that to get it in real-time you’ll need to add a few attributes and will need to defined which directories real time applies to.
It should look something like this:
<directories realtime="yes" report_changes="yes">/var/www/html</directories> report_changes attribute, if possible it will not only notify you of the change, but also give you an example of the change. This could be really helpful if you want to quickly understand what happened and decide how to respond. There is also another attribute I like that helps reduce noise, that's the restrict attribute. This allows you to specify which file types you're specifically interested in. For instance, for websites I like to configure it like this:
<directories realtime="yes" report_changes="yes" restrict=".htaccess|.php|.js|.phtml|.html>[path]</directories>
More often than note, these are the target of attacks, .htaccess being the most important as with that they can treat any file as PHP with a few lines of code. For more information on a basic configuration of OSSEC for websites you’ll want to check out my last post – OSSEC for Website Security – Part I.
An IDS for your Website Stack
If you have come to the conclusion that OSSEC is your IDS of choice, and are in need of professional support, please reach out to us, we’d love to chat. You can read more of what and how we use it by checking our Managed Server Security Program (MSSP).