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.
Well, there are stranger "museums" out there. At least it's not a museum of modern art.
Be sure to include this tragically lost packet.
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 boss would consider packets all of the packets routed to slashdot by me when I was meant to be working as "strange, unwanted and malformed". ;)
Taffyd.
Surely we now need a `Museum of shoddy half-assed software which passes junk as validly formed data`?
This is much the same thing:
http://www.iquest.net/~phillip/
Tim
Faster than a speeding packet,
More powerful than a triple Mocha,
Able to leap Full Towers in a single bound,
Look behind the window!
It's a boot disk!
No! It's a packet!
No! It's a...OOooo, shiney object!
If it is not on fire, it is a software problem.
Is the going to be special place for packets going to port 139?
if some folk have to much time on their hands.
surely the iis worms are one of the most useful applications around these days - forces an upgrade on the user; an upgrade to linux!
if only they used the netcraft service to check first before ruining your neat log files...
free (as in mp3s) electronic music
One thing is that I immediately think "IP" when I read "packets". But why did I have to misread "twisted paths" as "twisted pair"?
One cannot comprehend the mind-boggling amounts of spare time required to devote part of one's life to this.
What's next, a repository of images of free-form dust patterns from monitor screens?
Ignorance is the root of all evil.
Nowadays you get a malformed packet, and they'll call the FBI thinking there's anthrax in it.
OOps, wrong kind of packet.
means that it's the packet capture utility that's hosed, not the packets. :)
Is it, by any chance, on the Island of Misfit Toys?
Anybody else thought this would be a sequel to this?
Lars T.
To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
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.
You mean this story, already posted on slashdot, right?
See .sig for further commentary.
pooptruck
Utterly cool. I had (still have) an Ethernet
NIC (one of those ISA RealTek noname ones) that
trashes about 15% of the packages... It was
quite fun to find out the hard way - strange
sounds in mp3s, trashed porn mpegs (the involved
persons looked like aliens from Species in some scenes, because of the MPEG corruption)..
Exactly. It's brilliant in it's simplicity and subtlety. It's something you probably wouldn't think of unless you had an absolutely brilliant mind and were trying really hard to do that. I applaud their genius if nothing else.
Inconceivable!
In a stunning move to corner one of the oldest markets in networking, Microsoft has patented the concept of a broken packet. Many router manufacturers may come under litigation if they do not pay the licensing fees.
you mean this story?
"I don't need a compass to tell me which way the wind shines." - Mr. Furious, Mystery Men
All things are imperfect. Nothing that exists is without imperfections. When we look closely at things, we see the flaws. The sharp edge of a razor blade, when it is magnified, reveals pits, chips, and variegations. And as things begin to break down and approach the primordial state, they become even less perfect, more irregular, and perhaps more lovely.
--Exquisite Decay
Boy, I'm sure glad that this ssubmission made it in and my submission about Apple's ownership of the Alpha Blending patent getting in the way of the PNG format's progression [theregister.co.uk] was rejected.
Why yes, I am bitter about it. Thanks for asking. I finally felt like I had a story worth contributing to the masses.
Maybe it was rejected because it ran last week.
Now you can be bitter AND embarrased.
m00.
You should go to a mail warehouse, where you will see really strange lost packets.
------I can please only one person per day. Today is not your day. Tomorrow isn't looking good either.------
I hope the Museum of Broken Packets can adequately catalog its own slashdotting.
Skiers and Riders -- http://www.snowjournal.com
Well on the bright side it was worth submitting. Someone just beat me to it and I somehow snored my way through the previous posting. Mod my first post down to -1. I deserve it.
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.
...are a big geek.
And I applaud you for it!
Cool idea!
-cw
Speaking of misdirected or lost packets, would any of you happen to know why my WinME machine starts sending and receiving packets after about 10 minutes of inactivity (even on a fresh install)? I know it does so, because my OS X machine is running natd sharing a PPP connection and OS X's PPP useage meter lights like a christmas tree up until I use the PC or turn it off.
Well, perhaps the reason Slashdot rejected it was that they already ran a story on Apple's alpha blending patent several days ago?
Not all rejections are ridiculous, you know.
I've been grepping and gwaking more IPs to deny than I can count.
Reason: Your Computer, Server, or ISP is in need of a worm update. Get to it you Lazy Excuse for an Admin.
It has helped reduce the monthly count, but there's always sombody new. I think by now these worms should have been terminated, and those who are still passing it (Under Rock Livers) should be punished. If I only had the bandwidth to DOS 'em all down (Bad Toad, No Cookie).
Sombody out there has to be doing something more vendictive than mails and denys, I just want to hear about it. Really, just Hear.
Opinions Expressed by Me should be Forced on Others - PbHead
http://mobp.museum/
This isn't hard to foil at all. The "attacker" (hotmail in this case) can already trace up to your firewall, but not beyond it. This allows them to get the _incoming_ packets passed the firewall because they are part of an established connection, but the _outgoing_ packets will not be, they will be ICMP packets. Just block the outgoing TTL Exceeded packets (and while you are at it all ICMP except maybe ECHO) at your firewall.
It is as important to control what is leaving your network as what is coming in.
Si vis pacem, para bellum
The only thing more annoying than a Libertarian is an (un|mis)informed Libertarian
Already done.
Y'all DO know about tcptraceroute, right?
-- Cerebus
I can understand the problems for a business, but why is it so bad for someone just to know the toplogy behind the average user's firewall?
"as plurdled gabbleblotchits on a lurgid bee" - Prostetnic Vogon Jeltz. (One man's humorous is another mans flamebait)
I'll admit that it's "FlameBait" if you'll pay the $5 admission fee to attend my "Pocket Fluff Symposium".
Does anyone else expect that this collection will grow to include all of the orphaned packets, lost and all alone, that will appear when the server becomes slashdotted?
Jocking for a funny post....
Hriste22
This paper is simply great. Among other things it mentioned that the D-Link ethernet adapter's driver had a bug in it causing to to create malformed packets. Does anyone know what is the most error-free ethernet adaptor/driver combination?
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
Wow, I don't think I would've even payed attention to most of those. I guess I don't know enough about TCP, etc, to recognize subtle stuff.
Though I do know enough (or not enough) to wonder about stuff like this:
At least it looks weird to me (ICMP type 65535?) Anybody know what that's about? I just noticed it recently when it went to 212.15.64.41 which is where some linux worm phones home, but it pops up every now and then to other hosts too.Probably a simple explanation but while all the network geeks are in the room I figured I'd ask...
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.
Si vis pacem, para bellum
The only thing more annoying than a Libertarian is an (un|mis)informed Libertarian
First fact: Switches are NOT security devices. They are designed to boost network performance, not to provide security from sniffers. There are ways to make most switches broadcast traffic like a hub.
Second.. we're talking about the switching tables on the switch, not the arp cache (arp cache is the wrong word probably in this case). A switch keeps track of which mac address is on which port. These things time out after a while. So when a switch gets a packet with a destination mac address it doesn't recognize.. it HAS to broadcast it to all ports.
BTW, standard learning bridges work the same way.
Check out the FAQ at http://www.robertgraham.com/pubs/firewall-seen.htm l. It explanes a lot of the detritus that washes up on the shores of firewalls.
Example 1 is no particular mystery. The switch simply hasn't learned the MAC address of the intended destination. This could happen if the switch were newly rebooted, for example.
Cabletron had, at one point, a philosophy of "switch centric" networks. Even when layer 3 capabilities were built in so that the switches could, after a fashion, act like a router with respect to limiting broadcast traffic, it wouldn't be out of the question that some of the older equipment might still broadcast unicast packets under these conditions. These swtiches were often referred to by local staff as "routers", on the theory of walks-like-duck-quacks-like-duck.
I don't have a lot of experience with Cabletron stuff, but later stuff I've encountered uses standard VLAN techniques and could absolutely be configured to act like a router if that was what was desired. A temporarily misconfigured VLAN could cause this kind of unwanted packet -- for example if you attach a host, repeater or non-vlan switch to a trunk port of a VLAN switch. In that case you might receive broadcast traffic to any of the networks trunked by the port and unicasts to unlearned MACs. The whole point of VLAN is to physically uncouple cable segments to logical networks and to implement customizations to network topologies in software.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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.
Alright, it was me that has been doing this.
I had figured that chaining together rand48() with libpcap to generate random packets was the first step in creating an artificial life form out of the Internet at large.
If you'd just not exposed me prematurely like this I soon would have been successful in my attempt to create this life form.
"Provided by the management for your protection."
Last Night while surfing a forum.
I thought quite the same.
I was surfing from behind a *nix box,
ala lucent v.42, without domain name.
Natted and routing for all, no local
ports on the masking box to call..
running old kernel builds I like and
tcpservices large and small..
BUt: What appears to my pixelated eyes and
hunch postured frame?
but konqueror: browsing and moving and
abiding, in a remote hacksters game..
aghast and afraid, I hit the kill switch,
rueing and reviling the impulse which,
made me a lamer in me own home, and
caused an fsck 30 minutes long...
Not to mention the reintall, log analysis,
etc..
NO BS this really happened.
I'm not sure if this is what you would call a malformed packet, but definitely a lost one that had returned home to roost!
Newt-dog
My Doctor prescribed daily nasal saline irrigation, hehe
Yes.. if we are talking about separate vlans, (conceptually, different networks separated by a router) then the switch IS misbehaving. But that also depends on exactly how the switch is configured.
As for having a switch do arp requests in proxy-like fashion.. that's not the purpose of the switch. As for why it's 'not too wise' I don't understand.. ti's *exactly* what switches were designed to do... the purpose of a switch is to increase network performance (compared to a hub) by a best-effort attempt to put traffic only where it needs to be, without actually changing the behavior of the network itself.
As for a switch sending out an arp request... that in and of itself would be a broadcast packet to everywhere.... besides, as soon as the switch sees traffic from the 'unknown' host it'll populate it's switch table and start working 'normally' again.
I refuse to waste even MORE of my bandwidth on this 'bandwidth hogging garbage' by responding to it.. so it all goes to /dev/null. The only time I will respond to something is if it is actually having a quantifiable detremental effect on my systems, and I think contacting anyone will resolve it.
I must say that this is quite interesting. And I agree taht it seems a little fishy about the packet from Hotmail. It seems that the folks at Microsoft are up to something.
--
Adobe's anti-counterfeiting softw
> 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.
... which couldn't have been reached without sending that first SYN, so you might as well traceroute it with the SYN in the first place.
I fail to see the significance of the difference.
-- Cerebus
From the RFC1149 experiment in april, we experienced a pretty unique form of packet mangling:t n/ 05preparation_fri_mangled.jpg.html
t n/ 02testpacket.jpg.html
http://www.blug.linux.no/rfc1149/vegard_bilder/
Though it's not *that* obvious it's mangled, here is a non-mangled packet for comparision:
http://www.blug.linux.no/rfc1149/vegard_bilder/
- Vegard, member of the RFC1149 implementation team (http://www.blug.linux.no/rfc1149)
If that isn't recursive moderation. :<
The SYN packet is the first packet of a TCP session. It is the packet that the computer initiating the session sends to the server to initiate the conversation.
When the server recieves a packet with the SYN flag set it either replies with a SYN/ACK, at which point the client sends an ACK and the session is established.
The SYN traceroute will only work with host that are directly accessable from the outside and is useful for tracing to a publicly available server. The Hotmail trick is useful for tracing to non-publicly available clients.
Si vis pacem, para bellum
The only thing more annoying than a Libertarian is an (un|mis)informed Libertarian