How is Sagan different than other log analizers?

This questions seems to come up quite a bit. This short document will hopefully shed some light on the differences between Sagan and this miriad of other log based analyzers.

- Log parser or "real time"

Sagan is completely "real time". That is, as the logs are received, they are analyzed against the Sagan rule set. Sagan does not parse the logs via a "tail" like function and an offset. As the logs are received, they are handed to Sagan. The only delay is the time it takes for Sagan to analyze the incoming data. This can be measured in milliseconds.

- Logging formats.

Sagan is capable of logging output to several formats. When we say "output", we typcially mean alerts that have been triggered by Sagan rule sets. The only exception to this rule is the Logzilla output format, which can log only "alert" events or all events. Sagan can log to Snort database, which means you can corralate log events (syslog/snmp/etc) with your Intrusion Detection/Preventions system (IDS/IPS) data! Sagan can log to a Logzilla format for archival log purposes as well. If you find that Sagan doesn't log to a format that you desire, it's simple to write a output plugin via the "external program:" call. This means that when a Sagan alert is trigged (a 'bad thing' is happening), Sagan will execute your program with the data of the event triggered. Sagan hands this data to your program via standard input (stdin), which means you can write your custom output format in any language you want.

- Dealing with IP addresses.

One problem with logging is that the TCP/IP addresses presented are of little use to an administrator without further intervention (digging into the logs). This is very useful for the Snort output plugin (sagan-snort.c). Consider this example; let's say an attacker is attempting to "brute" for a machine in your network. That machine is "10.0.0.1". Log messages are sent from that server to your centerlized logging server, which we'll say is 10.0.0.100. For this example, we'll say the attacker is coming from 192.168.0.1.

When the attacker attacks 10.0.0.1, a log message will be sent in real time, to 10.0.0.100. The typical format of the log message will be from the source of 10.0.0.1 to 10.0.0.100, but this doesn't help the network administrator trying to mitigate the attack without having to 'dig' into the log message. This is also terrible for IDS/IPS corralation. The reason is, from a log management stand point, the log message will show that "10.0.0.1" is being attacked (the source of the log message) and the target of the log message will be 10.0.0.100. Unless the network administrator 'digs' into the log message, it won't show that 192.168.0.1 is the source of the attacker.

Sagan will attempt to 'parse' the message to log the event with the correct information. Sagan will reformat the message, for IDS/IPS corralation, as then attack is targetting 10.0.0.1 with a source of the attacker, 192.168.0.1. These leads to better correlation with IDS/IPS events without having to 'dig' into the log message.

- Other correlation points.

In some cases, Sagan will not only corralate by the source and destination IP address, but the TCP/IP source and target port as well. This makes correlation with IDS/IPS more accurate. Depending on the rule that's triggered, it'll also attempt to correlate via the Snort 'classification'. So if Snort see's an attack as a 'attempted-recon', Sagan will classify it the same way. With this data, we can corralate via:

1. The rule triggered with both Snort and Sagan

2. The source/destination IP address

3. The destination port

4. The source port, in some cases.

5 The classification of the rule

6 The time of the Sagan and Snort event, which should be at the same time.

- Rule sets

Sagan uses a Snort like syntax for rules. This has several advantages. For one, if you're already a Snort user, then understanding the Sagan rule set format is simple. This also makes Sagan compatible with Snort rule set management tools, like Oinkmaster and Pulledpork. Just like Snort, Sagan is capable of doing pattern match via PCRE (regular expressions) or "content:" type (simple string matching). Sagan can also do thresholding of alerts, so administrators don't get bombarded with events. Many of the applicable Snort 'bells and whistles' are avaliable in Sagan.

- No I/O Blocking.

Sagan is multi-threaded. This means that Sagan will not stop processing events when dealing with output. For example, if you're SQL datase is operating a bit slow, this won't slow Sagan down. Sagan will simply spawn off a thread to deal with the I/O (SQL insert, for example) and keep processing. This means Sagan can process log events fast and efficent. This also means that Sagan can take advantage of multiple processor platforms. Sagan should be consider a very high preformance real time log analyzer.

-- ChampClark - 2010-06-25

Topic revision: r1 - 2010-06-25 - ChampClark
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback