TCP Hijack - 3250

[bfl1]

How does the TCP hijack signature work? Does it notice an ACK storm? Does it pick up on 2 devices that seem to get their sequence numbers all out of whack, as the hijacker picks up on the sequence number and starts spoofing the original source?

I'm curious, because I see this triggered on a secure area of the network where I know a session hijack is not probable.

Thanks

[gfullage]

3250 will fire if the ratio of data-less ACK packets to data-full ACK packets within a TCP stream hits a certain ratio, I think it's something like 10-1 ratio. I think v3 only looked at Telnet, RSH and rlogin sessions, ports 23, 512 and 513 respectively, but v4 looks at any port as it all comes under the TCP stream reassembly functions.

A common misfire of this is caused by idle Telnet sessions, where the TCP Keepalives (data-less ACK packets) far outnumber the data-full ACK packets.

[darin.marais]

In our network this signature is triggered a lot when the destination is a proxy server> I am fairly convinced that these are not hijacked sessions.

Is there a way to tune out these events when the destination is TCP_80?

[gfullage]

The easiest way would be to simply add a filter, you can get very specific and filter out sig=3250 AND dest IP addr=.

This signature is handled by the OTHER engine which cannot be modified via IDS MC. It can be modified via IDS Device Manager by directly HTTPS'ing to the sensor, but even then you can't say "don't look at port 80", since as I mentioned, the V4 sig looks at all ports.