Slashdot Mirror
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.
Now how can one differentiate between a real malformed packed or one that someone just created to get it into the museum?
"Life moves pretty fast. You don't stop and look around once in a while, you could miss it." Ferris Bueller
"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... "
Inconceivable!
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.
There was this really interesting paper on intrusion that I had once read.
The paper basically had this idea that for every spoofed TCP packet, the receiptent will return a message, upon which the original sender would essentially say that it did not send the packet.
This paper made a statistical analysis of logging such packets over a fixed range of IP addresses, and then extrapolated from that result.
That way, one could get an idea of spoofed attacks being carried out. But the downside was that a lot of security programs themselves at times spoof IPs to mask their identity, so that could kind of alter the result by a reasonably high margin.
But I remember that it had a probability of a really high number of attacks being carried out under spoofed addresses. Pretty interesting read, although I do not seem to be able to locate where I had read it.
A site like this could be very useful for those of us designing stacks and equipment.
For example, where I work we are writing software for routing, PPP, PPPoE, RIP, OSPF, and so on with all sorts of encapsulations. In an early field test we discovered a lot of cases where our PPP stack would fall over but we couldn't reproduce the problems with our lab equipment. Since then we wrote a bunch of test tools to purposely corrupt packets in any way imaginable to test our software.
BTW, does anyone know of a good site displaying various exploit packets? My firwall seems to catch a lot of them (I'm on a broadband connection).
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
Slashdot probably gets the most interesting assortment of connections from all types of operating systems and routers from all over the world. It would be cool to monitor Slashdot's malformed IP packets and see if there is some trend.
Arp requests dude. They time out so when you move a computer it doesn't have problems connecting. The first packet sent out to an IP when an arp table entry on the switch isn't available gets sent to everyone. When the host replies, the switch uses that to update its cache. Fairly standard really. This isn't a problem if the host without an entry sends the first packet, but it happens. I'll post anything else I see as a reply to this...
SIG: HUP
I'd send out e-mails like "your implementation is not compliant with MIL-STD
para
This was needed. There were too many implementations that wouldn't talk to anything other than themselves, or screwed up when bandwidth was tight, or had related bugs.
TCP/IP could have turned into an N-squared problem, where you needed a matrix of what could talk to what, or where implementations had to be aware of the bugs in other implementations.
We managed to avoid that.
There was a cultural problem. The idea that the protocol specification ruled, not the implementations, was painful to some implementors. That's standard procedure in aerospace, where specs across vendor boundaries are taken seriously, and I was at Ford Aerospace.
Most of the players, even the universities, were DoD-funded through DARPA, and DoD insists on compliance with standards, so eventually, everybody was beaten into compliance.
In the end, everything talked to everything else.