Snort Few Q&A by Richard Bejtlich

In this edition of the Snort Report, I address some of the questions frequently asked by service providers who are users or potential users of Snort. I say "potential users" because some people hear about Snort and wonder if it can solve a particular problem. Here I hope to provide realistic expectations for service providers using Snort.

1. Can I use Snort to protect a network from denial-of-service attacks?

Before answering many of these questions it's important to define terms and reveal assumptions. A denial-of-service (DoS) attack consumes one or more computing resources (bandwidth, memory, CPU cycles, hard drive space or other information system components). Sometimes DoS attacks are initiated by a single party, while others are so-called distributed DoS or DDoS attacks.

DDoS attacks enlist more than one aggressor to assault a victim. The first popular DoS attacks were clever resource consumption attacks against memory (e.g., the SYN floods of the mid-1990s), but since the late 1990s DDoS attacks that consume bandwidth have been prevalent. Less popular, but still damaging, are application-centric DoS attacks, whereby regular activity (like retrieving a Web page) is repeated to the point that the victim's operation is impaired.

What can Snort do about DDoS attacks? Snort's Vulnerability Research Team publishes a set of rules named ddos.rules. This file contains a small set of signatures for detecting activity caused by older DoS tools like Tribe Flood Network, Shaft, Trinoo and Stacheldraht. Emerging Threats publishes bleeding-dos.rules, which contains a greater variety of rules. However, the question remains: What good are rules like these?

When users or potential users ask if Snort protects against DoS attacks, they usually want to know if Snort can deflect or mitigate bandwidth consumption attacks. The answer to this question is probably no. When deployed as an offline, passive device, there is little or nothing Snort can do to stop or reduce a bandwidth-consuming SYN flood, for example. Snort can potentially report seeing many SYN segments, but it won't improve the situation. The rules packaged in ddos.rules and bleeding-dos.rules are designed to either detect DoS agent command-and-control or possibly identify certain types of attacks that subvert but do not breach a target.

When deployed as an inline, active device, Snort acts as a so-called intrusion prevention system and can, in some cases, stop DoS attacks. For example, an intruder may use a malicious packet to cause a vulnerable Cisco router to reboot or freeze. An inline Snort deployment could identify and filter the malicious packet, thereby "protecting" the router. If the intruder switched to a SYN flood or other bandwidth consumption attack against the router, however, Snort would most likely not be able to counter the attack -- at least not on its own.

2. Can Snort decode encrypted traffic?

Let's assume that encrypted traffic means Secure Sockets Layer (SSL) or Transport Layer Security (TLS) as used by HTTPS, or Secure Shell protocol 2 as used by OpenSSH.

The short answer is no, Snort cannot decode encrypted traffic. An intruder who attacks a Web server in the clear on port 80 TCP might be detected by Snort. The same intruder who attacks the same Web server in an encrypted channel on port 443 TCP will not be detected by Snort. An intruder who displays the contents of a password file via a Telnet session on port 23 TCP might be detected by Snort. The same intruder who displays the same password file via a SSH session on port 22 TCP will not be detected by Snort.

Now, in some circumstances it's possible to decode HTTPS sessions. This is not done natively by vanilla Snort -- it must be handled by an external program. See my blog post on Wireshark Display Filters and SSL, especially the comments, for more details.

Generally speaking, a stand-alone Snort instance can inspect traffic in an encrypted channel if the traffic is subjected to a man-in-the-middle (MITM) attack. In other words, traffic is encrypted while traveling from the client to the MITM. Once the traffic reaches the MITM, it is unencrypted while Snort inspects it. Then, traffic is re-encrypted before traveling from the MITM to the server. (The reverse happens as well.) Such a setup must be intentionally designed and implemented by the network and security architects and accepted by management and users.

Also note that Snort cannot inspect Web pages that are Gzip-encoded. This bandwidth-consumption technique is perfectly legitimate, but it shields Web page contents from Snort's gaze. Uncompressing Gzip-encoded content on the fly would be prohibitively expensive, although not impossible.

3. Can Snort detect layer 2 attacks?

Generally speaking, Snort is a layer 3 and above detection system. This means Snort inspects and acts upon IP packet details, like source and destination IP addresses, time to live (TTL), IP ID and so on. This excludes MAC addresses, Ethertype, VLAN IDs and other details found before the start of the layer 3 header.

Snort does contain an "arpspoof" preprocessor, but the code has always been marked "experimental." I don't know of anyone who uses it in production. Most users who want to detect layer 2 network events use layer 2-specific tools like Arpwatch.

4. Can Snort log flows or sessions?

This question, like the others, indicates the hope that Snort can accomplish a goal best left to specialized tools. Let's assume the question indicates a desire to log details of TCP sessions. Snort's Stream4 preprocessor does include a "keepstats" option that records session statistics for TCP flows. An earlier version of Sguil relied on this data. Unfortunately, this capability is limited to TCP traffic. All other protocols are ignored.

Note that Stream4 is being deprecated in favor of Stream5. Stream5 does not offer a "keepstats" function, although Stream5 does track UDP "sessions" for Snort's own detection purposes.

