Museum Of Broken Packets

hobbicik writes: "Quote from the page: 'The purpose of this museum is to provide a shelter for strange, unwanted, malformed packets - abandoned and doomed freaks of nature - as we, mere mortals, meet them on twisted paths of our grand journey called life.'" Interesting and amusing idea. Most of the wasted packets I get are IIS worm attempts -- not nearly as interesting.

Comments

Paranoid? Or are they really out to get us?

[DataPath]

Did anyone else get really paranoid about that ACK packet from a hotmail server that returns traceroute type information that would pierce most stateful firewalls?

"This packet arrived from www.law10.hotmail.com, one of web servers handling Hotmail traffic... But unlike standalone traceroute packets, this legitimate traffic will be forwarded thru most of stateful firewalls, allowing you to obtain a valuable information about their internal network structure, distance and such - and all this with virtually no possibility to be detected. Well done - this covert packet looked so innocent... "

Causes of mal-formed packets

[sstammer]

For some causes of mal-formed packets, see this paper

Tim

A real bit bucket

[Animats]

Back in the early days of TCP/IP, before it was supported in Berkeley UNIX, I did a major rewrite on one of the early TCP/IP implementations. This was UNET, from 3COM. I wrote UDP and ICMP for UNET, overhauled TCP, and added logging.

My approach to logging was to log all packets that didn't advance the connection. This included not only rejected packets but duplicates, empty ACKs, and related junk. In the early days, I'd get only a few packets per day once I'd debugged the TCP implementation thoroughly. As more implementations appeared on the Internet, I'd get more junk packets, and would E-mail back the packet source telling them how their protocol stack was broken. In those days, everybody on the net was DoD funded, and the other implementations were typically from researchers. We became something of a validation site for TCP/IP.

Once Berkeley UNIX got a TCP/IP stack, the amount of logged junk increased substantially.

I'd see one or two packets per day that passed Ethernet CRC but failed TCP/IP checksums, even from the local net. Early Ethernet controllers were apparently subject to memory errors. Most other bad packets were associated with the beginning of a connection. But we'd sometimes see a large number of packets that didn't advance the connection, indicating broken retransmit timers.

So I probably had the first museum of bad packets.

Re:Paranoid? Or are they really out to get us?

[monkeydo]

tcptraceroute works by sending syn packets with incremented TTL's to publicly available servers on port 80 (or other public port). This passes firewalls because they are configured to allow traffic to these servers (hence "publicly available")

Again, this will not work if your firewall drops the outbound ICMP packets. In the case of tcptraceroute you will eventually get an ACK back from the server, so you will know how many hops it behind the firewall, but no other information.

The hotmail trick is somewhat more insidious because it is used in the midst of a session the firewall will usually pass the traffic to a normally protected (even NAT'd) host.

Both are easily blocked with outbound filters.

Re:Hmmm

[frank_adrian314159]

Surely we now need a `Museum of shoddy half-assed software which passes junk as validly formed data`?

Yeah, but the domain 'microsoft.com' is already taken.

Insert rimshot here...