This chapter is from the book
This chapter is from the book
This chapter is from the book
The Basic Sguil Interface
Sguil relies on Snort for its primary flow of alert data. (If all Sguil did was allow easier access to Snort alerts, many people would still prefer it to several alternative interfaces.) Snort alerts populate the RealTime Events tab. (I'll explain the Escalated Events tab shortly.) By default Sguil breaks the top half of the screen into three windows (see Figure 10.1). Alert information is shown in each window, with the top window showing the most severe alerts, the middle window showing less serious alerts, and the bottom window showing the least important alerts. These windows correspond to the priority levels in Snort, with priority levels 1 and 2 at the top, 3 and 4 in the middle, and 5 at the bottom. Analysts can tweak the sguil.conf configuration file to present a single pane with all alerts if they so choose. Fonts are also configurable by using Sguil's File→Change Font sequence.
)
Figure 10.1 Sguil interface with the highlighted WEB-MISC /~root access alert
The bottom part of the main Sguil display is broken vertically into two halves. The left side of the screen shows host name and Whois database information, at the discretion of the analyst. Because DNS queries for host names or lookups for Whois information may take up to several seconds, many analysts turn these options off unless they need the information. Sguil does not cache results internally, although the default DNS server usually will. The bottom of the left side of the screen shows system messages or user messages, depending on the tab selected. System messages pertain to the amount of space left on the disk collecting NSM information. User messages appear in an interactive chat application similar to Internet Relay Chat. Anyone logged in with the Sguil client to the same Sguil server can communicate via the interface in the User Messages tab. Figure 10.1 shows that user sguil thinks that "Sguil rocks!"
The right side of the bottom of the main Sguil window is dedicated to the highlighted alert. This varies according to the nature of the alert. Reconnaissance alerts show the sorts of packets caused by the scan. All other alerts show the packet details in a manner similar to that used by ACID. Above the packet details you find options for displaying the rule that generated the Snort alert.
The alert highlighted in Figure 10.1 has a message type of WEB-MISC /~root access. The ST column on the far left of the top pane shows a value of RT. The ST column refers to the status of the alert. A status of RT means "real time," meaning the alert has appeared in the Sguil interface and is waiting for validation or escalation. This feature hints at the accountability features built into Sguil. Alerts simply do not scroll off the screen, to be lost in a database. Analysts must inspect and validate or escalate alerts. (I'll cover that in the section Making Decisions with Sguil.) The second column, marked with the CNT header, shows the count of similar events. Because this WEB-MISC alert has been seen from the same source IP to the same destination IP 14 times, the CNT field shows that number. This value increments dynamically while the interface is active.
The third column shows the name of the sensor generating the alert. In this single-sensor configuration, only the name bourque appears. To the right of the sensor name is a two-part number representing the sensor and alert number. Here it's 1.73474, which corresponds to sensor ID 1, "connection" ID 73474. Beyond the sid.cid field we see a timestamp, followed by the source IP, source port, destination IP, destination port, and protocol of the packet or, potentially, the stream that generated the alert. Bringing up the rear is the alert message.
If an analyst is not familiar with the pattern or sequence of events that cause a WEB-MISC /~root access alert to appear, he or she can choose the Show Rule option by checking the corresponding box at the top of the lower-right window. In Figure 10.1 the full rule is obscured due to display constraints, but I've reproduced the entire rule here.
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-MISC /~root access"; flow:to_server,established; uricontent:"/~root"; nocase; classtype:attempted-recon; sid:1145; rev:6;)
We see that a packet containing the string /~root headed toward any ports defined in the $HTTP_PORTS variable (such as 80 TCP) will trigger this alert. If the rule definition is not sufficient to help the analyst understand the alert, he or she can press the www.snort.org button, which launches an instance of the defined Web browser. The URL for the alert will be visited, which in this case is http://www.snort.org/snort-db/sid.html?sid=1145. On this page the analyst can read Snort's own documentation for the WEB-MISC /~root access alert.
If the Show Packet Data button is selected, Sguil shows the packet that triggered the alert. In our example, it shows the following:
GET /~root HTTP/1.0.
This is the ASCII representation of the application data; the hexadecimal value is also shown.
On the left-hand side of the screen in Figure 10.1, DNS and Whois information has been turned on. As a result we see the source IP of 66.92.162.97 resolves to njektd.com, and the destination IP is a Comcast cable modem. The Whois data for the source IP shows it belongs to a netblock owned by the Speakeasy DSL ISP.