bookmark_borderOSSEC v1.2 BETA1 available

OSSEC v1.2 is soon to be released and we need some help beta testing it. As I always say, trying out our beta releases is a simpler and very effective way of helping the project.

Where can you download it?
v1.2 beta for Unix/Linux
v1.2 beta for Windows

What kind of things do we need to be tested?We need to make sure it compiles fine on all platforms and operating systems. We changed the internals quite a bit and we may have missed something. Try on Solaris, NetBSD, FreeBSD, AIX, HP-UX, any Linux distribution that you have.Make sure your local rules still work and it can parse all your logs.Try the new features, including the log signing and the granular e-mail configuration that I mentioned on previous posts.On Windows, make sure there are no false positives regarding our new NTFS ADS check.

Let us know if you find anything wrong…

bookmark_borderDaily/Chained checksum of ossec alerts

OSSEC v1.2 will come with support for daily/chained checksums enabled by default. Basically, what it means is that at the end of each day, ossec will generate the md5/sha1 sum of the currently logs plus the md5/sha1 sum of the checksum from the logs of the previous day.

To exemplify, at the end of Apr 23, ossec will create the following file:

# pwd
/var/ossec/logs/alerts/2007/Apr
# cat ossec-alerts-23.log.sum
Current checksum:
MD5  (/logs/alerts/2007/Apr/ossec-alerts-23.log) =
7a275b2d07a5aac500c78c7af51de457
SHA1 (/logs/alerts/2007/Apr/ossec-alerts-23.log) =
af560a60bfb9fde5944c4bfc36fedfb16a1956d5

Chained checksum:
MD5  (/logs/alerts/2007/Apr/ossec-alerts-22.log.sum) =
2ab5d8637e9f63493d2f3f3a9b06b17f
SHA1 (/logs/alerts/2007/Apr/ossec-alerts-22.log.sum) =
6b1f3c29abc9e37ddb6b1a53ac83b0fe20830140

If you look at the checksum of Apr 22, it will have its own plus the one from the day 21 (and the same will happen back until the first day that the chain started).

What do we get from that? First, any modification on the old logs will require changing all the next checksums. Second, if you e-mail them to you every day (or post somewhere publicly), you can have a valid case to prove that they were not tampered.

If you want to try this feature, please check a pre-beta version: snapshots

bookmark_borderWiki editing blocked (vandalism)

I decided to block any form of editing to the ossec wiki for reasons of vandalism. If you look at the wiki recent changes page you will see the changes that were made. Most of them were very strange to me, like removing every + (plus) from the pages or removing all the content (without adding any spam link or anything). Anyone seeing similar patterns?

After some log analysis I found that all the changes were made by the same IP address (200.238.102.170) across the last three days…

Sample log:


200.238.102.162 – – [11/Apr/2007:18:00:35 -0300] “GET /wiki/index.php?title=Log_Samples_Lotus_Domino&action=edit HTTP/1.1″ 200 6702 “http://www.ossec.net/wiki/index.php/Log_Samples_Lotus_Domino” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)”

200.238.102.170 – – [11/Apr/2007:17:08:36 -0300] “GET /wiki/index.php?title=Log_Samples_Solaris&action=edit HTTP/1.1″ 200 6667 “http://www.ossec.net/wiki/index.php/Log_Samples_Solaris” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)”

How do you guys handle vandalism/spam on your wikis? Any suggestion? Until I can find a solution to this, send me an e-mail if you need to edit the wiki.

bookmark_borderOSSEC performance (v2)

During the release of ossec v1.0, I posted some performance numbers regarding that version. Even though I know most performance tests do not prove anything per se, I was able to see how many events per second an old PIII box with 512M of ram could handle.

Recently, I finished doing multiple performance improvements to ossec and I decided to re-run this test using the latest available CVS version.

I took the same steps as before, basically sending as many logs as possible to analysisd (main ossec process) and checking /var/ossec/stats/totals to see how many logs it was able to process per second.

Test setup:

I created 5 ossec configurations for logcolletor and initiated one separated daemon for each config. Each process was monitoring one log file. The operating system was OpenBSD 3.9 on an old PIII 700 with 512M of RAM.
# /var/ossec/bin/ossec-logcollector -c /var/ossec/etc/log1.conf
# /var/ossec/bin/ossec-logcollector -c /var/ossec/etc/log2.conf
# /var/ossec/bin/ossec-logcollector -c /var/ossec/etc/log3.conf
# /var/ossec/bin/ossec-logcollector -c /var/ossec/etc/log4.conf
# /var/ossec/bin/ossec-logcollector -c /var/ossec/etc/log5.conf

# tail /var/ossec/logs/ossec.log
2007/01/20 15:14:49 ossec-logcollector(1956): Analyzing file: ‘/data/test-logs/log1′.
2007/01/20 15:14:50 ossec-logcollector(20567): Analyzing file: ‘/data/test-logs/log2′.
..
2007/01/20 15:14:56 ossec-logcollector(32102): Analyzing file: ‘/data/test-logs/log5′.
2007/01/20 15:14:56 ossec-logcollector: Started (pid: 15448).

