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!

Comments

Anonymous said…
qru, you're famous now! don't forget us little people
--ppcx
4:17 PM
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 ... :(
5:43 PM
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
10:39 AM
Anonymous 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
10:34 AM
Anonymous said…
@Jean-Marc

Try http://cctf.shmoo.com/
2:15 AM
Post a Comment

Popular posts from this blog

Zeek in Action Videos

Image
This is a quick note to point blog readers to my Zeek in Action YouTube video series for the Zeek network security monitoring project .  Each video addresses a topic that I think might be of interest to people trying to understand their network using Zeek and adjacent tools and approaches, like Suricata, Wireshark, and so on.  I am especially pleased with Video 6 on monitoring wireless networks . It took me several weeks to research material for this video. I had to buy new hardware and experiment with a Linux distro that I had not used before -- Parrot .  Please like and subscribe, and let me know if there is a topic you think might make a good video.
Read more

MITRE ATT&CK Tactics Are Not Tactics

Image
Just what are "tactics"? Introduction MITRE ATT&CK  is a great resource, but something about it has bothered me since I first heard about it several years ago. It's a minor point, but I wanted to document it in case it confuses anyone else. The MITRE ATT&CK Design and Philosophy document from March 2020 says the following: At a high-level, ATT&CK is a behavioral model that consists of the following core components: • Tactics, denoting short-term, tactical adversary goals during an attack; • Techniques, describing the means by which adversaries achieve tactical goals; • Sub-techniques, describing more specific means by which adversaries achieve tactical goals at a lower level than techniques; and • Documented adversary usage of techniques, their procedures, and other metadata. My concern is with MITRE's definition of "tactics" as "short-term, tactical adversary goals during an attack," which is oddly recursive. The key word in the tacti...
Read more

New Book! The Best of TaoSecurity Blog, Volume 4

Image
  I've completed the TaoSecurity Blog book series . The new book is  The Best of TaoSecurity Blog, Volume 4: Beyond the Blog with Articles, Testimony, and Scholarship .  It's available now for Kindle , and I'm working on the print edition.  I'm running a 50% off promo on Volumes 1-3 on Kindle through midnight 20 April. Take advantage before the prices go back up. I described the new title thus: Go beyond TaoSecurity Blog with this new volume from author Richard Bejtlich. In the first three volumes of the series, Mr. Bejtlich selected and republished the very best entries from 18 years of writing and over 18 million blog views, along with commentaries and additional material.  In this title, Mr. Bejtlich collects material that has not been published elsewhere, including articles that are no longer available or are stored in assorted digital or physical archives. Volume 4 offers early white papers that Mr. Bejtlich wrote as a network defender, either for technica...
Read more