Brought to you by Michal Zalewski.

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. Our exhibits - or, as you wish, inhabitants - are often just a shadow of what they used to be before they met a hostile, faulty router. Some of them were born deformed in the depth of broken IP stack implementation. Others were normal packets, just like all their friends, but got lost looking for the ultimate meaning of their existence, and arrived in places we should never see them. Every time, we try to recover a unique history of their lives, and to make you understand how difficult it is to be a sole messenger in the hostile universe of bits and bytes. If you have uncommon, interesting orphan packets you'd like me to take care of, please contact me. Our reality is interesting enough, do not make up stories; and always look for a rational explaination first... Thanks :)

Exhibit 1: Misrouted

12:09:19.213344 P 0:0:1d:cf:2f:fd 0:0:0:0:0:1 ip 60: C.3114 > D.netbios-ssn: S 75025934:75025934(0) win 8192 (DF) (ttl 127, id 33296)

This lost child, at first sight, looks like just an average Windows NetBIOS request. However, this packet wasn't received by the host that should receive it - D - but an innocent by-stander, my own computer. Machines C and D were in different physical network segments, and segment separation was proper. My box wasn't located in any of them. All segments were connected together by Cabletron SmartSwitch router, and its hardware address is the source of this ethernet frame.

My broken tcpdump version replaces all unicast destination addresses with 0:0:0:0:0:1 ("me"), and I really regret I used it to capture this packet. One way or another, I should never see this packet (and few others, including SNMP requests, that arrived to me this day). The key to this mistery, I believe, is the router. I have no clue why it keeps sending packets to incorrect parties on irregular basis, but it happens. A bug like that allows third-parties to capture very interesting data (like, as in this example, SNMP community names, passwords, whatever)...

Note that there's a possiblity that overloaded hub goes dumb "hub mode" and broadcasts everything (which is a stupid thing for switch to do, security-wise) - as pointed by some Slashdot readers. However, this does not explain why this packet is delivered to a machine that does not share the same segment with destination host.

Exhibit 2: lost its head

10:06:19.235208 213.76.114.40.18245 > 212.244.100.102.21536: SE 795438439:795438776(337) ack 794976622 win 12147 urg 28261 <[bad opt]> (DF)

