Detect events without Snort IDS rules

In this edition of Richard Bejtlich's Snort Report, value-added resellers (VARs) and consultants learn to run Snort IDS and analyze what it detects based on the Snort.conf file discussed in the previous Snort Report tip.

In the last Snort Report, we built a basic snort.conf configuration file from the ground up, called snort- (Please refer to the previous Snort Report to see that configuration file.) In this month's edition we'll try running Snort IDS and seeing what we can detect using that simple configuration.

First, we start Snort.

Snort is running, but it did not load any rules. We did not tell Snort where to find rules, so we will rely upon the few preprocessors that are enabled in order to detect a few classes of suspicious activity. We can test Snort's ability to detect odd traffic by using Aaron Turner's Tcpreplay to replay a trace known to contain activity that will trigger Snort's http_inspect preprocessor.

tcpreplay -i lnc0 snort_report_03_tr1.lpc

While inspecting this traffic, Snort created the following in its alert file:

[**] [119:2:1] (http_inspect) DOUBLE DECODING ATTACK [**]
01/22-22:07:28.688987 ->
TCP TTL:63 TOS:0x0 ID:27136 IpLen:20 DgmLen:788 DF
***AP*** Seq: 0x2A5D6595 Ack: 0x752A8AC8 Win: 0x16D0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 2095123656 1034302447

We can use the command line protocol analyzer Tshark to inspect the snort.log.TIMESTAMP alert.

The culprit here is the %252C part of the URL at the Web site (ng-prod1.cisco.com). The string %252C appears to be a double-encoded value which essentially translates into a , (comma) in the title "Cisco Security Monitoring, Analysis and Response System". Snort's http_inspect preprocessor is more likely to be concerned by URLs containing the string %255C, which is the \ (back slash) found in a directory traversal attack.

Here's another example of an alert generated by Snort after seeing an unusual Web request.

[**] [119:15:1] (http_inspect) OVERSIZE REQUEST-URI DIRECTORY [**]
01/22-22:41:23.119820 ->
TCP TTL:64 TOS:0x0 ID:7566 IpLen:20 DgmLen:744 DF
***AP*** Seq: 0xBBF23720 Ack: 0x19A00C1F Win: 0x8218 TcpLen: 32
TCP Options (3) => NOP NOP TS: 698053 318452739

Let's see why Snort saw using Tshark again.

Snort's http_inspect preprocessor found a request for an exceptionally long URL, and it triggered an alert.

Let's make this case a little more interesting. We'll use Dug Song's Fragroute running on the Arudius live Linux CD to chop up our traffic into IP packets with no more than 24 bytes of layer 4 and higher data. First we enable Fragroute with a simple fragroute.conf with only "ip_frag 24" and "print" enabled.

[email protected]:~# fragroute
fragroute: ip_frag -> print

Now we repeat the unusual Web request, but we let Fragroute fragment it at the IP level. When Snort exits, it reports handling 30 fragmented IP packets.

Fragmentation Stats:
Fragmented IP Packets: 30    (20.690%)
    Fragment Trackers: 1
    Rebuilt IP Packets: 1
    Frag elements used: 0
Discarded(incomplete): 0
    Discarded(timeout): 0
    Frag2 memory faults: 0

However, it still generated an alert.

[**] [119:15:1] (http_inspect) OVERSIZE REQUEST-URI DIRECTORY [**]
01/22-23:00:35.128908 ->
TCP TTL:64 TOS:0x0 ID:30864 IpLen:20 DgmLen:744
***AP*** Seq: 0x3534AC68 Ack: 0x6212185D Win: 0x5B4 TcpLen: 32
TCP Options (3) => NOP NOP TS: 59262 319596988

This is what the snort.log.TIMESTAMP trace looks like to Tshark.

This looks like a packet similar to the one we just saw. However, this is a pseudo-packet created by Snort's IP reassembly feature. The real traffic looks like this:

As you can see, the URL was chopped into many smaller packets. Thanks to Snort's Frag2 preprocessor, Snort was able to reassemble them for analysis by the http_inspect preprocessor. The http_inspect preprocessor then recognized an abnormally long URL.

This example raises two important points. First, Snort can perform several important detection tasks without any rules. In this article we

Snort IDS tips for resellers
Get more tips on how to use the open source IDS Snort from expert Richard Bejtlich's Snort Report
really only enabled portions of the http_inspect preprocessor, and we did not exercise the TCP stream reassembly features. Second, Snort's view of the world as represented by the packets it provides might not reflect the real traffic observed on the wire. This is one reason why some analysts choose to not rely on a single inspection process like Snort for "ground truth" on network activity.

In the next edition of the Snort Report, we'll enable dynamic preprocessors to detect more activity without yet enabling rules.

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.

Dig Deeper on Managed network services technology