In the last Snort Report, we built a basic snort.conf configuration file from the ground up, called snort-2.6.1.2-20dec06a.conf. (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.
[IMAGE]
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
To continue reading for free, register below or login
To read more you must become a member of SearchSecurityChannel.com
p>
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 69.143.202.28:58866 -> 198.133.219.83:80
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.
[IMAGE]
The culprit here is the %252C part of the URL at the 198.133.219.83 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 192.168.2.105:54024 -> 209.40.96.212:80
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.
[IMAGE]
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.
root@arudius:~# fragroute 209.40.96.212
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 192.168.2.103:46721 -> 209.40.96.212:80
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.
[IMAGE]
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:
[IMAGE]
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 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.
