I am getting thousands of TCP segment overwrite events (ID: 1300) directed at our MS SQL Server from numerous clients. Is this a bug in the MS SQL implementation that could cause false positives? Is there a known exploit that would be causing this?
We have investigated the packet traces we have from the other customer. It appears there might be a problem with a microsoft stack. The trace we have shows an IE browser hitting an IIS server. There is a legit overwrite of one byte that the IDS is correctly identifying. The traffic we have also does not appear to be an attack. It looks more like a broken TCP stack. The TCP session seems to hang and eventually RST are sent to close it. We are trying to reproduce this in our lab so that we can notify our customers as well as let Microsoft know. If you can provide details on OS type and patch level of both the client and server it would help.
At this point I would say that the alarm is not a false positive, however in the case we have seen it is identifying a broken stack and not a new attack tool.
The client that is causing most of the alarms is a Win2K machine with SP2. The server is a Win2K system with SP3a running SQL server. I have done a packet capture that should include one of the events. How would be the best way to send it to you if you still want it?
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...