Month: December 2006

bookmark_borderIs Open Source Rootkit Detection Behind The Curve?

Posted on by Daniel Cid

The guys from matasano posted in their blog an entry about the current state of open source rootkit detection. While I agree that we are way behind the latest rootkit technologies (specially for windows), if you look at the public known unix-based rootkits, we are not that bad. Most of them only use basic system call redirections and can be detected by ossec/rootcheck. It looks like very little has been done focusing on unix-based systems lately…

Below is my reply in their blog:

I think the tool you mentioned that does the connect/bind+kill stuff is rootcheck (now part of ossec). It basically does four things to detect anomalies in the system (that may indicate the presence of a rootkit):

1-Attempts to bind to every TCP and UDP port. If it can’t bind the port (port is used), we check if netstat is reporting it.

2-Attempt to kill(0), getsid and getpgid every process (from 1 to maxpid). We compare the output of these three system calls with ps and proc (where available).

3-Compare the output of stat st_nlink with the count from readdir.

4-Attempt to read every file in the system and compares the size read with the one from stat.

I know these techniques can be evaded, but they are sucessfull against most of the public known unix-based rootkits (99% still based on system call redirection). Rootcheck/ossec also has the rootkits signatures stuff…

In addition to that, OSSEC also does file integrity checking and log analysis to complete its HIDS tasks..

In my opinion, the best way to protect against rootkits is by having an updated and “as secure as possible” system. However, as soon as an attacker finds a way in and gets root (kernel) access, the battle becomes much harder… Early warning systems to detect the attack (not the rootkit) may be the only thing left (anything from log analysis to integrity checking and NIDS).

bookmark_borderCorrelating multiple snort IDS with OSSEC

Posted on by Daniel Cid

I was asked recently what is the best way to correlate multiple snort events with OSSEC. The idea would be to generate an ossec alert (by e-mail and possible an active response) if a specific number of snort rules are fired from the same source IP address (in any order)..

The easiest way to solve this is by creating a local ossec rule (inside local_rules.xml) to match if any of the desired snort signatures are fired:

<rule id=”100015″ level=”6″>
<if_sid>20101</if_sid>
<decoded_as>snort</decoded_as>
<id>1:xx|1:yy|1:zz</id>
<description>Watched snort ids</description>
</rule>

Note that 1:xx, 1:yy are the snort ids that you are interested to watch. We use the <if_sid> to make sure that this rule is only tested if it is an IDS event (see rule 20101).

Now, we create another ossec rule with a higher severity that will only be fired if the above rule (100015) is generated at least 4 times from the same source ip within 3 minutes (180 seconds):

<rule id=”100016″ frequency=”4″ level=”10″ timeframe=”180″>
<if_matched_sid>100015</if_matched_sid>
<same_source_ip />
<description>Multiple snort alerts with the watched ids</description>
</rule>

This idea can be extended to any other log format that you want to monitor. The following entry in the ossec wiki has some information too: Ignoring rules.

bookmark_borderFun with logs (#2)

Posted on by Daniel Cid

Every log analyst is tired of having to decipher weird/useless log entries. However, we are not alone… Even “normal” people have to deal with strange logs too. To prove that, the dailywtf web site is constantly adding entries to their funny pop-up potpourri “section” with some of the strangest messages that users have to deal on a daily basis:

Pop-up Potpourri: The -693926 Days of Christmas
Pop-up Potpourri: Mayday Edition
Pop-up Potpourri: You Can Quote Me On That
Pop-up Potpourri: It’s Getting a Little NaN Outside

I have also posted some funny log entries in the past and the log analysis site has some too. Check them out and enjoy…

bookmark_borderstdarg misuse (C tip #1)

Posted on by Daniel Cid

I received some reports in the past about OSSEC segfaulting during startup on 64 bits systems. However, I was never able to reproduce this problem until last week.. I was happily enjoying my “vacation” and playing with ossec on an Ubuntu 64 when I finally got the ugly “2006/12/16 15:26:21 Segmentation fault” during startup. A smile came in my face… I would be able to debug it now 🙂 . After some troubleshooting I finally noticed that I was misusing the stdarg functions. I was never able to reproduce this issue before, because it only happens when there is a configuration problem and ossec tries to print the error message to the log file and to stderr (by default it only writes to the log file).

Basically, what was happening is that I was calling va_start, followed by multiple vfprintf calls. I don’t know exactly why it works on 32 bits systems and not on 64 bits (it should fail everywhere), but the easiest solution was to duplicate the va_list using va_copy. So, just for the record, never do:

va_start(args, msg);
vfprintf(stderr, msg, args);
vfprintf(fp, msg, args);
va_end(args);

If you need to print a formatted string multiple times, just do a vsnprintf, followed by fprintf’s or use va_copy to duplicate the va_list:

va_start(args, msg);
va_copy(args2, args);
vfprintf(stderr, msg, args);
vfprintf(fp, msg, args);
va_end(args);

It may sound like an obvious advice, but it may be useful to someone…

bookmark_borderOSSEC snapshot available (alpha 2).

Posted on by Daniel Cid

We have a new snapshot available for testing. It includes the following new features (in addition of multiple bug fixes):Rules for Symantec AV.More information to the active response scripts and changed them to log to the logs directorySupport for glob formated files in the logcollector listRules for Windows Routing and Remote Access logs

In addition of these features, it also has the ones reported at http://www.ossec.net/dcid/?p=19.

Download it from http://www.ossec.net/files/snapshots/ and always make sure to get the latest file available.

**Testing the snapshots is one of the best ways to help with ossec development!.