Earlier this week, a user submitted one of those "odd packets" we all like. The packet was acquired with tcpdump, without the "-x" or "-X" option, but still, tcpdump decided to dump the entire packet in hexadecimal. I have seen tcpdump do things like this before, and usually attributed it to "packet overload". If I have tcpdump write the same traffic to disk (using the -w option) and later read it back with -r, I don't see this questionable traffic.
But I never bothered to really look into it. So today, returning from the dentist and under the influence of Novacaine after crown prep, I decided what better thing to do but to play a bit with packets.
Here is the setup:
I am running tcpdump on my firewall. I have it listen on all interfaces. The exact command line:
sudo tcpdump -i any -nn -xx not ip and not ip6 and not arp
Now if I got this filter right, I should see no IPv4, no IPv6 and no ARP . At first, I got packets like this:
21:39:55.404619 Out 00:e0:4c:68:e0:7d ethertype Unknown (0x0003), length 344: 0x0000: 0004 0001 0006 00e0 4c68 e07d 0000 0003 0x0010: 4510 0148 0000 0000 8011 2e93 0a05 00fe 0x0020: ffff ffff 0043 0044 0134 cb27 0201 0600 0x0030: 1223 3456 0000 8000 0000 0000 0a05 004a 0x0040: 0a05 00fe 0000 0000 000e f316 a4a6 0000 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 (removed remainder: all "0").
Interestingly, the packet has an "off" ethernet header that looks like it got an additional two bytes, followed by what looks like a normal IPv4 header.
On a second attempt, using the same filter, I even got some packets that got interpreted as IPv4, even though my filter should exclude them:
21:44:01.919690 IP 10.128.0.11.56559 > 10.5.1.12.80: Flags [.], ack 421172865, win 403, length 0 0x0000: 0000 0001 0006 8ab0 1e25 1fcb 0000 0800 0x0010: 4500 0028 b78a 4000 4006 6daa 0a80 000b 0x0020: 0a05 010c dcef 0050 69b5 295b 191a 9681
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter