UPDATE
A number of readers have submitted packets which allowed us to correlate some information. John has also been able to provide some additional information.

According to RFC 731 "TCP MUST be prepared to handle an illegal option length (e.g., zero) without crashing; a suggested procedure is to reset the connection and log the reason." we have to keep this in mind when looking at the rest of the information available.

Typically this is what we see:
       Source:http > target1:1205 Syn, ACK
       target1:1205 > source:http RST,ACK xxxxxxxxxx
        (ACK is not always evident and where xxxxxxx are changing parameters, depending on the stack)

Generally the source ports are 80, 6667, 6666, and 443. However there are also a number of packets with random source ports between 1024 and about 1300. Ports 1024-1300 are also used as the target port. Looking at the Dshield data for ports 6666 and 6667 there was a small peak for these ports as source ports on the 27/28 Feb.

So we are seeing multiple hosts sending SYN,ACK with truncated option to targets (sometimes both scan the same IP) from known ports. The response is typically a RST, or RST,ACK. The window size is also often changed in the response.

What it looks like is a mapping/fingerprinting exercise using the target stacks' response to bad options. But at this stage the end goal is unclear. We have a few theories on the boil, but to confirm we'll need more info. If you have packets let us know, we are currently especially interested in the RST responses.

MH

---

We had a reader named John who sent us an email about some unusual traffic they are seeing.  I'm curious if this is isolated or widespread.  Here is a copy of his email for what they are seeing and an example of  5 packets all destined for different hosts.  If you are seeing this, please let us know and if you can send us a packet capture of the traffic.   Thanks!!

Over the past few weeks we have seen an increase in the number of snort alerts we have been receiving for "Truncated TCP options." Looking at the packets, they appear to be crafted. At first it was one host scanning one of our /16 blocks, then it was another a week later, then one more a couple days later and then a couple every day. some of the times these scans are sourced from random ports, but some times they are sourced from common ports like 80, 443 and 6667. They have come across as syn packets, ack packets (for which there was no initiating syns), or syn/acks (again there were no initiating syns). The destination ports are always within the lowest ephemeral ports (1024-1300), and there is no consistency in the OS of the hosts that do respond. Because so few host do respond to these packets, I believe that one of the objectives of this scan may be to probe firewall configurations (we have a standing policy requiring host based firewalls), but it seems the level of crafting involved would be overkill.

When looking at some of the packets what we see is that the tcp option for mss is called twice, with the second one running past the end of the packet. When I counted the headers based upon the data in the IP and TCP header fields, it appears these packets are the correct length.

07:11:45.781421 IP (tos 0x0, ttl 113, id 9433, offset 0, flags [DF], proto: TCP (6), length: 48) 129.250.128.21.1256 > www.xxx.yyy.zzz.1229: S, cksum 0x5ed4 (correct), 2627126762:2627126762(0) ack 257795
6091 win 1460 <mss 1460,nop,[bad opt]>

0x0000: 4500 0030 24d9 4000 7106 4944 81fa 8015 E..0$.@.q.ID....
0x0010: wwxx XXYY 04e8 04cd 9c96 c5ea 99a8 7cfb ...{..........|.
0x0020: 7012 05b4 5ed4 0000 0204 05b4 0102 0403 p...^...........


07:11:51.517325 IP (tos 0x0, ttl 113, id 21659, offset 0, flags [DF], proto: TCP (6), length: 48) 129.250.128.21.1252 > www.xxx.yyy.zzz.1070: S, cksum 0xa40c (correct), 1381904945:1381904945(0) ack 2301
854615 win 1460 <mss 1460,nop,[bad opt]>

0x0000: 4500 0030 549b 4000 7106 764c 81fa 8015 E..0T.@.q.vL....
0x0010: wwxx XXYY 04e4 042e 525e 3231 8933 8397 ........R^21.3..
0x0020: 7012 05b4 a40c 0000 0204 05b4 0102 0403 p...............


07:12:06.816985 IP (tos 0x0, ttl 113, id 5274, offset 0, flags [DF], proto: TCP (6), length: 48) 129.250.128.21.1054 > www.xxx.yyy.zzz.1132: S, cksum 0x90a5 (correct), 404326101:404326101(0) ack 122769195
4 win 1460 <mss 1460,nop,[bad opt]>

0x0000: 4500 0030 149a 4000 7106 10d2 81fa 8015 E..0..@.q.......
0x0010: wwxx XXYY 041e 046c 1819 86d5 492d 17b2 ..b,...l....I-..
0x0020: 7012 05b4 90a5 0000 0204 05b4 0102 0403 p...............


07:12:12.670863 IP (tos 0x0, ttl 113, id 38039, offset 0, flags [DF], proto: TCP (6), length: 48) 129.250.128.21.1088 > www.xxx.yyy.zzz.1204: S, cksum 0x0701 (correct), 269829739:269829739(0) ack 3374363
152 win 1460 <mss 1460,nop,[bad opt]>

0x0000: 4500 0030 9497 4000 7106 d97d 81fa 8015 E..0..@.q..}....
0x0010: wwxx XXYY 0440 04b4 1015 466b c920 b210 .....@....Fk....
0x0020: 7012 05b4 0701 0000 0204 05b4 0102 0403 p...............


07:12:22.675579 IP (tos 0x0, ttl 113, id 29721, offset 0, flags [DF], proto: TCP (6), length: 48) 129.250.128.21.1033 > www.xxx.yyy.zzz.1067: S, cksum 0x2919 (correct), 1872427362:1872427362(0) ack 69068
0305 win 1460 <mss 1460,nop,[bad opt]>

0x0000: 4500 0030 7419 4000 7106 cdbb 81fa 8015 E..0t.@.q.......
0x0010: wwxx XXYY 0409 042b 6f9a f962 292a f1f1 ..E....+o..b)*..
0x0020: 7012 05b4 2919 0000 0204 05b4 0102 0403 p...)...........