TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to [EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems! ---------------------------------------------------------------------------- Hi, Does anybody have much experience of the TCP overlapping data alert? As far as I can tell this alert could occur during "normal" but busy operation, ie is not caused purely by malicious attacks or faulty equipment? I imagine it could occur when a sending host has to resend an earlier segment because the receiving host has not acknowledged it. One issue with IDS generally, and overlapping data in particular, is that network IDS analysers should (ideally) try to analyse data streams based on how the two participants of the session would process them - ie whether or not to process packets with bad checksums, bad flags, bad options, overlapping data etc. The following talks about overlapping segments, NOT fragments, although some of the issues are similar. I found a report on the web which suggested that NT always aims to process the "original data" it received, whereas some other operating systems always process the "latest data". I took a look at some Unix source code on the web and found that that particular system seemed to do BOTH (when receiving a segment containing some new data that overlaps a preceding segment, it drops the overlapping data from the incoming segment, but if it overlaps succeeding segments then it will trim those and keep the overlapping data from the incoming segment). Of course, even if Realsecure imitated the target operating system precisely (pretty difficult when there's a mix of target operating systems!) it can't be sure whether the target OS actually received the segments anyway. Anyhow would anybody know what kind of approach RealSecure takes? I had thought of doing "log with raw" or "view session" but I don't know how those components would work. For example if a hacker sent a malicious segment then overwrote it with a normal one, because they assume that the target OS would stick with the first, then RealSecure would only issue the "overlapping data" event for the second segment (containing the normal data) so any "log with raw" or "view session" would capture harmless stuff. Plus i've not tried to see whether "log with raw" or "view session" then carry on to capture the rest of the session, or just the dodgy segment. Does anybody have any bits of advice for using those features (logwithraw & viewsession)? If the above was to happen then hopefully RealSecure will spot the first malicious segment above anyway, unless it's built from many small carefully crafted overlapping segments and RealSecure always takes the latest data when filling its buffer prior to processing. Finally I think (hope) we're just seeing the result of TCP retransmissions and I suspect the only real way forward is to capture some of them on a network sniffer (although i'm not sure there's an easy trigger I could set to capture them). Any thoughts would be much appreciated, either on the theoretical / technical side or just on whether the majority of TCP overlapping data seen in the wild are false-positives or malicious. Cheers, James Email: [EMAIL PROTECTED] ===================================================================== Disclaimer! All views are my own. I accept no responsibility for any death, injury, damage, loss (financial or otherwise) or inconvenience - whether caused directly or indirectly - resulting from the use of information given or implied. =====================================================================
