- Snort is not a "badness-ometer."
- Snort is not "lightweight."
- Snort is not just a "packet grepper."
In this edition of the Snort Report, I expand beyond those ideas, preparing you to use Snort by explaining how to think properly about its use. Instead of demonstrating technical capabilities, we'll consider what you can do with a network inspection and control system like Snort.
For our purposes, we'll focus on Snort 2.x. At the moment it is unclear exactly what capabilities Snort 3.0 will offer. While the comments in this article will broadly apply to Snort 3.0, Sourcefire may provide new, unanticipated features.
A segment of the security community immediately equates anything related to "intrusion detection" or (worse) "monitoring" with Snort. When I taught classes with the title "Network Security Operations," students would show up asking, "Is this the Snort class?" I would mention that we would learn how to perform network security monitoring, and students would respond with "You mean Snort, right?" While this is a testimony to the importance and mindshare Snort has achieved in the decade it's been available, there are limitations when using Snort and these misconceptions result in a user whose security worldview is exceptionally narrow.
I see similar issues with existing Snort users. It's not uncommon to see questions posted to the #snort IRC channel or to the snort-users mailing list asking how Snort can be operated outside of its designated use model -- for example, "How can I use Snort to monitor bandwidth usage and alert on high traffic levels?" or "How do I make Snort log sessions/flows?" It's inspiring to see such faith in Snort, but such questions indicate a certain amount of tool-fixation.
Positioning Snort as active or passive
Snort can operate in two modes: active and passive. Snort can be active either inline or offline. In an active, inline mode, Snort acts as an intrusion prevention system (IPS). A Snort appliance physically sits on the wire between other networking components, inspecting traffic as it passes from one network interface card to the other. In this gatekeeper function Snort makes pass or block decisions based on the traffic it sees and the configuration it runs.
In an active, offline mode, Snort acts as a quasi-IPS. It does not sit inline, but it sees traffic passing nearby. Under certain conditions Snort will react to traffic it has been programmed to consider malicious. Because the Snort appliance is limited in the fact that it cannot physically deny traffic in this deployment model, it must rely on trying to "knock down" traffic using RST segments for TCP traffic or ICMP error messages for UDP traffic. This model sees Snort as a network control device of last resort; truly inline devices (firewalls, usually) are expected to stop undesirable traffic.
Snort can also run passively, meaning it takes no actions to interfere with traffic. Passive operation can happen in inline or offline deployments as well. In passive, inline mode, Snort sits physically on the wire and allows all traffic to pass. Inspection is done and alerts are generated, but no blocking occurs. This mode is usually a prelude to adopting an active, inline mode.
I strongly recommend deploying a Snort appliance in tandem with an external bypass switch when Snort is operating inline, either in passive or active mode. Net Optics Bypass Switches have performed reliably for me over the years. If you need more information on bypass switches versus other tap types, please see the free online copy of Chapter 4 from my book Extrusion Detection.
Finally, Snort can operate in a passive, offline mode. While I cannot cite statistics, I submit this deployment model is the most popular. Here Snort watches traffic provided by a network tap or switch SPAN port. The tool generates alerts, which must be reviewed by a security analyst. When configured properly a Snort sensor operating in this mode is essentially invisible to an intruder.
Now that we appreciate how Snort can be positioned on the network, what are we supposed to do with it? First a decision must be made regarding Snort's active or passive role in the environment. If you're comfortable deploying a system that has the ability to disrupt traffic -- malicious, suspicious or sometimes even normal -- then you can go active. If you prefer to let other security devices make blocking and filtering decisions, then Snort should stay passive. Many people who are considering using Snort as an active defense tool deploy passively inline then switch to actively inline once they gain confidence in Snort's operation.
Let's assume a passive, offline deployment. If you're reading this article you're more likely getting started with Snort, so experimenting with an implementation that is least likely to impact the environment is the best way to begin.
Now we must set proper expectations regarding Snort's operation because it has its limitations. I prefer to view Snort as a means to acquire indications of network activity. I don't consider Snort to be a definitive means to say exactly what is happening in an enterprise. Please note I am not talking about so-called "false positives." As far as I am concerned, Snot did its job if I tell it to look for "uid=0(root)" and the following from attack-responses.rules fires when I visit http://www.testmyids.com/:
alert ip any any -> any any (msg:"ATTACK-RESPONSES id check returned root";
content:"uid=0|28|root|29|"; classtype:bad-unknown; sid:498; rev:6;)
If, however, Snort fires an alert saying it saw "id=0(root)" but that string never appeared on the wire, I consider that event to be a real false positive.
That alert is designed to catch something like the following in cleartext:
uid=0(root) gid=0(wheel) groups=0(wheel), 5(operator)
Years ago (and sometimes today) it was popular to embed the Unix "id" command at the end of shellcode. When a service was exploited, the shell provided to the attacker would finish execution by showing the level of access granted by the exploit.
Sometimes the data in a Snort alert (if Snort is configured to provide it) can be enough to differentiate among normal, suspicious and malicious traffic. For example, the alert created by rule 498 above contains a packet payload like the following:
HTTP/1.1 200 OK.
.Date: Tue, 20 N.
ov 2007 20:08:14.
d: Mon, 15 Jan 2.
007 23:11:55 GMT.
ive: timeout=2, .
This is clearly a Web response. Additional data can be helpful to see exactly what happened. The following is a transcript generated from Sguil. The data was collected by a second instance of Snort running in pure Libpcap packet logging mode. The content was built using Tcpflow. The operating system fingerprinting was done by P0f.
Sensor Name: hacom.
Timestamp: 2007-11-20 20:02:31.
Connection ID: .hacom_208895.
Src IP: Obscured (Obscured).
Dst IP: 126.96.36.199 (kundenserver.de).
Src Port: 46480.
Dst Port: 80.
OS Fingerprint: Obscured:46480 - Linux 2.6, seldom 2.4 (older, 4).
(up: 16 hrs) .
OS Fingerprint: -> 188.8.131.52:80 (distance 3, link: ethernet/modem).
SRC: GET / HTTP/1.1.
SRC: Host: www.testmyids.com.
SRC: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206).
Gecko/20060601 Firefox/220.127.116.11 (Ubuntu-edgy).
SRC: Accept: text/xml,application/xml,application/xhtml+xml,text/html;.
SRC: Accept-Language: en-us,en;q=0.5.
SRC: Accept-Encoding: gzip,deflate.
SRC: Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7.
SRC: Keep-Alive: 300.
SRC: Connection: keep-alive.
SRC: Pragma: no-cache.
SRC: Cache-Control: no-cache.
DST: HTTP/1.1 200 OK.
DST: Date: Tue, 20 Nov 2007 20:08:14 GMT.
DST: Server: Apache/1.3.33 (Unix).
DST: Last-Modified: Mon, 15 Jan 2007 23:11:55 GMT.
DST: ETag: "9b30607-27-45ac0a3b".
DST: Accept-Ranges: bytes.
DST: Content-Length: 39.
DST: Keep-Alive: timeout=2, max=200.
DST: Connection: Keep-Alive.
DST: Content-Type: text/html.
DST: uid=0(root) gid=0(root) groups=0(root).
A Web browser visiting www.testmyids.com generated the SRC traffic. The Web server at www.testmyids.com provided the DST reply traffic. In this example one can see that the indication of something potentially bad (ATTACK-RESPONSES id check returned root) can be validated by looking at the packet accompanying Snort, or, better yet, reviewing a transcript. The transcript shows the activity before the offending packet(s) as well as the offending traffic itself.
This very short example hints at the real power of Snort. I tend to see Snort as a pointer to activities that require additional inquiry. A Snort alert should be the beginning of an investigation, not the end. If a Snort alert appears and you say, "That's OK, I don't need to analyze that," you should question why you have the alert firing in the first place.
Many times you'll find that using Snort is an excellent source of indicators, but Snort is limited when acting as a tool for investigations. I find that real analysis requires supporting data, often involving activity outside the scope of the Snort alert. This is an area where supporting tools (open source or commercial) can make a big impact.
In future Snort Reports we will consider how to integrate other tools with Snort. We will also return to reviewing new features in Snort 2.8.0.