- Why Sguil?
- So What Is Sguil?
- The Basic Sguil Interface
- Sguil's Answer to "Now What?"
- Making Decisions with Sguil
- Sguil versus the Reference Intrusion Model
- Conclusion
Sguil's Answer to "Now What?"
At this point you might think Sguil is a cool way to look at Snort alerts. It certainly is, but we're only getting started. The question that NSM theory was designed to answer was stated in the beginning of the book: "Now what?" Now that we have an alert, what does the analyst do with it? Most commercial and many open source systems leave analysts with alerts and expect them to make escalation decisions based on the information present in the alert. The fact that Snort can be tweaked to show the information seen thus far is a big win for the open source community. Where do we go next?
Sguil is designed to collect alert, session, and full content data. If we have the Snort sensor configured to log libpcap data for port 80 TCP, we can take the next step using full content data. If we right-click on the sid.cid field of the highlighted event, we are given options to query the following items.
-
Event History: Show any comments and the validation status assigned by an analyst to the alert. New alerts marked RT do not have an event history yet.
-
Transcript: Generate full content data for the alert, if available. Sguil will query the sensor for libpcap data associated with the alert, use Secure Copy to transport it to the analyst workstation, and display the transcript in a new window.
-
Transcript (force new): Regenerate the transcript. If the first transcript was created while the session was still open, a transcript created using force new may show additional data that was exchanged during the session. Requested transcripts are stored on the server running the Sguil daemon and used to generate future transcripts for users who don't possess a copy of the pcap file on their local workstations.
-
Ethereal: Launch Ethereal, reading the same data as would be transferred to generate a transcript.
-
Ethereal (force new): As with forcing a new transcript, this option tells Ethereal to inspect the latest date for the session designated by the selected alert.
Transcripts are very useful for ASCII-based protocols, like HTTP. For the WEB-MISC /~root access alert, Figure 10.2 shows part of the transcript.
Figure 10.2 Sguil transcript for the WEB-MISC /~root access alert
The "Now what?" question for the WEB-MISC /~root access alert was "Did this attack succeed?" If the attack succeeded, we might have seen a 200 OK HTTP status code returned by the target, along with the contents of the /~root directory. Instead we see a 403 Forbidden HTTP status code, indicating the attack did not succeed.
The availability of transcripts is incredibly powerful. While it is tedious to inspect every alert in this manner, the power of having this sort of data on hand cannot be denied. There is no ambiguity here because we know as much as the intruder does about how the victim responded to the attack. After all, we see exactly the same data the intruder sees. (Of course, encryption obfuscates this form of investigation.)
Certain protocols are not easy for analysts to inspect by using transcripts. Figure 10.1 shows an RPC portmap listing TCP 111 alert at the top of the first pane. This is a good candidate for investigation using Ethereal. After highlighting the top alert and right-clicking on the sid.cid field, we launch Ethereal and see the results shown in Figure 10.3.
Figure 10.3 Ethereal inspecting full content data generated by Sguil
Using Ethereal, we see the DUMP Reply tells the intruder what RPC services the target offers. Again, by looking at the same data as seen by the remote party, we can evaluate the likelihood of the attack succeeding. Both ASCII and binary full content data help us understand the nature of the alert and the probability the intruder can accomplish her goal.
Resolving the alert at hand isn't the only item of concern. What else has an intruder attempted? There are two ways to answer this question: queries for alerts and queries for sessions. By default Squil supports querying against the source or destination IP addresses for either form of information. Let's return to the source of the WEB-MISC /~root access alert, 66.92.162.97. Right-clicking on the source IP address gives the following options.
-
Query Event Table: The analyst can query for alerts from the source IP, the destination IP, or from the source IP to the destination IP.
-
Query Sessions Table: The analyst can query for sessions from the source IP, the destination IP, or from the source IP to the destination IP.
-
Dshield IP Lookup: The analyst can query on source or destination IP. Querying on the source IP, for example, sends the URL http://www.dshield.org/ipinfo.php?ip=66.92.162.97 to the default Web browser. This returns data from the Dshield database, along with Whois information.
Querying for alerts means asking to see the traffic Snort judged to be suspicious. Querying for sessions means showing summaries of traffic and letting the analyst decide what is or is not suspicious. Analyzing session data is potentially more work, but it is a content-neutral approach. Snort alerts may not trigger on events obscured by encryption or fragmented by evasion tools. Session data has a greater chance of being recorded for events that do not trigger Snort rules and thereby lack alert data.
For the first example, we will query for events by right-clicking on the IP address 66.92.162.97 and selecting Query Event Table→Qry Src IP. This action launches the Query Builder, as shown in Figure 10.4.
Figure 10.4 Sguil Query Builder
Once the Query Builder is started, an analyst can enter SQL statements in the Edit Where Clause field. By selecting items from the three columns, the Query Builder helps construct more complicated queries. In most cases, the items requiring modification are the event.timestamp value (to accommodate queries for older events) or the LIMIT value. In our example, we leave the defaults and receive the results shown in Figure 10.5.
Figure 10.5 Event query results
The screenshot concentrates on the alerts displayed in the main Sguil window. Notice that the CNT value is 1, so all of the aggregated WEB-MISC /~root access alerts are seen individually. Besides alerts from the intruder to the target (66.92.162.97 to 68.84.6.72), Sguil shows alerts triggered by the target's response. These are ATTACK-RESPONSES 403 Forbidden alerts. Any one of these alerts can be investigated in the same way the original WEB-MISC /~root access alert was analyzed.
Had we queried for sessions instead of alerts, we would have seen results like those shown in Figure 10.6. Session data is content-neutral, so Sguil reports any sessions recorded by the keepstats option of Snort's stream4 preprocessor. Session results do not appear as alerts. Certain columns are easy to understand, such as the sensor name, starting and ending timestamps, and source and destination IPs and ports. The second column, Ssn ID, is a session identifier. The final four columns provide information on the numbers of packets sent by the source and destination and on the count of bytes sent by the source and destination. From the session results window, analysts can generate transcript, launch Ethereal, or query for any field or combination of fields in the event or session database tables.
Figure 10.6 Session query results