* museum of broken packets *

Brought to you by Michal Zalewski.

Hey, you! Yes, you. This page is about 10 years old and is kept here purely out of sentiment. There's probably a lot of better reading material here.


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 the twisted paths of our grand journey called life. Our exhibits - or, if 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 a broken IP stack implementation. Others were normal packets, just like all their friends, you or me, 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 find the 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 an 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 :)


Last modified: Sep 21, 2003



Exhibit 1: Misrouted

[SOLVED AND FOUND TO BE SILLY - REMOVED]



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 what should be the 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 a HTTP request. This kid has lost its TCP header, but IP header (with protocol type set to TCP) and TCP payload are 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 that all were generated by a badly broken Nortel CVX access servers deployed country-wide by the Polish Telecom. Firmware was fixed within a month or so, but this priceless packet dump will live forever.

This packet a 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 its 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 fairly uncommon routing problems, but our paranoid minds kept telling us this must be something more. What if, within an established TCP connection, you started sending any of your responses several times, with increasing TTL, starting from something pretty low? Well, you get just another version of traceroute, and should receive ICMP responses from subsequent routers on the way to your target. But unlike the traditional, "standalone" version, this embedded traceroute that lives within a legitimate session established by the customer, will cut thru almost every stateful firewall and address translation, allowing you to obtain a valuable information about their internal network structure, depth, target distance and such. All this without risking being detected, really. Well done, packet! You 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 a 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 from Przemyslaw Frasunek.



Exhibit 7: DoS tool changes into DoS exploit

Internet Protocol Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 48
Identification: 0x6fbb
Flags: 0x04 (DF)
Fragment offset: 0
Time to live: 127
Protocol: TCP (0x06)
Header checksum: 0x63b6 (correct)
Source: 64.190.25.48 (64.190.25.48)
Destination: XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX)

Transmission Control Protocol, Src Port: 1113 (1113), Dst Port: 490 (490), Seq: 269484601, Ack: 0
Source port: 1113 (1113)
Destination port: 490 (490)
Sequence number: 269484601
Header length: 28 bytes
Flags: 0x0002 (SYN)
Window size: 16384
Checksum: 0x023b (correct)
Options: (8 bytes)

Maximum segment size: 1460 bytes
NOP
Maximum segment size (option length = 4 bytes says option goes past end of options)

0000 XX XX XX XX XX XX XX XX XX XX XX XX 08 00 45 00 ..............E.
0010 00 30 6f bb 40 00 7f 06 63 b6 40 be 19 30 XX XX .0o.@...c.@.....
0020 XX XX 04 59 01 ea 10 10 02 39 00 00 00 00 70 02 ...Y.....9....p.
0030 40 00 02 3b 00 00 02 04 05 b4 01 02 04 03 .. .. @..;............

This one comes from Andy Brown, who "does security" for a large web portal. It is a nice example of how simple error in DoS tool turned it into potential DoS exploit, and that conspiration theory is not always the best answer :). The packet you see above is generated by a DoS SYN tool called Juno-z. This tool was used against their site. As Andy describes, the fun is in the TCP options: 0x020405B4 MSS=1460, 0x01020403 NOP, MSS=0x03??

Normally the NOP option (0x01) is used to pad options so they lie on 4-byte boundaries, causing the actual MSS value to lie conveniently on a 16-bit boundary. Here, it's not - this NOP causes MSS value to end past the end of this packet. Might cause some dumb stack to have a bus/alignment fetch error because the MSS is shifted. Also, it could cause a dumb stack to read past the end of the packet causing a segmentation fault. Turns out, this was all unintentional - I talked to the author, and it was a coding glitch :-)



Exhibit 8: forgetful

