Monitor Your IDS in Real Time






Monitor Your IDS in Real Time

Use Sguil's advanced GUI to monitor and analyze IDS events in a timely manner.

One thing that's crucial when analyzing IDS events is the ability to correlate all your audit data from various sources, so you can determine the exact trigger for an alert and what actions should be taken. This could involve anything from simply querying a database for similar alerts to viewing TCP stream conversations. One tool to help facilitate this correlation is Sguil (http://sguil.sourceforge.net).

In case you're wondering, Sguil is pronounced "sgweel" (to rhyme with "squeal").


Sguil is a graphical analysis console written in Tcl/Tk that brings together the power of such tools as Ethereal (http://www.ethereal.com), TcpFlow (http://www.circlemud.org/~jelson/software/tcpflow/), and Snort's port scan and TCP stream decoding preprocessors into a single unified application, where it correlates all the data from each of these sources. Sguil uses a client/server model and is made up of three parts: a plug-in for Barnyard, a server (sguild), and a client (sguil.tk). Agents installed on each of your NIDS sensors report back information to the Sguil server. The server takes care of collecting and correlating all the data from the sensor agents and handles information and authentication requests from the GUI clients.

Before you begin using Sguil, you'll need to download the Sguil distribution from the project's web site and unpack it. This creates a directory that reflects the package and its version number (e.g., sguil-0.6.1).

Creating the Database

The first step in setting up Sguil is creating a MySQL database to store its information. You should also create a user that Sguil can use to access the database:

$ mysql -u root -p 
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 546 to server version: 3.23.55

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> CREATE DATABASE SGUIL;
Query OK, 1 row affected (0.00 sec)

mysql> GRANT ALL PRIVILEGES ON SGUIL.* TO sguil IDENTIFIED BY 'sguilpass' \
               WITH GRANT OPTION;  
Query OK, 0 rows affected (0.06 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.06 sec)

mysql>

Now, you'll need to create Sguil's database tables. Locate the create_sguildb.sql file (it should be in the server/sql_scripts subdirectory of the directory that was created when you unpacked the Sguil distribution) and feed it as input to the mysql command, like this:

$ mysql -u root -p SGUIL < create_sguildb.sql
            

Setting Up the Server

sguild requires several Tcl packages in order to run. The first is Tclx (http://tclx.sourceforge.net), which is an extensions library for Tcl. The second is mysqltcl (http://www.xdobry.de/mysqltcl/). Both of these can be installed by running./configure && make, and then becoming root and running make install.

You can verify that the packages were installed correctly by running the following commands:

$ tcl
tcl>package require Tclx
8.3
tcl>package require mysqltcl
3.02
tcl>

If you want to use SSL to encrypt the traffic between the GUI and the server, you will also need to install tcltls (http://sourceforge.net/projects/tls/). To verify that it was installed correctly, run this command:

$ tcl
tcl>package require tls
1.40
tcl>

Now, you'll need to configure sguild. First, create a directory suitable for holding its configuration files (e.g., /etc/sguild):

# mkdir /etc/sguild
            

Then, copy sguild.users, sguild.conf, sguild.queries, sguild.access, and autocat.conf to the directory that you created:

# cd server
# cp autocat.conf sguild.conf sguild.queries \
               sguild.users sguild.access /etc/sguild
            

This assumes that you're in the directory that was created when you unpacked the Sguil distribution. You'll also want to copy the sguild script to somewhere more permanent, such as /usr/local/sbin or something similar.

Now, edit sguild.conf to tell it how to access the database you created. If you used the database commands shown previously to create the database and user for Sguil, set these variables to the following values:

set DBNAME SGUIL
set DBPASS sguilpass
set DBHOST localhost
set DBPORT 3389
set DBUSER sguil

In addition, sguild requires access to the Snort rules used on each sensor so that it can correlate the different pieces of data it receives from the sensors. You can tell sguild where to look for these by setting the RULESDIR variable. For instance, the following line tells sguild to look for rules in /etc/snort/rules:

set RULESDIR /etc/snort/rules

However, sguild needs to find rules for each sensor that it monitors here, so this is really just the base directory for the rules. When looking up rules for a specific host, it looks in a directory corresponding to the hostname within the directory that you specify (e.g., zul's rules will be in /etc/snort/rules/zul).

To set where sguild archives the data it retrieves from sensors, change the LOCAL_LOG_DIR variable to something like the following:

set LOCAL_LOG_DIR /var/log/snort/archive

You'll also need to install tcpflow (http://www.circlemud.org/~jelson/software/tcpflow/) and p0f (http://www.stearns.org/p0f/) on the host on which you decide to run sguild. Once you've done that, set their locations so that sguild can find the programs using the TCPFLOW and P0F_PATH variables:

set TCPFLOW "/usr/bin/tcpflow"
set P0F_PATH "/usr/sbin/p0f"

If you want to use SSL to encrypt sguild's traffic (which you should), you'll now need to create an SSL certificate/key pair [Hack #69]. After you've done that, move them to /etc/sguild/certs and make sure they're named sguild.key and sguild.pem.

Next, you'll need to add users for accessing sguild from the Sguil GUI:

# sguild -adduser andrew
Please enter a passwd for andrew: 
Retype passwd: 
User 'andrew' added successfully

You can test out the server at this point by connecting to it with the GUI client. All you need to do is edit the sguil.conf file and change the SERVERHOST variable to point to the machine on which sguild is installed. In addition, if you want to use SSL, you'll need to change the following variables to values similar to these:

set OPENSSL 1
set TLS_PATH /usr/lib/tls1.4/libtls1.4.so

Now, test out the client and server by running sguil.tk. After a moment, you should see a login window, as shown in Figure.

The Sguil login dialog


Enter the information that you used when you created the user and click OK. You should then see the dialog shown in Figure.

Sguil's no available sensors dialog


Since you won't have any sensors to monitor yet, click Exit.

Installing a Sensor

Setting up a sensor involves installing a patched version of Snort that uses modified versions of the portscan and stream4 preprocessors. You'll also need to patch Barnyard to use Sguil's special output plug-in. Sguil's sensor agent script will then collect data from Snort and Barnyard and forward it to sguild.

Patching Snort

To set up a Sguil sensor, you'll need to patch your Snort source code. You can find the patches you need in the sensor/snort_mods/2_1 subdirectory of the Sguil source distribution. Now, change to the directory that contains the Snort source code, go to the src/preprocessors subdirectory, and patch spp_portscan.c and spp_stream4.c:

$ cd ~/snort-2.4.4/src/preprocessors
$ patch spp_portscan.c < \
                  ~/sguil-0.6.1/sensor/snort_mods/2_1/spp_portscan_sguil.patch 
patching file spp_portscan.c
Hunk #4 succeeded at 1252 (offset 2 lines).
Hunk #6 succeeded at 1285 (offset 2 lines).
Hunk #8 succeeded at 1416 (offset 2 lines).
$ patch spp_stream4.c < \
                  ~/sguil-0.6.1/sensor/snort_mods/2_1/spp_stream4_sguil.patch 
patching file spp_stream4.c
Hunk #1 succeeded at 72 with fuzz 1 (offset 39 lines).
Hunk #3 succeeded at 197 (offset 47 lines).
Hunk #4 succeeded at 254 with fuzz 2 (offset 32 lines).
Hunk #5 succeeded at 300 (offset -12 lines).
Hunk #6 succeeded at 421 (offset 46 lines).
Hunk #7 succeeded at 419 with fuzz 2 (offset -8 lines).
Hunk #8 succeeded at 1069 with fuzz 1 (offset 82 lines).
Hunk #9 succeeded at 1117 (offset 14 lines).
Hunk #10 succeeded at 3609 (offset 296 lines).
Hunk #11 succeeded at 3361 (offset 14 lines).
Hunk #12 succeeded at 4002 (offset 327 lines).

Compile Snort [Hack #106] as you normally would. After you've done that, edit your snort.conf and enable the portscan and stream4 preprocessors:

preprocessor portscan: $HOME_NET 4 3 /var/log/snort/portscans gw-ext0
preprocessor stream4: detect_scans, disable_evasion_alerts, keepstats db \ 
  /var/log/snort/ssn_logs

The first line enables the portscan preprocessor and tells it to trigger a portscan alert if connections to four different ports are received from the same host within a three-second interval. Next, it specifies that the portscan preprocessor will keep its logs in /var/log/snort/portscans. The last field on the line is the name of the sensor. The second line enables the stream4 preprocessor, directs it to detect stealth port scans, and tells it not to alert on overlapping TCP datagrams. It also tells the stream4 preprocessor to keep its logs in /var/log/snort/ssn_logs.

You'll also need to set up Snort to use its unified output format, so that you can use Barnyard to handle logging of Snort's alert and log events:

output alert_unified: filename snort.alert, limit 128
output log_unified: filename snort.log, limit 128

Next, create a crontab entry for the log_packets.sh script that comes with Sguil. This script starts an instance of Snort solely to log packets. This crontab line will have the script restart the Snort logging instance every hour:

00 0-23/1 * * * /usr/local/bin/log_packets.sh restart

Edit the variables at the beginning of the script, changing them to suit your needs. These variables tell the script where to find the Snort binary (SNORT_PATH), where to have Snort log packets to (LOG_DIR), which interface to sniff on (INTERFACE), and which command-line options to use (OPTIONS).

Pay special attention to the OPTIONS variable, where you can tell Snort what user and group to run as; the default won't work unless you've created a sguil user and group. In addition, you can specify what traffic to not log by setting the FILTER variable to a BPF (i.e., tcpdump-style) filter. You should also configure the sensor's name by setting the HOSTNAME variable.

Patching Barnyard

Next, compile and install Barnyard [Hack #116]. You'll need to patch it, which you can do by running these commands:

$ cd ~/barnyard-0.2.0
$ cp ~/sguil-0.6.1/sensor/barnyard_mods/configure.in .
$ ./autojunk.sh
$ cd src/output-plugins/
$ cp ~/sguil-0.6.1/sensor/barnyard_mods/op_* .
$ patch op_plugbase.c < op_plugbase.c.patch 
               

After you've done that, run the configure script with the --enable-tcl option in addition to any other options that you want to use. Then, run make from the current directory; when that completes, change to the top-level directory of the source distribution and run make install. To configure Barnyard to use the Sguil output plug-in, add this line to your barnyard.conf file:

output sguil

Now, you can start Barnyard as you would normally.

Finishing Up

Finally, you'll need to set up Sguil's sensor agent script, sensor_agent.tcl, which you'll find in the sensor directory of the source distribution. Before running the script, you'll need to edit several variables in its configuration file, sensor_agent.conf, to fit your situation. For example:

set SERVER_HOST localhost
set SERVER_PORT 7736
set HOSTNAME gw-ext0
set LOGDIR /var/log/snort

Now that everything's set up, create a user to run sguild under and start it like this:

$ sguild -O /usr/lib/tls1.4/libtls1.4.so
            

Make sure that the argument to -O points to the location of libtls on your system, or, if you're not using SSL, omit the -O /usr/lib/tls1.4/libtls1.4.so portion of the command.

Now, start the sensor agent by running a command like the following:

$ sensor_agent.tcl -o 
               -O /usr/lib/tls1.4/libtls1.4.so
            

As with the daemon, omit the command-line options if you don't want to use SSL encryption. However, using it is recommended.

Getting Sguil running isn't trivial, but it is well worth the effort. Once it's in place, Sguil will provide you with a very good overview of precisely what is happening on your network. Sguil presents data from a bunch of sources simultaneously, giving you a good view of the big picture that is sometimes impossible to see when simply looking at your NIDS logs.



 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows