What is Sguil?

Sguil (pronounced sgweel) is probably best described as an aggregation system for network security monitoring tools. It ties your IDS alerts into a database of TCP/IP sessions, full content packet logs and other information. When you've identified an alert that needs more investigation, the sguil client provides you with seamless access to the data you need to decide how to handle the situation. In other words, sguil simply ties together the outputs of various security monitoring tools into a single interface, providing you with the most information in the shortest amount of time. Sguil uses a database backend for most of its data, which allows you to perform SQL queries against several different types of security events.

Downloading Sguil

Sguil is hosted at Sourceforge. You can download the latest stable code from the downloads page. The CVS snapshots are usually pretty stable, but may have additional unknown features. If you want to try them, use the following commands to check out a copy of the tree:

Documentation

General Sguil Docs

General Architecture

The Sguil architecture has a few main components (see network and data flow diagrams below):

Server: The Sguil server receives connections from sensors and clients, in addition to connecting to the database.

Database server: The database holds alert and session data that is collected by the sensors. The database is usually on the same system as the Sguil server, but this is not a requirement.

Sensors: The sensors are the systems actually doing the network monitoring and data collection. Sensors perform full packet captures of network traffic in addition to running Snort in alert mode.

Clients: The client is the interface for the analyst to connect to the Sguil server.

On each sensor, full content data is captured by a Snort process running in packet-capture mode. Another Snort process runs as an IDS in alert mode and SANCP collects session data. As alerts are generated, Barnyard processes them prior to passing the alert data to the Sguil sensor agent on the local host. The Sguil sensor agent on 0.6.1 or various agents on 0.7.0 are responsible for communicating with the Sguil server, including sending alert and session (sancp) data.

The Sguil server receives the alert and session data, and then adds them to the database. Database queries from each client are also passed through the Sguil server, which will then pass the query results back to the client. All connections to the database are made with one database user that is configured during installation of Sguil.

Client queries for ASCII transcripts or packet captures are sent through the Sguil server. After going through the packet captures on the sensor to pull out the relevant data, an agent passes a packet capture file back to the server. In the case of transcripts, the Sguil server will convert the packet capture to ASCII prior to forwarding it to the client while data for use with a protocol analyzer is passed as a pcap file.

A brief description of major software components follows, and software components are listed in detail in the Sguil_on_RedHat_HOWTO.

A common Sguil network layout and Sguil 0.6.1 data flow are presented in the accompanying diagrams. However, there are multiple ways to set up Sguil. If monitoring a small network with only one sensor, the server and sensor may be on the same system. Another potential configuration is to have the Sguil server and MySQL database on separate systems.

A common Sguil network layout and Sguil 0.7.0 data flow diagram are presented in the accompanying diagrams. As with Sguil 0.6.1, the Sguil server and MySQL database can be separated to different systems if needed, or the sensor can be on the same system as the server.

Changes from Sguil 0.6.1 to Sguil 0.7.0

The separation of agents in Sguil 0.7.0 makes it easier to add other data sources with their own agents. Two examples of this are the Modsec2sguil agent and OSSEC agent. The separate agents also make it fairly easy to separate different functions to different systems, such as performing packet capture on a separate sensor from session capture or the Snort alerting process.

Separating collection to different systems is facilitated using a NET_GROUP in the agent configuration.

Another change is that 0.7.0 requires encryption between the server and clients, and the server and sensors. This was optional with 0.6.1.

PADS is a new addition to 0.7.0 that provides asset detection and profiling. Information from PADS can be useful to help correlate and determine applicability of events as they relate to specific systems, or to detect unexpected assets and services on the network.