Category: Log Analysis and Correlation

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.

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…

At ossec we have a long list of log formats to add support for the next version, and of them is the cisco IOS logs. Since it is such a common device, I decided to start working on that…

One of my surprises when looking at the IOS logs was a new (well, not really new, but I didn’t know about) feature introduced on the version 12.3 that allows full granularity for logging authentication events. So, if you are interested to forward all failed and success login attempts from your IOS to a remote syslog server, you can just enable login logging:

login on-failure log
login on-success log

If you enable that, you will get logs similar to those:

%SEC_LOGIN-5-LOGIN_SUCCESS:Login Success [user:dbc] [Source:1.2.3.4] [localport:22] at 13:51:11 UTC Web Nov 11 2006
%SEC_LOGIN-4-LOGIN_FAILED:Login failed [user:dbc] [Source:1.2.3.4] [localport:22] [Reason:Invalid login] at 13:51:19 UTC Web Nov 11 2006

From now on, whenever you enable syslog on a cisco ios, don’t forget these commands.

If you have ever been involved with log analysis, you probably had the experience to look at a log entry and find it so useless and so weird that your only reaction was to laugh. Today I had this experience multiple times while looking at some Extreme logs (private information removed)…

Aug 11 09:11:19 xx MSM-B HAS TAKEN OVER AS THE MASTER
Aug 11 09:11:19 xx Free Entry Not Available
Aug 11 09:11:19 xx null pif ? exit! 0
Aug 11 09:11:19 xx eaps_runtime.c: Bug!

Check out the explanation for the last one: “This message indicates a software error and should never appear.”.. Priceless. The log analysis web site has some funny entries too.

Anton Chuvakin commented in his blog about a mistake that most analysts make when monitoring their logs: they only care about errors or failures and forget about the sucessful entries. The comment was regarding to web logs, but it applies to all formats.
He also asked about how to separate the interesting (security relevant) sucessful entries to the normal ones (valid access). This was my reply:

I also think that sucessful attempts should be checked and taken in consideration…

For 200 (sucess) return codes, it is very hard to separate the “bad” from the “good”, specially on dynamic web sites. To try to solve this problem, on ossec, we built a list of strings that are most of the time bad on URLs. For example, for sql injections, we use the following combination:

=’|select%20|insert%20|%20from%20|%20where%20|union%20

For cross site scripting, we use:

%3Cscript|%2Fscript|script>|script%3E|SRC=javascript|IMG%20|%20ONLOAD=|INPUT%20

We also have more *patterns for specific attacks, common worms , etc.

Btw, I also think that this analysis must be done on web proxy logs too.
On ossec we use that on our squid rules and we can easily detect
infected internal systems by their http requests…

I just released the document Log analysis for Intrusion Detection at the ossec web site. It shows how some threats can be detected by correlating specific patterns on web logs, proxy logs and authentication logs..”

Log analysis is one of the most overlooked aspects of intrusion detection. Nowadays we see every desktop with an anti-virus, companies with multiple firewalls and even simple end-users buying the latest security related tools. However, who is watching or monitoring all the information these tools generate? Or even worse, who is watching your web server, mail server or authentication logs?”