To log flows or sessions, use a stand-alone tool like Argus. If you're already using Sguil, take a look at the Security Analyst Network Connection Profiler (SANCP), which logs session details for many protocols. A third option is to collect NetFlow or another flow format from a hardware probe, or less often, a software probe.

5. Can Snort rebuild content from traffic?

In order to perform its detection functions, Snort rebuilds several types of content. For example, it's impossible to match the password "hackerpassword" sent over Telnet without letting Snort rebuild the traffic. However, Snort is not designed to watch traffic and rebuild everything it sees. A review of the README.Stream5 document shipped with Snort 2.8.0 shows that the new preprocessor offers a "show_rebuilt_packets" option that will "Print/display packet after rebuilt (for debugging)." This option is off by default, but even if enabled it's not the sort of capability I recommend activating in Snort.

People who wish to rebuild content typically want to parse Libpcap trace files to rebuild TCP sessions. One of the best tools for this job is Tcpflow. Tcpflow can be run against a dead trace or a live interface. If given no parameters, Tcpflow will rebuild all TCP sessions it sees, putting the content from client to server in one file and the content from server to client in another file. Tcpflow repeats this process for every single TCP session it finds.

If you run this sort of operation on a large Libpcap trace, you might learn what it means to run out of inodes on a Unix machine. If you do the same against a live interface, you'll probably start dropping many packets. Tcpflow is best pointed against a trace after being told exactly what to rebuild. For example, "Rebuild this FTP session involving this source IP and this source port."

Do you have other questions you would like answered? Email them to me at taosecurity at gmail.com.

About the author
Richard Bejtlich is founder of TaoSecurity, author of several books on network security monitoring, including Extrusion Detection: Security Monitoring for Internal Intrusions, and operator of the TaoSecurity blog.

TCP SYNCOOKIES - SYN FLOOD

Mail service for Panix, an ISP in New York, was shut down by a SYN flood starting on 6 September 1996. A week later the story was covered by the RISKS Digest, the Wall Street Journal, the Washington Post, and many other newspapers.

SYN flooding had been considered by security experts before. It was generally considered insoluble. See, for example, ``Practical UNIX and Internet Security,'' by Garfinkel and Spafford, page 778:

The recipient will be left with multiple half-open connections that are occupying limited resources. Usually, these connection requests have forged source addresses that specify nonexistent or unreachable hosts that cannot be contacted. Thus, there is also no way to trace the connections back. ... There is little you can do in these situations. ... any finite limit can be exceeded.

Large SYN queues and random early drops make SYN flooding more expensive but don't actually solve the problem.
SYN cookies are now a standard part of Linux and FreeBSD. To enable them, add

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

to your boot scripts.

What are SYN cookies?
SYN cookies are particular choices of initial TCP sequence numbers by TCP servers. The difference between the server's initial sequence number and the client's initial sequence number is

* top 5 bits: t mod 32, where t is a 32-bit time counter that increases every 64 seconds;
* next 3 bits: an encoding of an MSS selected by the server in response to the client's MSS;
* bottom 24 bits: a server-selected secret function of the client IP address and port number, the server IP address and port number, and t.

This choice of sequence number complies with the basic TCP requirement that sequence numbers increase slowly; the server's initial sequence number increases slightly faster than the client's initial sequence number.

A server that uses SYN cookies doesn't have to drop connections when its SYN queue fills up. Instead it sends back a SYN+ACK, exactly as if the SYN queue had been larger. (Exceptions: the server must reject TCP options such as large windows, and it must use one of the eight MSS values that it can encode.) When the server receives an ACK, it checks that the secret function works for a recent value of t, and then rebuilds the SYN queue entry from the encoded MSS.

A SYN flood is simply a series of SYN packets from forged IP addresses. The IP addresses are chosen randomly and don't provide any hint of where the attacker is. The SYN flood keeps the server's SYN queue full. Normally this would force the server to drop connections. A server that uses SYN cookies, however, will continue operating normally. The biggest effect of the SYN flood is to disable large windows.

Blind connection forgery
If an attacker guesses a valid sequence number sent to someone else's host then he can forge a connection from that host.

Attackers can try to cryptanalyze the server-selected secret function: inspect a series of valid cookies and then intelligently guess a new cookie. For a secure function, the attacker's chance of success is not noticeably better than the chance of success for a uniform random guess. Secret-key message authenticators are designed to provide exactly this type of security. The following function is extremely fast and appears to be secure: encode the input in 16 bytes; feed the result through Rijndael with a secret key; extract the first 24 bits of the result.

No matter what function is used, the attacker will succeed in a connection forgery after millions of random ACK packets. Servers can make this attack more expensive in two ways:

* Keep track of the most recent SYN queue overflow time (for each SYN queue, not in a global variable). Don't rebuild missing SYN entries if there hasn't been a recent overflow. This stops ACK forgeries from passing through SYN-blocking firewalls.
* Add another number to the cookie: a 32-bit server-selected secret function of the client address and server address (but not the current time). This forces the attacker to guess 32 bits instead of 24.

A new protocol with 128-bit sequence numbers would make blind connection forgeries practically impossible.

TCP State Transition Diagram