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!