Jumat, 08 April 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!

0 komentar:

Posting Komentar