Sagan on laptops and workstations.....(Sagan's main site)

Sagan has been designed to deal with large volumes of logs while being as memory and CPU efficent as possible. For large scale deployment, these are "good things". However, in some cases, you might have a desire to run Sagan on a smaller scale. For example, a laptop or workstation. Considering Sagan attempts to be CPU/memory efficent, it will actually work quite well on smaller scales. For example; I tend to go to many security conferences a year. When I do, I typically carry around my laptop or netbook. While I'm at these 'security events', I like to be notified when something 'fishy' is being attempted with or against my laptop. I'd like to be 'notified' when a stranger might be attempting to SSH into my laptop. It would also be nice to be notified when my device might be having some sort of hardware failure. Sagan already has the infrastructure to detect these type of events. The problem is getting these Sagan alerts/events to the end user. 'tail -f /var/log/sagan/alert' really isn't a good answer, as it requires the end user to constantly 'monitor' a file. That's not a viable solution. Since we're dealing with workstations and laptops, we're more than likely using XWindows (X11/Xorg/etc). With this in mind, it'd be preferred that when a Sagan event/alert happens, a 'popup' notification is generated. This is actually pretty simple to do using Sagan's "external output" plug in, and this is what I'll be covering.

Sagan's "external output:" plug-in....

Sagan supports various "output plug ins". These are typically used to pass data in various ways. For example, to pass Sagan alerts to a Snort or Prelude MySQL or PostgreSQL database. Another example might be to have Sagan send out an e-mail when an event in triggered. For a simple laptop or workstation setup, this is probably over kill. Within your corporate environment to monitor and correlate log events with your IDS/IPS events is exteremly powerful. On a laptop, we probably just want to be notified when an event takes place. That's it. No need for SQL, SMTP, etc.. That's where the "external output:" Sagan plug in comes into play.

The idea is that Sagan will call "some other program" via a thread. This way you can write, in any language (C, Perl, Python, Ruby, etc) a way to deal with the data you see fit. Sagan does the detection of the alerts/events, and then can call "your" program in which you can do whatever you please with the data. Pretty simple, eh? Data from Sagan to your program is passed via 'standard input' (stdin). So, when your program is called, it'll read in the data supplied by Sagan from "stdin". Technically, Sagan can supply the data to your program in two formats. The standard 'alert' format, which is similar to Snort's output or 'parseable'. Parseable allows you to extract information about the event for your program to use. In this simple example, we won't be extracting data from the alert. With this in mind, we'll simply be using the 'alert' format. This keeps the information in that 'snort like' format, and makes it easy for the end user to 'view' what happened.

Compiling and settting up Sagan....

Much of the compiling and configuring of Sagan is coverted in the SaganHOWTO, so I won't be going over the details of that in this document. Since we'll be building Sagan for a small scale use, there are some key things to consider. For example, my laptop will not be sending out e-mails or attempting to correlate information with a SQL database. There isn't much of a need to enable these features which will simply add to the footprint size of Sagan. With that in mind, I'm going to build Sagan with 'barebones' support. That is, that majority of output plugins will be disabled. To do this, you'll want to run the "configure" routine with options you don't need disabled. Like this:

./configure --disable-mysql --disable-postgresql --disable-prelude --disable-esmtp

By default, Sagan always has the 'external output' plug in enabled. As a matter of fact, that's built into Sagan an is not possible to disable. Once the 'configure' script is complete, run 'make && make install' as 'root' to install on your system. You'll need to tweak a few configuration options in the /usr/local/etc/sagan.conf. That information is also covered in the SaganHOWTO.

sagan-gtk and sagan-notify

In the Sagan version 0.1.8 SVN and above, I've included some very basic external programs for Sagan to generate 'popup' notifications with. They are sagan-gtk.c and sagan-notify.c. By looking at the source code for both examples, you'll notice they are very simply X11 based programs. They simple take stanadard input (from Sagan) and generate some sort of 'popup' window based on that information. These example programs are located in the Sagan source tree under the "extra" directory. Both examples have a Makefile. If you have the proper libraries installed (libglib, libgtk and libnotify), then compiling should be straight forward. Simply enter the directory and type "make". Once the compile is complete, simply copy the binary to your desired location. For this document, I'll be placing the binaries in the /usr/local/bin/sagan-gtk and /usr/local/bin/sagan-notify.

Sagan 'external output' configuration:

Once the Sagan configuration file is setup the way you want (see, the SaganHOWTO), you'll need to 'tell' Sagan to use an external output format of 'sagan-gtk' or 'sagan-notify'. This is pretty straight forward. Simply add the following to your configuration:

max_ext_threads 50
output external: /usr/local/bin/sagan-gtk alert

You might find that you prefer the 'sagan-notify type of 'popup' better. If that's the case, simply replace 'sagan-gtk' with 'sagan-notify'. The "max_ext_threads" tells Sagan how many maxium external threads to spawn at any given time. In this case, this means we never want more than 50 'popup' windows at a time! You'll probably want to tweak this to your own liking.

Starting up Sagan

We'll be starting Sagan as normal, but we need to do a bit of setup first. Since Sagan will be sending output in the form of XWindows 'popup' notifications, Sagan will need to have access to the X display. This is normally "0:0.0" and can be checked by typing 'echo $DISPLAY' at the command prompt. Since Sagan operates under it's own username (typically, the 'sagan' username), we'll need to give that user access to the XWindows display. To do this, open a Xterm (or whatever) and issue the following command:

$ xhost +local:sagan 

This allows the username 'sagan' to update and add events to your display. Without it, Sagan will still function, but fail to generate the 'popups' we're going for. If running this on a laptop or workstation, you'll want to consider adding it to your startup or possibly your .xsessions file. This way, upon reboot, it'll give the user Sagan access to your display.

To start Sagan, simply type (as 'root'):

# /usr/local/bin/sagan

Once your satisfied with Sagan starting up, you'll probably want to add it to your startup routine with a '--daemon' flag. This way, Sagan will start up in the background.

The final out come....

I've taken some screen shots of the final results. The first ones are of sagan-gtk being used.

Sagan GTK #1

Sagan GTK #2

These are of the sagan-notify being used. This is just the top right hand corner of my display. While I like libnotify, it typically mangles the 'alert' output to much for my own taste. Also, it displays one alert at a time.

Sagan notify #1

Sagan notify #2

Sagan notify #3

Why Sagan doesn't use GTK directly...

My orignal idea was to write a GTK based Sagan plug in. This way, Sagan could directly write to a X11 based display. However, this ends up being problematic and I switched to using the Sagan external output function. There's two primary reasons. One, I don't feel that the X11/GTK overhead should be directly in the source code base of Sagan. The second and probably most important reason Sagan doesn't have built in native X11/GTK support is that when a $DISPLAY isn't 'reachable', GTK tends to halt all functionality of the software. That is, if Sagan had the GTK funtionality built in, and it couldn't communicate with the X11 server, Sagan itself would stop functioning due to the X11/GTK error! For the function that Sagan provides, this is simply unacceptable! With the GTK/X11/Notify calls being in an "external" thread, the external thread will be 'killed' (exit) rather than the Sagan.

Other GTK/Notify/X11 uses....

Another nifty thing that comes out of this is being able to redirect headless systems 'popups' to your X11 display. For example, let say you have a 'home firewall' and you'd like to be notified anytime someone attempts to log into the system. The home firewall is at 192.168.0.1. On your workstation, you'd simply run:

$ xhost +192.168.0.1:sagan  

On the 'home firewall', before Sagan is executed, you'd set your $DISPLAY variable back to your workstation. For example, if your workstation is at 192.168.0.100, before starting up Sagan, you'd run:

# export DISPLAY="192.168.0.100:0.0"
# /usr/local/bin/sagan --daemonize

Now, when an event happens on your firewall, a GTK/Notify is sent to your X11 display smile

-- ChampClark - 2010-11-30

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