Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Links

Museum Of Broken Packets 127

Posted by CmdrTaco from the put-them-on-a-milk-carton dept.
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.
This discussion has been archived. No new comments can be posted.

Museum Of Broken Packets More

Museum Of Broken Packets

Comments Filter:

  • Hmm (Score:3, Funny)

    by MxTxL ( 307166 ) on Monday November 19, 2001 @02:17PM (#2585660)
    Well, there are stranger "museums" out there. At least it's not a museum of modern art.
    • Maybe intentionally malformed packets *are* modern art...in a more pure sense of the term. Not only is it just poorly done, it's using a completely modern medium. Just you wait, someday you'll find a computer terminal showing live tcpdumps of malformed packets.

  • Be sure (Score:2, Offtopic)

    by ez76 ( 322080 )
    Be sure to include this tragically lost packet [leoburnett.com].

  • Authenticity? (Score:1, Interesting)

    by johann6 ( 471372 )
    Now how can one differentiate between a real malformed packed or one that someone just created to get it into the museum?
    • Not to nitpick or anything, but why would somebody do something like that?, yeah, I know boredom, attention, etc. But would it really matter if it was crafted wrong or became mutilated later?? The museum didn't specify they had to be "naturally occuring" mutations.

    • If it were a packet using IPSec AH (authentication headers), the authenticity could be verified.

  • Paranoid? Or are they really out to get us? (Score:5, Interesting)

    by DataPath ( 1111 ) on Monday November 19, 2001 @02:20PM (#2585675)
    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... "

    • 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.
    • Y'all DO know about tcptraceroute [toren.net], right?

      • Re:Paranoid? Or are they really out to get us? (Score:5, Informative)

        by monkeydo ( 173558 ) on Monday November 19, 2001 @05:01PM (#2586321) Homepage
        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.
        • > 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.
          • 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.
    • 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?


      • 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 sure that... (Score:4, Funny)

    by taffyd ( 316451 ) on Monday November 19, 2001 @02:20PM (#2585677)
    ...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.

  • Hmmm (Score:3, Funny)

    by MrFredBloggs ( 529276 ) on Monday November 19, 2001 @02:21PM (#2585680) Homepage
    Surely we now need a `Museum of shoddy half-assed software which passes junk as validly formed data`?

  • Causes of mal-formed packets (Score:5, Informative)

    by sstammer ( 235235 ) on Monday November 19, 2001 @02:22PM (#2585686)
    For some causes of mal-formed packets, see this paper [acm.org]


    Tim

    • Slashdot could be a good test-best for this (Score:1, Interesting)

      by Anonymous Coward
      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.

  • Something to "Marvel" at... (Score:3, Funny)

    by GISboy ( 533907 ) on Monday November 19, 2001 @02:22PM (#2585687) Homepage
    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!

  • Special packets (Score:1, Funny)

    by Anonymous Coward
    Is the going to be special place for packets going to port 139?
    • Yes, /dev/null... (or "NUL:" if you're on Windows)
      At the moment my firewall (iptables) logs and drops unwanted packets. I used it like this for about a couple of hours, looked at the log, then added an extra "don't log, just drop" rule specifically for NetBIOS...
      Hardly surprising, since I'm on a LAN Internet connection full of poorly configured Windows Notworking hosts spamming each other (and potentially the entire Internet, since they use 255.255.255.255, although I suspect/hope my college filters NetBIOS out at the router...)


      • Hardly surprising, since I'm on a LAN Internet connection full of poorly configured Windows Notworking hosts spamming each other (and potentially the entire Internet, since they use 255.255.255.255, although I suspect/hope my college filters NetBIOS out at the router..


        Well, RFC1812 specifies, that packages sent to the "limited broadcast address" (255.255.255.255) MUST NOT be forwarded by any router. Hence, unless your router(s) are seriously broken/misconfigured, the rest of the internet should be fairly safe ;)



        In general, RFC1812 is interresting reading, dictating how an IPv4-router should behave ;)

  • 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...

  • Geek? (Score:2, Funny)

    by Anders ( 395 )

    One thing is that I immediately think "IP" when I read "packets". But why did I have to misread "twisted paths" as "twisted pair"?

  • Awe-inspiring (Score:3, Funny)

    by still cynical ( 17020 ) on Monday November 19, 2001 @02:23PM (#2585697) Homepage
    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?
    • Actually I have some rather nice free-form dust patterns on my monitors. It isn't such a big deal as long as the dust is equally distributed. But as soon as someone comes along and puts a little finger print in my dust and that part of the monitor all of a sudden is brought into sharp focus it just pisses me off. I have to clean the whole screen and start my dust collecting over.

  • Malformed? Hmm (Score:3, Funny)

    by Anonymous Coward on Monday November 19, 2001 @02:24PM (#2585704)
    Nowadays you get a malformed packet, and they'll call the FBI thinking there's anthrax in it.

    OOps, wrong kind of packet.

  • Occam's Razor (Score:4, Funny)

    by uberchicken ( 121048 ) on Monday November 19, 2001 @02:25PM (#2585706)
    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?

  • Slashback? (Score:2, Funny)

    by Lars T. ( 470328 )
    Anybody else thought this would be a sequel to this [slashdot.org]?

  • A real bit bucket (Score:5, Interesting)

    by Animats ( 122034 ) on Monday November 19, 2001 @02:44PM (#2585769) Homepage
    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.

    • 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.

      Argh, here he is.. the first net-cop!

      • The first net-cop? (Score:3, Interesting)

        by Animats ( 122034 )
        At least for TCP/IP, that's probably right.
        I'd send out e-mails like "your implementation is not compliant with MIL-STD ...,
        para ..., subparagraph ..., because the packet dumped below...".


        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.

    • I'd see one or two packets per day that passed Ethernet CRC but failed TCP/IP checksums, even from the local net

      Any Ethernet frame, valid or not, will have a correct CRC, unless there is a problem on your local LAN. Also, your router wouldn't look at TCP or TCP checksums, but it certainly shouldn't pass anything with an incorrect IP checksum.

      It sounds like you may have been attributing some of these malformed packets to faulty TCP/IP stacks on the other end, when the problem was actually your LAN or gateway. Were you using experimental layer 2/3 equipment?
      • This was back in the early 1980s. Everything about TCP/IP was experimental. Routers were mostly PDP 11/34 machines running Dave Mills' Fuzzball code. Hosts were mostly DEC-20 machines, with Mark Crispin at Stanford frantically trying to get their protocols stack to work. But yes, I did see bad packets that were travelling entirely over the local LAN. I suspected memory errors in the Ethernet board in a VAX.

  • Microsoft Patents the Broken Packet (Score:4, Funny)

    by rsimmons ( 248005 ) on Monday November 19, 2001 @02:45PM (#2585780) Homepage
    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.

  • Wabi-Sabi (Score:1, Offtopic)

    by DaoudaW ( 533025 )
    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 [utne.com]
  • You should go to a mail warehouse, where you will see really strange lost packets.

  • Broken packets? Slashdotting? (Score:3, Funny)

    by cr@ckwhore ( 165454 ) on Monday November 19, 2001 @02:53PM (#2585808) Homepage
    I hope the Museum of Broken Packets can adequately catalog its own slashdotting.

  • A paper on intrusion (Score:3, Interesting)

    by metlin ( 258108 ) on Monday November 19, 2001 @02:56PM (#2585827) Journal
    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.
    • You're probably thinking about this paper [caida.org]. Abstract:
      In this paper, we seek to answer a simple question: "How prevalent are denial-of-service attacks in the Internet today?". Our motivation is to understand quantitatively the nature of the current threat as well as to enable longer-term analyses of trends and recurring patterns of attacks. We present a new technique, called "backscatter analysis", that provides an estimate of worldwide denial-of-service activity.
  • My logs are plagued with IIS Worm packets, usless bandwith hogging garbage. Anybody have any fun ideas to deal with these other than automailing [admin webmaster etc.]@IP and add IP to hosts.deny?

    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.

    • Not sure if this is what you're looking for, but it may help. Stick this in the httpd.conf of your mod_perl enabled Apache server: # Nimda: Block incomming requests. { package Apache::Vermicide; use Apache::Constants qw(:common :response); sub handler { my $r = shift; if ($r->uri() =~ /root\.exe|cmd\.exe|default\.ida/i) { $r->push_handlers(PerlLogHandler => sub { return BAD_REQUEST }); return BAD_REQUEST; } return DECLINED; } } PerlPostReadRequestHandler Apache::Vermicide

    • 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.
  • http://mobp.museum/
  • 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?

  • This could be very useful (Score:3, Interesting)

    by AaronW ( 33736 ) on Monday November 19, 2001 @04:29PM (#2586177) Homepage
    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).
    • If you just want to know what certian attacks look like, I might suggest going to snort.org and looking at the Intrusion detection rules they have. (downloads, snort-rules-current)

      While this isn't a pretty-pictures way of doing it, they do contain a lot of signatures for suspicious packets. Be ready for information in this kind of format:

      alert tcp $EXTERNAL_NET !80 -> $HOME_NET 21554 (msg:"BACKDOOR GirlFriendaccess"; flags: A+; content:"Girl"; reference:arachnids,98; sid:145; classtype:misc-activity; rev:3;)

      Which means a tcp segment from an outside machine on port 80, to an inside machine on port 21554 with the text content "Girl" might be an attempt to access the "Girlfriend" trojan horse.

      Better yet, why not install and run snort on a low-end box and let it identify the wacky ones for you. I run one on a console only OpenBSD box with a p-90 and it monitors a T1 just fine. Another runs on a 486-120 under console-only linux.

      There is even a Window$ version for those that prefer that platform.

  • Reason for Exhibit one (Score:3, Interesting)

    by autocracy ( 192714 ) <slashdot2007@sto ... .com minus berry> on Monday November 19, 2001 @04:50PM (#2586265) Homepage
    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...

  • 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:

    Nov 18 12:58:01 home kernel: Packet log: ppp-out - ppp0 PROTO=1 xx.xx.xx.32:65535 yy.yy.yy.82:65535 L=24 S=0xC0 I=51990 F=0x002C T=255 (#1)
    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...

    • The datagram in question is a fragment. There is no ICMP type 65535, valid values are 0-255, and the common ones are 0-18, however this data is only valid in the first fragment. This looks like part of a large ICMP packet.

      Check your logs, there should be more of these fragments before this one. The first will have more useful information.

      Go here [logi.cc] to analyze ipchains log output.
  • 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.

  • 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.

Slashdot Top Deals

"Money is the root of all money." -- the moving finger

Close