[Snort-users] Sniffers Misbehaviors (MS Network Monitor & tcpdump)?

Martin Roesch roesch at ...421...
Tue Jan 2 12:49:25 EST 2001


It could be a padding error from Superscan when it generates its PING
packets.  The interesting thing here is that the IP datagram length is equal
for all the packet printouts, but Snort is the only one that seems to be
paying attention to it.  I don't know if this is a good or bad thing, but at
least we're conforming to spec...  :)

It'd be interesting to see what the caplen for these packets is compared to
the IP dgm length...

     -Marty

Ofir Arkin wrote:
> 
> When I have published my article about "Identifying ICMP Hackery Tools" a
> gentleman name Johan Augustsson have sent me an email about SuperScan 3.0, a
> tool by Foundstone.
> 
> Ok, I set down to examine it, and I was amazed to see the following results
> with the different sniffers I was using. I was using Network Monitor by
> Microsoft on my Windows 2000 Server machine, tcpdump on my Debian box, and
> Snort v1.7 beta 8. Look at the following:
> 
> This is the tcpdump trace:
> god:~# /usr/sbin/tcpdump -xnvv icmp
> tcpdump: listening on eth0
> 15:20:14.933525 192.168.1.5 > 192.168.1.15: icmp: echo request (ttl 128, id
> 6547)
>                          4500 0024 1993 0000 8001 9de1 c0a8 0105
>                          c0a8 010f 0800 d7fd 0200 1e02 0000 0000
>                          0000 0000 0000 0000 0000 0000 0000
> 15:20:14.933596 192.168.1.15 > 192.168.1.5: icmp: echo reply (ttl 255, id
> 4115)
>                          4500 0024 1013 0000 ff01 2861 c0a8 010f
>                          c0a8 0105 0000 dffd 0200 1e02 0000 0000
>                          0000 0000
> 
> 2 packets received by filter
> 0 packets dropped by kernel
> 
> This is the Network Monitor results:
> ICMP Echo Request:
> 00000000  00 60 08 4C 9B 68 00 50 DA 4F DB 1A 08 00 45 00 .`.L.h.P.O....E.
> 00000010  00 24 19 93 00 00 80 01 9D E1 C0 A8 01 05 C0 A8 .$..............
> 00000020  01 0F 08 00 D7 FD 02 00 1E 02 00 00 00 00 00 00 ................
> 00000030  00 00                                           ..
> 
> And the reply:
> 00000000  00 50 DA 4F DB 1A 00 60 08 4C 9B 68 08 00 45 00 .P.O...`.L.h..E.
> 00000010  00 24 10 13 00 00 FF 01 28 61 C0 A8 01 0F C0 A8 .$......(a......
> 00000020  01 05 00 00 DF FD 02 00 1E 02 00 00 00 00 00 00 ................
> 00000030  00 00 00 00 00 00 00 00 00 00 00 00             ............
> 
> WHOOPS!!!!!!!!!!!!!!!!!
> What the hell? I mean, there are ONLY 8 bytes of 0's of data that are sent.
> Here I get a report that there are additional 8 bytes of 0's in the reply,
> while tcpdump reported "those" in the request!
> 
> Snort:
> Initializing Network Interface eth0
> Decoding Ethernet on interface eth0
> 
>         --== Initialization Complete ==--
> 
> -*> Snort! <*-
> Version 1.7-beta8
> By Martin Roesch (roesch at ...66..., www.snort.org)
> 01/01-15:20:14.933525 192.168.1.5 -> 192.168.1.15
> ICMP TTL:128 TOS:0x0 ID:6547 IpLen:20 DgmLen:36
> Type:8  Code:0  ID:512   Seq:7682  ECHO
> 00 00 00 00 00 00 00 00                          ........
> 
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
> 
> 01/01-15:20:14.933596 192.168.1.15 -> 192.168.1.5
> ICMP TTL:255 TOS:0x0 ID:4115 IpLen:20 DgmLen:36
> Type:0  Code:0  ID:512  Seq:7682  ECHO REPLY
> 00 00 00 00 00 00 00 00                          ........
> 
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
> 
> Now, is this one reported?
> Some one bumped into this one?
> ANY IDEAS?
> 
> Ofir Arkin
> ofir at ...949...
> http://www.sys-security.com
> PGP CC2C BE53 12C6 C9F2 87B1 B8C6 0DFA CF2D D360 43FA
> 
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> http://lists.sourceforge.net/mailman/listinfo/snort-users

-- 
Martin Roesch
roesch at ...421...
http://www.snort.org




More information about the Snort-users mailing list