Sguil: Intrusion Detection and Analysis

Network Security Monitoring

Sguil (pronounced sgwheel) is a Network Security Analysis tool that facilitates the practise of Network Security Monitoring (NSM). Richard Bejtlich, a former Military Intelligence Officer with the US Air Force, now Director of Incident Response at General Electric, introduced the concept in his book, The Tao of Network Security Monitoring.

NSM involves the collection, analysis and escalation of warnings in order to detect and respond to network intrusions. It uses a traditional IDS system – like SNORT – as an alerting mechanism, but also relies on a full spectrum of data types, including IDS events, session data and full packet capture. This additional, supporting, data, helps a security analyst determine whether an event is a false positive, or if the incident response team needs to be informed.

Bejtlich defines NSM as:

the collection, analysis and escalation of indications and warnings to detect and respond to intrusions.

Sguil

Sguil is the de facto reference implementation for NSM and incorporates a number of other products:

• Snort – An Intrusion Prevention / Detection System based on signature matching, protocol inspection and anomaly detection.
• SanCP – the Security Analyst Network Connection Profiler – a statistical tool designed to create connection logs and record network traffic. SanCP records who talks to whom, start and end times, number of bytes and packets transferred.
• Barnyard – an output system for Snort that parses Snort’s ‘unified’ binary file output into a structured database.

These products together form a Sguil sensor, a number of which are deployed around an enterprise network. A central Sguil server and MySQL database aggregate the data feeds from these deployed sensors. Users access the data through a single graphical user interface, accessible by a number of analysts concurrently.

Alerts

The interface presents first-line analysts with real-time alerts from the Snort senors. If the activity is not suspicious, the analyst can choose to ‘expire’ the event. Alternatively, they can file it, with a comment, into one of seven categories:

1. Unauthorised Root Access
2. Unauthorised User Access
3. Attempted Unauthorised Access
4. Successful Denial of Service Attack
5. Poor Security Practice or Policy Violation
6. Reconnaissance/Probes/Scans
7. Virus Infection

If first-line analysts are unable to categorise or expire alerts, they can escalate them to senior analysts for investigation.

Analysts have a number of tools at their disposal to determine whether an alert indicates suspicious activity. The user interface can, for example, automatically conduct WHOIS checks on the source or destination IP addresses associated with alerts. This registration data can help to quickly determine whether the activity is expected behaviour, or not. The alerting packet data is also displayed with IP and TCP headers parsed out into individual fields and flags.

In addition to the centrally databased information, a second Snort instance sits on each sensor conducting a full packet capture. Analysts can instruct Sguil to retrieve this packet data and load it into Wireshark for analysis. Depending on the level of capture (it can be controlled based on amount of disk space available), this can allow a forensic investigation of network traffic, after-the-fact.

Non-Alert Analysis

Alerts don’t have to be the start point for analysis. Because all the session data from the SanCP sensors is centrally databased, investigations can start with internal or external IP addresses that have become suspicious for other reasons. Perhaps, for example, an ISP has reported that one of your network clients is port scanning, but this hasn’t been picked up by Snort. An analyst can quickly request session transcripts or a Wireshark dump to confirm the reported behaviour.

This example from Chas Tomlin shows how session information (in this case captured on an Sguil sensor via Snort rather than SanCP) can help track back to an original attack vector:

I began to look at the TCP sessions to and from the server around the time of the attack. The first sign of anything malicious was a session that looked like a backdoor to a remote server on port 6667 (IRC). So I decided to see if I could establish where the first backdoor session took place and look at the surrounding sessions for something that resembled an exploit. Again from web application exploit experience I knew I was looking for something that would look like a normal inbound connection to port 80 followed by the web server initiating an outbound session probably to port 80 to download some malicious code. I found a sequence of sessions that followed this exact pattern and determined that this was the initial vector.

Conclusion

NSM, and Sguil, are not replacements for an IDS/IPS system – they extend it. With access to databased events, statistical data and full packet capture at strategic points in your network, NSM can improve the efficiency, and overall success, of your analytical team.