fragmented packet challenge

Published: 2006-11-09
Last Updated: 2006-11-10 13:23:32 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)
Before signing off for the day and handing the helm over to Chris, I got one more diary for you.
This one is a challenge. Michael sent us this packet earlier today. He is seeing a lot of these hitting his mail server, all from the same source. I got some ideas about whats going on, but nothing "definite". So let me just show you the packet and see what you can come up with. I will post my opinion (and a summary of what you submit sometime late tomorrow.

The short summary of the packet:
- its the last fragment (MF is cleared, offset is 1472
- there are 8 bytes worth of payload
- the protocol is TCP

I obfuscated pieces that would help identify the submitter.

Update

I received a couple or interesting responses to this "challenge". Couple people noted that the offset + packet length is 1480, which would be in line with a regular ethernet MTU of 1500 bytes.
Alex had a couple of interesting insights: He noted that the 8 bytes of data are consistent with Base64 encoded data. While there is not enough data here to reconstruct any content, he suggests it may be one of the many "spam images" going around these days.
Also, he menioned that 1472 is a common MTU for PPPoE DSL connections.
So a likely reason for the fragment is that the host is connected to a local ethernet network which is using a DSL uplink.

The reason the first fragment is missing is likely some kind of packet filtering device. Given that only the first fragment will include the port number, the packet filter allows the second fragment to pass.

Lessons learned:
- If you are using a DSL modem with PPPoE, take a look at what MTU it supports. Your internet experience may improve if you reduce your MTU to match the DSL modems MTU.
- Check how your border device deals with fragments. I typically like to put some kind of statefull firewall at my border that will reassemble fragments. Most of the home-devices (NAT routers) typically do a good job at that. Its a bit more challenging to find one that can deal with large loads (in particular if you have a lot of connections. The bandwidth is sometimes not as critical here as the number of connections you are trying to support.

Thanks to everyone who responded!



Frame 1 (60 bytes on wire, 60 bytes captured)
Arrival Time: Nov 8, 2006 10:46:21.288548000
Time delta from previous packet: 0.000000000 seconds
Time since reference or first frame: 0.000000000 seconds
Frame Number: 1
Packet Length: 60 bytes
Capture Length: 60 bytes
Protocols in frame: eth:ip:data
Ethernet II, Src: (xx:xx:xx:xx:xx:xx), Dst: (xx:xx:xx:xx:xx:xx)
Type: IP (0x0800)
Trailer: 000000000000000000000000000000000000
Internet Protocol, Src: xxx.yyy.171.21 Dst: aaa.bbb.181.18
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 28
Identification: 0xdf49 (57161)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 1472
Time to live: 112
Protocol: TCP (0x06)
Header checksum: 0xXXXX [correct]
Good: True
Bad : False
Source: xxx.yyy.171.21
Destination: aaa.bbb.181.18
Data (8 bytes)

0000 75 37 68 4c 52 65 2b 4d u7hLRe+M

Keywords:
0 comment(s)

Comments


Diary Archives