My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Protocol 61 Packets Follow Up

Published: 2013-04-14. Last Updated: 2013-04-14 23:55:40 UTC
by Johannes Ullrich (Version: 1)
4 comment(s)

Thanks for all the tips and packets we have received so far regarding protocol 61 traffic. I would like to summarize some of the responses here.

We got two captures of the suspect traffic. The source IPs are identical (5.5.128.1 and 2.2.128.1). The last octet of the target IP address is always 1. In each target network, only 1 or 2 IPs are hit by the odd packets.

The captures exhibit different time to live values, which may indicate that the packets originated from the same source in either case, but the sample is clearly too small at this point to decide about spoofed or not spoofed. My "guess" is that the IP addresses are spoofed. Yes, they are assigned real networks according to whois, but the addresses themselves just loop suspicious. Two addresses with the same last two octets, but very different first two octets doesn't sound right.

One reader pointed to a recent talk at a security conference showing that some routers are susceptibe to a denial of service if hit by odd protocols. It is possible that this tool attempts to trigger this condition, but unlikely as this wouldn't require packets at a high rate.

Most of the packets are 40 bytes in length with 20 bytes of IP header and 20 bytes of payload. One possible explanation would be that the 20 bytes of payload are actually a TCP header, but the data doesn't quite line up for that. For example, if interpreted as TCP, the TCP header length doesn't come up as 20 Bytes, and the flags are "wrong".

There are a couple of larger packets (up to 1500 bytes), but the vast majority is 40 bytes.

One reader provided some insight that the packets may be caused by an unspecified configuration or hardware error:

I have exactly the same, now for the 3rd or 4th time. Pretty unclear what this should be my guess after discussion with our upstram ISP's NOC was that there is something broken. The packets seem not to be spoofed and typically it lasts a week or so.

Personally, my bet is that this will turn out to be a configuration error or a bug, not an attack. But keep the packets coming (if you have any). Thanks to everybody contributing to this.

Two Sample packets (anonymized. The target network was changed to 10.10)

 

IP 5.5.128.1 > 10.10.128.1:  ip-proto-61 20
0x0000:  4500 0028 0000 0000 2f3d 7c88 0505 8001  E..(..../=|.....
0x0010:  0a0a 8001 0060 0ff3 c69c 78e1 7b42 1a25  .....`....x.{B.%
0x0020:  1197 1c27 d964 0000 0000 0000 0000       ...'.d........

IP 2.2.128.1 > 10.10.128.1:  ip-proto-61 20
0x0000:  4500 0028 0000 0000 2f3d 7f8b 0202 8001  E..(..../=......
0x0010:  0a0a 8001 0060 0ff7 c69c 60e6 7b36 e948  .....`....`.{6.H
0x0020:  ecf5 3f78 3a8d 0000 0000 0000 0000       ..?x:.........

Marked up fields for first packet

 

IP 5.5.128.1 > 10.10.128.1:  ip-proto-61 20
0x0000:  4500 0028 0000 0000 2f3d 7c88 0505 8001  E..(..../=|.....
         VHTO LEN  IPID FLAG TTPR CHSU Source IP
0x0010:  0a0a 8001 0060 0ff3 c69c 78e1 7b42 1a25  .....`....x.{B.%
         Target IP <--- Payload 
0x0020:  1197 1c27 d964 0000 0000 0000 0000       ...'.d........
                   ---> (ethernet padding)

V = version, H=header length, LEN=datagram length, FLAG: Frag. flags and offsets
TT: TTL, PR: Protocol, CHSU: checksum

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: 61 protocol
4 comment(s)
My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Comments

If you look at the length in the IP header, the payload should extend an additional two (null) bytes and the Ethernet padding reduced by two bytes. Thanks.
0x3D.

Any host internal protocol.

Hmmm. Given that a stream of packets is going on for a week I would guess that one would be able to trace it back in part.

Given that there is no real life usage for these packets any ISP can track the packets back to the next untill they trace it back to the customer sending them out.

Looking at a sample of Netflow data collected on a Tier 1 network, I found an additional source, which is also a French-registered network: 2.4.5.180.

Here are the counts for the sources, so you see that 3rd source accounts for practically nothing in the big picture. Keep in mind that this is from a sample of a sample: just the first 500 matching netflow records for each of the past 6 days:

SrcIP Packet Count
5.5.128.1 31 million
2.2.128.1 24 million
2.4.5.180 1,517

There were 139 destination addresses in this sample, spread out all over. The top destination received more than double the traffic of the next nearest, nowhere near a majority.



Diary Archives