Protocol 61 Packets Follow Up
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
Network Monitoring and Threat Detection In-Depth | Singapore | Nov 18th - Nov 23rd 2024 |
Comments
MrProtocol
Apr 15th 2013
1 decade ago
Any host internal protocol.
StarLight
Apr 15th 2013
1 decade ago
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.
Hugo
Apr 15th 2013
1 decade ago
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.
Hal
Apr 15th 2013
1 decade ago