01:00:11.800399 truncated-tcp 0 (DF)
0000: 4500 0014 5832 4000 6c06 afea d8d3 1644 E...X2@.l.-eO/.D
0010: 4428 d387 0000 0000 0000 0000 0000 0000 D(..............
0020: 0000 0000 0000 0000 0000 0000 0000 .... .................

01:00:12.646873 truncated-tcp 0 (DF)
0000: 4500 0014 5b32 4000 6c06 acea d8d3 1644 E...[2@.l..eO/.D
0010: 4428 d387 0000 0000 0000 0000 0000 0000 D(..............
0020: 0000 0000 0000 0000 0000 0000 0000 .... .................

This one comes from Michael Anuzis. These two packets arrived to his webserver some time ago. Both of them originated from a Windows machine providing public access for Ontario residents (operated by The City of Thunder Bay). Both packets seem to be "trunacted" right after the IP header, so TCP data is completely blank (thus making it look like a packet from port 0 to port 0). Declared total length is 20 bytes (IP header alone), but more data was received (26 extra bytes). Two packets are almost the same, but have different ID fields (5832 and 5b32) - second one is slightly higher. This may suggest that this packet was not forged but sent by the actual IP stack implementation. It is really difficult to consider them any sort of probing, DoS attack, etc... Did this box forget to fill out some of the data before sending it?

Two minutes after receiving this traffic, Michael received a packet identified by snort as "stealth scanning" from the same source IP. While he does not have detailed logs from this incident, it looks like this snort sensor was actually triggered by one packet, unfortunately not logged, not a real, massive scan. So maybe some clever hackers? Your suggestions are welcome - this case is open!



Exhibit 9: E.T. phone home

13:41:22.104160 aa:aa:aa:aa:aa:aa 1:a0:f8:f0:f0:2 8781 109:
002d 0800 0057 0000 0005 0007 0000 0001
XXXX XXXX ffff ffff 0001 0000 0000 0601
0300 0000 0000 0000 3130 3100 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 2c2d 2e2f 000a 3031
2e35 302d 3130 006d 541b 5b30 6d79 01..

This very interesting packet comes from Slawomir Krawczyk. What you see here? aa:aa:aa:aa:aa:aa belongs to a wireless base station 3Com Air Connect. Its IP appears later in the packet as XXXX XXXX. 1:a0:f8:f0:f0:2 is a multicast address assigned to SYMBOL TECHNOLOGIES, INC., the manufacturer of Prism chipset used in this 3Com station. Inside the packet, immediately following the source IP, you see 'ffff ffff', which seems to be a broadcast IP address. But this is where the obvious ends. What is the ethernet type 8781? Why is the chipset apparently calling other similar devices in the local network over this protocol? What is the format of data transmitted?

This might turn out to be trivial, but we simply have some doubt as to what exactly is going on, so your suggestions are welcome.



Exhibit 10: Strange things happen when hosts get lonely

Ethernet II
Destination: 00:80:5a:14:93:99 (00:80:5a:14:93:99)
Source: 00:00:81:a1:c5:68 (00:00:81:a1:c5:68)
Type: IP (0x0800)

Internet Protocol
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default)
Total Length: 44
Identification: 0x8dfc
Flags: 0x00 (no DF, no MF)
Fragment offset: 0
Time to live: 255
Protocol: TCP (0x06)
Header checksum: 0xee38 (correct)
Source: 255.255.255.255 (255.255.255.255)
Destination: amb3 (128.141.27.9)

Transmission Control Protocol, Src Port: telnet (23), Dst Port: 43006 (43006), Seq: 176289405, Ack: 43007
Header length: 24 bytes
Flags: 0x0012 (SYN, ACK)
Window size: 512
Checksum: 0x056c
Options: (4 bytes):
Maximum segment size: 1460 bytes


0080 5a14 9399 0000 81a1 c568 0800 4500 ..Z........h..E.
002c 8dfc 0000 ff06 ee38 ffff ffff 808d .,.......8......
1b09 0017 a7fe 0a81 f67d 0000 a7ff 6012 .........}....`.
0200 056c 0000 0204 05b4 4145 .... .... ...l......AE....

This is, by far, one of most weird cases. The capture is contributed by Christophe Pernod. What you are seeing is a strange SYN|ACK packet from port telnet on a broadcast address (but a unicast hardware address corresponding to 128.141.27.253, a box Christophe identified as as Alteon AceSwitch 110 4.0.37) to port 43006 of his machine, 128.141.27.9. All this happening on an internal network. The type of this device is also confirmed by the MAC address class resolving to "SynOptics Communications switch, HUB". Christophe kept seeing those packets in short time intervals for the entire day, then the traffic suddenly stopped, and the device would not answer connections on port 23 (telnet).

I don't think there should be any doubt the packet actually originates from the switch device - look at the ACK number of the packet, it is just dst_port+1, such a brain-damaged algorithm is very common for embedded devices and usually not to be found anywhere else. The packet had originated locally, look at it TTL... plus, as we know, the device eventually decided to quit, so there seem to be a clear connection.

Sense makes it not. First, why the packet was sent at all? I doubt it's been "made up" by the switch, the sequence number looks to be pretty random, the packet does not seem to be random. It is probably safe to assume this is a response triggered by a regular SYN packet to the telnet port.

But why is the source IP a broadcast? My guess is that someone had sent a legitimate SYN packet to a broadcast address of the network - perhaps quite accidentally, for example while scanning the network with a too broad specification. The device's IP stack converted the network's broadcast address to 255.255.255.255, which is a common practice. The TCP/IP stack decided to handle it as usual. It generated a SYN|ACK packet and swapped source and destination addresses, as it had to be done, made up some weak ACK number, and sent it back with its unicast hardware address to the declared sender, 128.141.27.9, with the source address of 255.255.255.255.

The theory, however, does not seem to be complete. Why would another host sent a SYN packet to port 23 (telnet) to the broadcast address, can be explained - a typo, a faulty application, a scanner. Even a broken network configuration on the switch could contribute to that, interpreting some unicast address as a broadcast. But why would it use a source address of 128.141.27.9? Christophe offered a potential explanation - he scanned the the box a day before. If you look at the source port - 43006 - way too high for local port range on a typical unix, but in the range nmap uses for stealth scans - well, makes sense. So, in theory, the response could have been triggered by a legitimate traffic from this host. But there's a catch - he does not recall scanning the entire network, and he says he's usually working on a host-by-host basis. Also, why would the device generate the traffic for the next day, then stop suddenly?

The possible explanation is that the device had a buggy TCP/IP implementation and would not time-out. This is silly, but not impossible. There is a problem, however. It would be getting RST responses, and it's quite difficult to imagine the device would keep ignoring them and still do not remove the connection. And even then, it is difficult to understand why would it stop and crash after a day - there's no growing queue or such, just a single entry that was a result of the scan, and some SYN|ACK retransmits every few minutes.

The theory, while based on some assumptions that are not necessarily true, is still incomplete. Such a bug, while possible, sounds awkward, and we can't be sure that is exactly what happened. I will stay in touch with Christophe and see if he can find some time to reproduce the problem by re-launching the scan, and in the meantime, your theories are welcome.



Exhibit 11: quux frob?

[9:34:10|77]BHF-SW-ENTRY.MIT.EDU.32120 > 34.148.80.24.10930 S (ttl 4,len 49320,id 4608,tos 200,ack:0)win 4945,chks:46276

[9:34:51|7/7]29.192.0.2.32120 > 34.148.80.24.39669 A+R (ttl 4,len 49320,id 4608,tos 200,ack:1)win 58995,chks: 48454

[9:35:8|7/7]29.192.0.2.32120 > 34.148.80.24.39669 F (ttl 4,len 49320,id 4608,tos 200,ack:1)win 58995,chks: 48454

[9:35:38|7/7]35.116.0.2.32120 > 34.148.80.25.12961 S (ttl 4,len 49320,id 4608,tos 200,ack:0)win 21331,chks: 40780

[9:36:13|7/7]40.49.0.2.32120 > 34.149.80.16.29206 F (ttl 4,len 49320,id 4608,tos 200,ack:1)win 8760,chks: 52566

...

[00:00:08|7/7]247.75.0.10.2 > gsb04-0-1.gw.ualberta.ca.3 S (ttl 4,len 49320,id 3584,tos 1,ack:0)win 29801,chks: 28526,DATA:
atage-nordIQ}wwwvibrationalismQ}wwwwesterroenfeldQ}wwwwgs-electronicIQ }wwwbartels-wohnbauIQ}wwwcambium-hamburgIQ}wwwpointimmobilienIQ}wwwpro bsteier-boteIQ}wwwrestaurant-nixeIQ}wwwalfred-haeusslerIQ}wwwcellpap-t ruckingIQ}wwwkh-nordfrieslandIQ}wwwksh-eckernfoerdeIQ}wwwmultimediacam pusIQ}wwwvibrationalismusQ}wwwfrank-yachthandelIQ}wwwimmobilien-centro IQ}wwwinteraktiv-werbungIQ}wwwwassersportwerbungIQ}wwwwassersportundre isenIQ}wwwberufsakademie-wak-shIQ}"wwwtherapiezentrum-westerheideIQ}di fhshonlineIQ}www1lasersoftIQ}www1Q}www3netuseIQ}wwwaltsuperbuplusIQ}2v ierundzwanzig-siebencomvierundzwanzig-siebenQ}secondaryscznIQ}ns1jQ}

This traffic is a courtesy of Pawel Stochlinski. His system is a lone host attached to the network via PPP (over Ericsson HIS terminal), not hooked up to any local network, running a reputable operating system, and hardly used for any purpose. One day, quite mysteriously, he started noticing packets like the ones above - by all means valid TCP packets, SYNs, FINs or such in some reasonable sequences - but from a quite surprising source and to a completely unexpected destination (definitely not on his network). They have valid checksums, different IDs, ports, etc - but all are of the same size - 49320 bytes. Quite unusual indeed.

The payload, a part of which is quoted above, is by all means just as perplexing as the packet itself. What is it? A zone transfer? Looks like a part of a zone transfer for .de domain (no dots or other printable separators between segments looks very much like DNS traffic format) - but zone transfers of .de are prohibited. So... it could be that an authorized name server, perhaps one of the secondary nameservers for .de, asked for a transfer, and the response somehow got mangled and sent to this guy? But how? Is this an awkward conjunction of a nasty hiccup with packet routing here and with the DNS server there? Or...?



Exhibit 12: Protocol madness

[SOLVED AND FOUND TO BE NOTHING SPECIAL - REMOVED]



Exhibit 13: Leaky windows

210.14.22.68:3368 - Windows XP (2)
Signature: [16384:110:1:48:M1460,N,N,S:U:Windows:?] -> 217.8.32.51:80 (distance 18, link: ethernet/modem)
-- EXTRA TCP VALUES: ACK=0x0, UNUSED=0, URG=0x5071

217.11.16.114:2692 - Windows XP (1)
Signature: [S6:110:1:48:M1460,N,N,S:U:Windows:?] -> 217.8.32.51:135 (distance 18, link: ethernet/modem)
-- EXTRA TCP VALUES: ACK=0x0, UNUSED=0, URG=0x401>

This is a very interesting case. While writing my passive OS fingerprinting utility, p0f, I was trying to come up with a number of checks that would detect systems with strange packet characteristics. My intention was to cover all bases, just in case, even if something is not likely to happen. One of the things I looked at were non-zero URG pointer values in TCP/IP SYN packets. For all packets that do not have URG flag set, this value in TCP header should be disregarded, according to the RFC, and it usually is. Most sane systems set it to 0. Some other boxes use fixed values such as 0xcccc.

And then I stumbled upon a minority but noticable population of Windows XP and 2000 systems that exhibited this strange property - had URG pointer set to a non-zero, seemingly random value. Very elusive creatures indeed, I spent weeks and weeks trying to hunt them down. Whenever I thought I got a box like this, it immediately started behaving the way it should. I was sure it is a random memory leak - the value is simply not cleared after sending or receiving some other traffic.

And then it happened. Just as I pretty much gave up, I found out what the problem was. As it turned out, almost all Windows boxes (including most up-to-date versions) were affected, but the problem appeared only when a simultaneous transfer was occuring when sending this SYN (or RST, for that matter) packet. In other words, browsing the web, downloading ware^H^H^H^Hyour mail or any other activity like this resulted in URG being set. Oh well, you are getting two bytes of someone else's stuff as a bonus.

More details here. All hail Microsoft!



Exhibit 14: Web too fast

62.101.126.232:41785 - UNKNOWN [57920:46:1:220:N,N,T:ATD:?:?] (dropped) (up: 27 hrs) -> X:80 (link: unspecified)
[00] 45 00 05 dc 04 47 40 00 2e 06 8c 45 3e 65 7e e8
[10] d9 08 20 3a a3 39 00 50 d0 db e1 aa d9 c9 be f2
[20] 80 04 e2 40 bd 61 00 00 01 01 08 0a 00 96 cc 27
[30] 00 75 83 04 a0 a0 e5 6c 0d 28 89 7c bb a1 a7 3b
[40] 0c 50 18 b8 50 94 30 13 07 1b 3b a8 b2 c4 9f ff
[50] cc 21 16 b0 f9 68 0b 78 7e 0d c0 68 fc bf d9 48
[60] cf 57 e1 9c 33 3e 30 18 b8 85 5f d4 51 96 b6 88
[70] 4c 83 95 c9 11 df 40 c4 87 d5 33 8f 16 f9 06 78
[80] 27 2e 48 27 03 e0 9f c3 27 af 29 7d 22 b9 fc 40
[90] 52 79 48 39 b4 88 c1 c6 97 05 72 e7 26 71 ce 3e
[a0] b4 dc 2b 83 67 80 b1 ae 83 4f 08 c5 17 73 9b 6e
[b0] 6b 90 ca b6 f3 1d 21 01 fe 1e 52 73 04 97 cd 7d
[c0] 18 d5 d2 8b d0 e9 ae c8 5d e8 4c e7 bb 05 20 c9
[d0] 3c 36 23 48 42 86 68 4f df af 6c 88 a0 06 0a d6
[e0] 2f 05 21 09 31 ca .. .. .. .. .. .. .. .. .. ..

RST packets are not supposed to carry data payload, except for an optional human-readable description of what was the reason for dropping this connection. But this packet is different, and so is a number of other RST packets arriving from 62.101.126/24 (fastweb.it residential customer network), all spotted while trying to add RST fingerprinting to p0f. Packets arrive from a number of different OSes, but always carry a sizable payload, a total size of 220 or 140 bytes. The payload looks like random data, but is a part of the data just exchanged between two endpoints (the user was downloading a compressed file, which I managed to locate on the webserver).

I have tried contacting FastWeb folks asking them what devilish devices they use for NAT or firewalling for their customers, but I'm yet to hear from them... any suggestions?:-)



Exhibit 15: Reset HTML

216.250.217.216:45467 - UNKNOWN [0:31:0:82:N,N,T:TD:?:?] (dropped) (up: 27 hrs) -> 217.8.32.51:80 (link: unspecified)
[00] 45 00 00 52 2b d6 00 00 1f 06 c3 c1 d8 fa d9 d8
[10] d9 08 20 33 b1 9b 00 50 6c 76 5f f9 00 00 00 00
[20] 80 04 00 00 e5 29 00 00 01 01 08 0a 00 98 f0 19
[30] 00 00 b0 15 31 32 20 0d 0a 2e 0a 3c 2f 62 6f 64
[40] 79 3e 0a 3c 2f 68 74 6d 6c 3e 0a 0d 0a 30 0d 0a
[50] 0d 0a .. .. .. .. .. .. .. .. .. .. .. .. .. ..

And yet another RST marvel, courtesy of p0f, of course. What is really interesting is the payload of this RST, believed to originate from Windows NT 4.0 SP6a (although I wouldn't bet too much on it). As mentioned previously, RST packets are not supposed to carry any data, other than perhaps a brief description of why they're being sent. So, the funny part - this packet's payload:

12
.
</body>
</html>

0

I have received a number of those, actually. Makes me think about the marvels of TCP/IP engineering at our friendly giant, Microsoft.


"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


- best viewed with html browser -
54.80.12.147, you are a visitior number 10471526.