Strange states for custom ICMP packets
Carter Bullard
carter at qosient.com
Fri Nov 28 18:18:18 EST 2014
Hey /Elof,
Argus uses a 6-tuple flow key for ICMP traffic. We do that so we can get RTT's (round trip times) for the pings, and other req/resp ICMP flows. For ICMP traffic, the 4th and 5th tuples are the ICMP type and code fields, and the 6th tuple is a sequence number for some ICMP types. Its pretty clear that hping is not forming conformant packets, as the type and code fields are different and I suspect that particular type and code payload formats aren't to speck.
What is hping anyway ???
Carter
> On Nov 28, 2014, at 12:03 PM, elof2 at sentor.se wrote:
>
> Hi Carter!
>
> This is just a report of a minor strangeness.
>
> If I run this hping command:
> echo -n "Hello,World" > /tmp/hello_world.txt
> hping3 -1 -c 10 -i 3 -n -C 0 -K 0 -d 11 -E /tmp/hello_world.txt 111.111.111.111
>
> ...I get this output from ra:
>
> StartTime Flgs Proto SrcAddr Sport Dir DstAddr Dport SrcPkts DstPkts SrcBytes DstBytes State
> 14:47:22.269359 e icmp 111.111.111.111.0x2600 <- 10.244.159.37.0x0dbb 0 1 0 60 ECR
> 14:47:25.265160 e icmp 10.244.159.37.0x031f -> 111.111.111.111.0x0dbb 1 0 60 0 DCE
> 14:47:28.265469 e icmp 10.244.159.37.0x0307 -> 111.111.111.111.0x0dbb 1 0 60 0
> 14:47:31.265819 e icmp 10.244.159.37.0x0304 -> 111.111.111.111.0x0dbb 1 0 60 0 SRC
> 14:47:34.266148 e icmp 10.244.159.37.0x0304 -> 111.111.111.111.0x0dbb 1 0 60 0 SRC
> 14:47:37.266547 e icmp 10.244.159.37.0x0008 -> 111.111.111.111.0x0dbb 1 0 60 0 ECO
> 14:47:40.266854 e icmp 10.244.159.37.0x820f -> 111.111.111.111.0x0dbb 1 0 60 0 IRQ
> 14:47:43.267169 e icmp 10.244.159.37.0x201f -> 111.111.111.111.0x0dbb 1 0 60 0 DCE
> 14:47:46.267479 e icmp 10.244.159.37.0x001f -> 111.111.111.111.0x0dbb 1 0 60 0 DCE
> 14:47:49.267786 e icmp 10.244.159.37.0x0008 -> 111.111.111.111.0x0dbb 1 0 60 0 ECO
>
> ...or this:
>
> StartTime Flgs Proto SrcAddr Sport Dir DstAddr Dport SrcPkts DstPkts SrcBytes DstBytes State
> 11:34:38.786492 e icmp 10.200.0.52.0x001f -> 111.111.111.111.0x5cac 1 0 60 0 DCE
> 11:34:41.782536 e icmp 10.200.0.52.0x0007 -> 111.111.111.111.0x5cac 1 0 60 0
> 11:34:44.782427 e icmp 10.200.0.52.0x001f -> 111.111.111.111.0x5cac 1 0 60 0 DCE
> 11:34:47.782421 e icmp 10.200.0.52.0x0007 -> 111.111.111.111.0x5cac 1 0 60 0
> 11:34:50.791829 e icmp 10.200.0.52.0x0101 -> 111.111.111.111.0x5cac 1 0 60 0
> 11:34:53.806536 e icmp 10.200.0.52.0x0107 -> 111.111.111.111.0x5cac 1 0 60 0
> 11:34:56.781956 e icmp 10.200.0.52.0x0005 -> 111.111.111.111.0x5cac 1 0 60 0 RED
> 11:34:59.781889 e icmp 111.111.111.111.0x1c00 <- 10.200.0.52.0x5cac 0 1 0 60 ECR
> 11:35:02.781718 e icmp 10.200.0.52.0x0107 -> 111.111.111.111.0x5cac 1 0 60 0
> 11:35:05.791089 e icmp 10.200.0.52.0x0207 -> 111.111.111.111.0x5cac 1 0 60 0
>
> ...or this:
>
> StartTime Flgs Proto SrcAddr Sport Dir DstAddr Dport SrcPkts DstPkts SrcBytes DstBytes State
> 11:37:06.535637 e icmp 10.200.0.52.0x0101 -> 111.111.111.111.0x5cad 1 0 60 0
> 11:37:09.539314 e icmp 10.200.0.52.0x0107 -> 111.111.111.111.0x5cad 1 0 60 0
> 11:37:12.555582 e icmp 10.200.0.52.0x0107 -> 111.111.111.111.0x5cad 1 0 60 0
> 11:37:15.558824 e icmp 10.200.0.52.0x0207 -> 111.111.111.111.0x5cad 1 0 60 0
> 11:37:18.535193 e icmp 10.200.0.52.0x0207 -> 111.111.111.111.0x5cad 1 0 60 0
> 11:37:21.536809 e icmp 10.200.0.52.0x0207 -> 111.111.111.111.0x5cad 1 0 60 0
> 11:37:24.534740 e icmp 10.200.0.52.0x0007 -> 111.111.111.111.0x5cad 1 0 60 0
> 11:37:27.534754 e icmp 10.200.0.52.0x0007 -> 111.111.111.111.0x5cad 1 0 60 0
> 11:37:30.535038 e icmp 10.200.0.52.0x0207 -> 111.111.111.111.0x5cad 1 0 60 0
> 11:37:33.535025 e icmp 10.200.0.52.0x0101 -> 111.111.111.111.0x5cad 1 0 60 0
>
>
> So, we get all kinds of different states... ECR, DCE, blank, SRC, ECO, IRQ, and so on.
> This is strange, since all we do is to send the same icmp packet 10 times.
>
> Even more strange is that the 10 flows look different from time to time.
>
> Sometimes, the IPs and direction are even reversed. This is probably because the flow is treated as a response (ECR) even though it is not.
>
> I don't know what to make out of this. :)
> Perhaps is is a bug, or perhaps this is just what happens when crafting your own ICMP-packets like this...
>
> Oh well, just thought I'd let you know in case it's a bug. :)
>
> /Elof
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2443 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20141128/b93fa98f/attachment.bin>
More information about the argus
mailing list