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.
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.
- 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)
Nov 9th 2006
Nov 9th 2006
1 decade ago