Friday, April 08, 2005

Using Snort's -k Option

I was looking for traffic to test Snort today. I found the Honeynet Challenge Scan of the Month 27 to have just what I was looking for -- traffic caused by PsExec.

When I tried analyzing the traffic with Snort, I did not get a single alert:

drury:/usr/local/src/snort-2.3.2$ snort
-c etc/snort.conf -r /tmp/sotm27 -b -l /tmp/snort
Running in IDS mode
TCPDUMP file reading mode.
Reading network traffic from "/tmp/sotm27" file.
snaplen = 1514

--== Initializing Snort ==--
Initializing Output Plugins!
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file etc/snort.conf

+++++++++++++++++++++++++++++++++++++++++++++++++++
Initializing rule chains...
...edited...
Rule application order: ->activation->dynamic->alert->pass->log
Log directory = /tmp/snort

--== Initialization Complete ==--

,,_ -*> Snort! <*-
o" )~ Version 2.3.2 (Build 12)
'''' By Martin Roesch & The Snort Team: http://www.snort.org/team.html
(C) Copyright 1998-2004 Sourcefire Inc., et al.

Run time for packet processing was 0.89519 seconds


===============================================================================

Snort processed 54536 packets.
===============================================================================
Breakdown by protocol:
TCP: 54350 (99.659%)
UDP: 186 (0.341%)
ICMP: 0 (0.000%)
ARP: 0 (0.000%)
EAPOL: 0 (0.000%)
IPv6: 0 (0.000%)
IPX: 0 (0.000%)
OTHER: 0 (0.000%)
DISCARD: 0 (0.000%)
===============================================================================
Action Stats:
ALERTS: 0
LOGGED: 0
PASSED: 0
===============================================================================
...edited...
Snort exiting

When I looked at the alert file, it was empty:

drury:/usr/local/src/snort-2.3.2$ ls -al /tmp/snort
total 12
drwxr-xr-x 2 analyst wheel 512 Apr 8 15:49 .
drwxrwxrwt 22 root wheel 9216 Apr 8 15:49 ..
-rw------- 1 analyst wheel 0 Apr 8 15:49 alert

I couldn't figure out what was going on, but I should have looked closer at these packets with Tcpdump's -v option:

05:08:09.525204 219.118.31.42.1025 > 172.16.134.191.137:
[bad udp cksum 5af6!] NBT UDP PACKET(137): QUERY; REQUEST;
BROADCAST (ttl 111, id 1798, len 78, bad cksum 20ce!)

05:08:09.525205 172.16.134.191.137 > 219.118.31.42.1025:
[bad udp cksum ba13!] NBT UDP PACKET(137): QUERY; POSITIVE;
RESPONSE; UNICAST (ttl 127, id 33508, len 329,
bad cksum 93f4!)

05:08:09.817956 219.118.31.42.2388 > 172.16.134.191.139:
S [bad tcp cksum 5af6!] 1943715630:1943715630(0) win 16384
(DF) (ttl 111, id 1811, len 48,
bad cksum e0e9!)

Do you see all of the bad checksum errors? I jumped into the #snort-gui IRC channel and talked the problem over with the crew there. Thankfully, qru (aka Bamm Visscher) recommended using Snort's -k option:

-k checksum-mode
Tune the internal checksum verification functionality with
alert-mode. Valid checksum modes include all, noip, notcp,
noudp, noicmp, and none. All activates checksum verification
for all supported protocols. Noip turns off IP checksum verifi-
cation, which is handy if the gateway router is already dropping
packets that fail their IP checksum checks. Notcp turns off TCP
checksum verification, all other checksum modes are on. noudp
turns off UDP checksum verification. Noicmp turns off ICMP
checksum verification. None turns off the entire checksum veri-
fication subsystem.

That did the trick! Here was the result:

drury:/usr/local/src/snort-2.3.2$ snort
-c etc/snort.conf -r /tmp/sotm27 -b -l /tmp/snort -k none
Running in IDS mode
TCPDUMP file reading mode.
Reading network traffic from "/tmp/sotm27" file.
snaplen = 1514

--== Initializing Snort ==--
Initializing Output Plugins!
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file etc/snort.conf

+++++++++++++++++++++++++++++++++++++++++++++++++++
Initializing rule chains...
...edited...
Rule application order: ->activation->dynamic->alert->pass->log
Log directory = /tmp/snort

--== Initialization Complete ==--

,,_ -*> Snort! <*-
o" )~ Version 2.3.2 (Build 12)
'''' By Martin Roesch & The Snort Team: http://www.snort.org/team.html
(C) Copyright 1998-2004 Sourcefire Inc., et al.

Run time for packet processing was 0.759793 seconds


===============================================================================

Snort processed 54536 packets.
===============================================================================
Breakdown by protocol:
TCP: 54350 (99.659%)
UDP: 186 (0.341%)
ICMP: 0 (0.000%)
ARP: 0 (0.000%)
EAPOL: 0 (0.000%)
IPv6: 0 (0.000%)
IPX: 0 (0.000%)
OTHER: 0 (0.000%)
DISCARD: 0 (0.000%)
===============================================================================
Action Stats:
ALERTS: 2052
LOGGED: 2122
PASSED: 0
===============================================================================
...edited...
Snort exiting

And there were alerts now:

drury:/usr/local/src/snort-2.3.2$ ls -al /tmp/snort
total 1164
drwxr-xr-x 2 analyst wheel 512 Apr 8 15:49 .
drwxrwxrwt 22 root wheel 9216 Apr 8 15:49 ..
-rw------- 1 analyst wheel 744877 Apr 8 15:49 alert
-rw------- 1 analyst wheel 387900 Apr 8 15:49 snort.log.1112989772

Apparently all of the checksums were messed up when obscuring the victim IP addresses. The sotm27 trace uses a 172.16.0.0/16 victim IP range. These are not the true victim IP addresses. Whoever changed the destination IPs did not bother to fix the packet checksums. Snort by default did not process any packet with a bad checksum, so I didn't get any alerts until I changed the default processing mode. Thanks qru!

5 comments:

Anonymous said...

qru, you're famous now! don't forget us little people
--ppcx

Anonymous said...

At a time when GCIA certification meant something, not that long ago (before its MCSE-ization), this was one of the first thing someone would learn, before trying to analyze some of SANS' logs, for a practical analysis ... :(

Anonymous said...

Hi Richard,
I encountered exactly the same problem a few months ago when I also wanted to use the pcap files of sotm27 to do some IDS testing. I was not aware of the -k flag of snort at that time but since I was using tcpreplay to replay the traffic I used tcpreplay's -F flag to fix the checksum. This feature of tcpreplay is handy if you want to alter IP addresses to anonymize pcap file but want correct checksum.
By the way I also wanted to test the pcap of Defcon's rootfu contest (aka capture the flag, http://www.shmoo.com/cctf/ ), but the files do not seem to be available anymore... if anyone has them please let me know! (jmclerc@gmail.com)

/Jean-Marc

Eric hines said...

Richard,

FYI: I ran in to this problem when recording Nikto attack traffic, not replaying dumps from Honeynet or SANS. This was a live capture of traffic and Snort was not alerting on it unless I used -k none.

In sending it to Bamm, he found the issue was the snaplen of tcpdump. By default, its 96 bytes.


[ehines@wks3 ~]# file web_attacks.dump
web_attacks.dump: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 96). This of course would mess up the checksums in the pcap.

This is just an FYI to anyone here who comes upon this blog and has the same situation with a pcap file they've made.

Eric Hines

Christian Heinrich said...

@Jean-Marc

Try http://cctf.shmoo.com/