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?
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 firstname.lastname@example.org
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.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...