TCP Segment Overwrite Events

[dblairii]

I am stumped on the cause of TCP Segment Overwrite (sig1300) events that I am seeing on multiple sensors from 3 different servers (to the tune of about 4000 events per day per server). The source port on these events are random, but the destination port is always 1433 (SQL?). I am aware of cold fusion 5 running on these particular servers, and think that this is probably the culprit.

Have any of you seen a similar/identical false positive? Did you just filter by source? What is the exact cause?

Thanks,

Don

[mlhall]

There is a bug in quite a few microsoft stacks. It sends a 0xff to overwrite the last byte in the flow. We have notified microsoft of this and plan to put in a work around in the IDS sensor code to detect the MS stack vs. a different type of overwrite. Microsoft stacks are overlapping and overwriting the flow. If you would like more details contact me at mlhall@cisco.com

[mlhall]

After further investigation I have found that there is an older implementation of TCP keepalives dating back to BSD 4.2 days where the keepalive does hold garbage data. Microsoft's stack was based on some of this older BSD code and therefore shows this behavior. So we have concluded that there is no stack bug in Microsoft's TCP stack. They are just doing something that most stacks do not.

We now know the problem and I will be committing a fix for v4.1.4 of the IDS. It will safely ignore an overwrite if it is a single byte one byte back in the sequence and both ends of the TCP connection have already ack'ed the byte.

Sorry for the delay in solving this problem for you all. If you have lowered the sev or filtered 1300 I would recommend setting your filters and severity back to default after upgrading to v4.1.4.