0000: 4500 017d 5d03 4000 7906 22a8 d54c 7228 E..}].@.y."..Lr(
0010: d4f4 6466 4745 5420 2f69 6d67 2f62 616e ..dfGET /img/ban
0020: 6572 2f73 7964 6e65 7932 3030 302e 6a70 er/sydney2000.jp
0030: 6720 4854 5450 2f31 2e31 0d0a 4163 6365 g HTTP/1.1..Acce
0040: 7074 3a20 2a2f 2a0d 0a52 6566 6572 6572 pt: */*..Referer

This little poor thing looks just odd. When you take a closer look, you will see that port numbers and other TCP parameters of this packet are actually... constructed of packet payload! Source port and destination port, two 2-byte values that start every TCP header, are 18245 and 28261 - 0x4745, 0x5420 in network endian order. This translates to ASCII string 'GET ', a beginning of HTTP request. This kid has lost its TCP header, but IP header (with protocol type set to TCP) and TCP payload is still there... We started to see thousands of packets just like this one somewhere in the middle of 2000 coming from many locations in Poland. After some time, we realized they are generated by broken Nortel CVX access servers deployed country-wide by one of biggest Polish ISPs. Firmware was fixed within maybe a month or so, but this priceless packet dump will live forever.

This packet courtesy of smarkacz.

Exhibit 3: espionage

+ TCP 0x14 64.4.14.250:80 -> 193.0.67.34:62990 ttl=1 off=0x0 id=0x7529 tos=0x0 len=40 phys=46

45 00 00 28 75 29 00 00 01 06 F1 86 40 04 0E FA
C1 00 43 22 00 50 F6 0E 00 00 00 00 00 D0 79 FE
50 14 00 00 EB 82 00 00 00 00 00 00 00 00

This packet arrived from www.law10.hotmail.com, one of web servers handling Hotmail traffic, to a valid address in a cyber-cafe during hours of operation. It looks legitimate - ah, just a typical RST|ACK packet. What is interesting is TTL, set to 1. This behavior, observed there and in few other places, might be a result of some problems, but our paranoid minds kept telling us this must be something more. What if, within an established TCP connection, you start sending any of your responses several times, with increasing TTL, starting from something pretty low? Well, just another version of traceroute, you will get ICMP responses from subsequent routers on the way to your targer. 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...

Exhibit 4: line noise

14:03:58.029541 ip_hl < 5 (0)

0000 05b4 0100 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 b4bd 0000 1850 92f1 8318 c231 819b 0b30 8801 a140
5146 19a2 1c74 84e0 450f 8026 91de 176e 8a34 840a 43c4 b882 0814 ae20
de13 2eb8 a023 4161 b890 9709 1b90 d041 07fe 1e24 f1c4 0b32 1234 467a
3a86 2047 0761 1ca8 4213 4288 5107 1499 86a4 655e 2bc4 3142 0603 2481
2414 e9f9 2990 082e b490 ea0a 4234 1146 1872 c8f1 c2ad 63d8 2890 172d
d081 5f18 0166 20c2 61a6 9a5a 2c48 4dac d081 0a19 1c16 4280 7164 0865
4147 3431 df0f 2124 91c2 0f83 ae90 0411 3e88 9144 41c3 8a01 050a 1940
0be8 8d1b be0b 9258 2534 4146 7a72 b800 c513 414e cb03 1d22 30a1 2b13
7190 4186 1061 8810 870a 4924 2610 1147 e8da 440b 7578 616a 13d0 597c
12a0 2db4 502a 127b 3201 4518 4400 9044 1c4f 0841 c617 f845 1b07 7262
7685 2313 a0a5 eac2 614a fafc 3394 4233 4186 d02d 403b 0600 6601 eaaf
17b8 b630 4609 90f5 46a3 a94c 6c9d 9e18 4f9c e535 fe4a 4034 da84 1ce9
c150 ad18 2e00 1046 1164 e415 0610 196c cbc4 1819 a440 c689 b8a6 57ad
c775 c701 5117 7b1b 0404 1423 10db 5094 5044 a9a3 067f 0210 8218 ....

This odd, malformed packet that makes little or no sense was spotted by Lindsay and reported to INCIDENTS mailing list. So far, we have absolutely no clue what could it be - partially damaged data in some protocol, memory dump from faulty router, or just a line noise, something that was a result of random fluctations in the medium and accidentally passed all checks on its way there?

Exhibit 5: growing!

At the source:

11:47:16.797885 riget.scene.pl.2487 > 62.233.130.254.ssh: S 624278517:624278517(0) win 32768 (DF)

4500 002c 114d 4000 4006 1fd7 d4b6 730a 3ee9 82fe 09b7
0016 2535 bbf5 0000 0000 6002 8000 2486 0000 0204 05b4

Second hop (2 extra bytes):

10:04:30.154502 riget.scene.pl.2487 > 62.233.130.254.ssh: S 624278517:624278517(0) win 32768 (DF)

4500 002c 114d 4000 4006 1fd7 d4b6 730a 3ee9 82fe 09b7
0016 2535 bbf5 0000 0000 6002 8000 2486 0000 0204 05b4
0000

Destination host (20 extra bytes):

11:46:54.386596 riget.scene.pl.2487 > 62.233.130.254.ssh: S 624278517:624278517(0) win 32768 (DF)

4500 002c 114d 4000 3806 27d7 d4b6 730a 3ee9 82fe 09b7
0016 2535 bbf5 0000 0000 6002 8000 2486 0000 0204 05b4
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

This is a history of SSH connection packet, gaining extra zeroed bytes at the end while passing apparently buggy FreeBSD routers. Apparently, for specific IP parameters (this does not happen in all cases), packets are forwarded with some overhead. Because packet length specified in the header is not modified, packet is not perceived by other hosts as being corrupted.

This one comes from Przemyslaw Frasunek.

Exhibit 6: shift

23:22:14.941266 ff:ff:ff:ff:0:90 2:0:0:0:ff:ff 27a3 102:

f100 0800 4500 0054 747f 0000 ff01 1c16 0a0a 0b01 0a0a 0bff 0800
5654 7616 3600 86fb bb39 ba5c 0e00 0809 0a0b 0c0d 0e0f 1011 1213
1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d
2e2f 3031

This is pretty funny. Due to a hardware failure, this packet was, erm, shifted (some data appended at the beginning of ethernet frame). Hardware addresses are not extactly correct, and IP header is prefixed with four bytes (f1 00 08 00). It was reported to happen for broadcasts only (!) and was fixed by replacing one cable.

This is another one Przemyslaw Frasunek.

"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." -- rsimmons@spamcop.net, Slashdot reader