TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to [EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems! ----------------------------------------------------------------------------
Fiona, I've seen them in the past too, with no evidence of malfunctioning equipment, and determined (based on my knowledge of the environment) that it was not hostile activity. I did conduct some experiments, crafting my own packets to determine when Real Secure would trip and when it wouldn't (the thing with IDS and overlapping data is that, ideally, the IDS system should know how the TARGET server will handle the overlapping data; it gets awfully messy with sequence numbers and receive windows and new data being compared to existing chained segments which it may partially or totally overlap - i believe somebody once wrote an excellent paper comparing how different operating-systems handled overlapping data). I've forgotten the results of my testing now, but I remember resending both changed and unchanged overlapping data. I can't remember - does RealSecure supply any information? For example, the overwritten data AND/OR the overwriting data? There are some devices you can buy which will record ALL network traffic for extended periods of time (custom build using striped SCSI disks and capable of handling several hunder Mbps) which would be useful to investigate these kinds of alerts, else they're pretty difficult after the event. I've attached something below from last year's forum. Sorry i can't be of any more help - i'd be really interested in other people who've had false positives in this area and determined their cause. Jason >For example if a receiver does ackno a1 window size r1, >and the sender sends packet p1 seqno s1 length l1, >followed by packet p2 seqno s2 length l2, >where >s1=a1 (ie next expected data) >s2=s1+l1 (ie next segment) >s2+l2<=r1 (ie within window) > > >Now if RealSecure sees the above it will assume the next seqno of the >sender should be s2+l2, however if the receiver doesn't get the packet >(TCP's not reliable so this could happen due to "normal" congestion) >then the sender will retransmit depending on the last ack it received. > > >This means it could retransmit packet p3 seqno s1 length l1+l2, >ie deciding to bunch both segments together this time. In this >particular case p3 won't look like p1 or p2. > > >Which brings up the interesting point of how RealSecure differentiates >between retransmitted segments and overlapping data? I'd hope it >wasn't by packet id (and indeed i don't think it is) because attackers >could use the same packet id in subsequent attacks. It could be by >seqno and length, but likewise a hacker could duplicate that. It could >maintain the checksum of the last transmitted packet and use that to >spot changes but that could get complicated (and really smart hackers >could potentially resend overlapping data crafted to match the >checksum of the previous packet). > > >So.. could somebody confirm whether it is possible to get >false-positive TCP overlapping data due to network congestion? > > >And could somebody explain how RealSecure differentiates between >retransmitted segments and other forms of overlapping data? > > >Yours, puzzled, > > >Jason > > >On Wed, 13 Jun 2001 11:50:58 -0700, you wrote: > > >> >>TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to >>[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems! >>---------------------------------------------------------------------------- >> >>TCP Overlap Data - Data in TCP connections is broken into packet-sized >>segments for transmission. The target host must reassemble these segments >>into a contiguous stream to deliver it to an application. The TCP/IP >>specifications are not clear on what should happen if segments representing >>interpret such data. This type of traffic should never happen naturally on >>a network. By deliberately constructing connections with overlapping but >>different data in them, attackers can attempt to cause an intrusion >>detection system or other network monitoring tool to misinterpret the >>intent of the connection. This can be used to deliberately induce false >>positives or false negatives in a monitoring tool. Intruders may utilize >>IP spoofing and sequence number guessing to intercept a user's connections >>and inject their own data into the connection. If successful, the intruder >>can gain control of a system. In some cases, Real Secure should be >>triggered if the TCP data has changed within some set number of >>frames. However, some recent TCP implementations of Windows 2000 and some >>Unix implementations that send "status" information after a RESET within >>the data part of the frame which will then result in a false positive being >>reported. >> >>thanks to Rob G and Peter K of NI for educating me about TCP Overlap over >>and over again.. >>