# cat /var/ossec/etc/log1.conf

<ossec_config>
<localfile>
<log_format>syslog</log_format>
<ocation>/data/test-logs/log1</location>
</localfile>
</ossec_config>

To be fair, I chose 5 different log formats and wrote a simple script to keep filling the logs as faster as possible.

# cd /data/test-logs
# while [ 1 ]; do ./fill-logs.sh; done
# cat fill-logs.sh
cat PIX-sample >> log1 &
cat accesslog-sample >> log2 &
cat authlog-sample >> log3 &
cat messages-sample >> log4
cat squid-sample >> log5

Test results:

To my surprise, my changes made a great improvement to the overall ossec performance. Previously, ossec was able to handle in average 1,238,000 events per hour (or 340 per second).

On the latest CVS version, this number jumped to 2,100,000events per hour (or 600 per second). This is a big jump! Note that I am using real data and that this sample is generating an average of 1,000,000 alerts per hour (rate or 1 alert per 2 events). On a normal environment this value would be much lower.

Summarized stats output from the UI:


Hour  	         Alerts  	Alerts %  	Total  	Total %
Hour 14  	1,046,427  	5.0%   	2,140,978  	5.2%
Hour 15 	1,034,108 	4.9% 	2,142,076 	5.2%
Hour 16 	1,041,571 	5.0% 	2,096,306 	5.1%
Hour 17 	1,016,219 	4.8% 	2,048,642 	5.0%

Performance values per version:

*on a PIII, 512RAM, OpenBSD 3.9

Version 1.0           1,238,000 per hour     340 per second
Version 1.2           2,100,000 per hour     600 per second

If you have some spares systems to execute a similar test, let us know how it goes and we will publish the results.

bookmark_borderOSSEC WUI version 0.2 is available

We are pleased to announce the release of the first non-BETA version of the OSSEC web interface (v0.2). This version contains the following features and bug fixes:

  • Added real time monitoring to the search page.
  • Added support for paginated search results.
  • Added “Log Format” as an option to allow searches based on the log format.
  • Added integrity checking page to allow monitoring of changed files/registry entries.

The full release message is available here.

Download it from here.

Install guide here.

As always, comments are welcome…

bookmark_borderOSSEC Web UI v0.2 beta 1 available

The first beta of the ossec wui v0.2 is available for our beta testers. As I mentioned before, the best way to get involved in the project is by helping us testing our beta releases. If you do so, please let us know how it went.

You can download the beta 1 from here.

You can follow the same steps as mentioned here to install.

New features include paginated search results, real time monitoring of alerts, new integrity checking page and many other stuff (saving details for official release).

Let us know of any bugs or suggestions that you may have.

bookmark_borderOSSEC v1.1 BETA1 available

If you are looking for a way to help the project, here is your chance. We just release the first beta for the 1.1 version and we need beta testers. This version has numerous bug fixes and new features, so a great deal of QA will be required. If you try it out, let us know if it worked or not (and provide the operating system/version that you used).

Partial changelog:Added support for hostnames in the server-ip configuration. Use “server-hostname” to specify it.Added granular e-mail configuration options. Extra email_alerts options can be added based on the severity or event location.Added support for Solaris 10 and OpenBSD su messages.Improved Windows installer to use NSIS Modern UI.Added overwrite attribute to the rules. It allows an entire rule to be overwritten. Example to overwrite rule 1002:

Partial changelog:

  • Added support for hostnames in the server-ip configuration.
  • Use “server-hostname” to specify it.Added granular e-mail configuration options.
  • Extra email_alerts options can be added based on the severity or event location.
  • Added support for Solaris 10 and OpenBSD su messages.
  • Improved Windows installer to use NSIS Modern UI.Added overwrite attribute to the rules. It allows an entire rule to be overwritten. Example to overwrite rule 1002:


<rule id="1002" level="8" overwrite="yes">
<match>Segmentation|XYZ</match>
<description>Rule 1002 overwriten.  </description>
</rule>

You can download the Unix and Windows files from:
http://www.ossec.net/files/snapshots/

Let us know of any question (dcid @ ossec.net).

bookmark_borderLog alerts from OSSEC (NSM 2)

Richard Bejtlich, from taosecurity, posted two interesting blog entries, where he mentions some ossec alerts.

He says that he got some ossec log alerts, but lacked more information regarding what do you with them. I agree with his assessment, where he used Sguil to get more network-based details to see what happened during that time. However, in addition of using a network sensor, he could have setup a log server, where he would be able to do a great deal of analysis with his log data (without ever touching the affected system).

Using firewall logs, for example, he would be able to see all connections during that time from that IP address. Looking at authentication messages from all his systems, he would be able to see if that IP was ever able to connect remotely, or if it ever accessed any other service (like http or his mail server, etc).

What am I trying to say here? Well, as I said before, I just want to point that Network Security Monitoring (NSM) along with log analysis can provide much more visibility than any of this two alone.