Under Cisco IDS version 3.x, SigID 3250 only looked at few ports (TCP 21, 23, 513 and 514 if I recall correctly).
With the introduction of version 4.x, the signature was no longer limited to these ports. As a result, at least here, we've been seeing a lot of "false positives" involving proxied web traffic and NetBIOS traffic. BTW, I have no idea if the signature has been re-coupled to ports under version 5.x (anyone?).
The logic we apply to any SigID 3250 alarm we see here is based on two factors: intent and feasibility.
While it is theoretically possible to hijack most session-oriented TCP connections between a client and server, there are some that just make no sense.
If you take alarms involving TCP port 80, what would be the point to hijack someone's connection to a web server? Anything sensitive that someone might do using a browser will be done via HTTPS (aka SSL/TLS), so the crypto will eliminate the hijack threat there. So now you’re left with unsecured web access; what are you most likely to find if you do hijack this? Someone looking at Dilbert comics, or some such I imagine... I think you can agree that, as a result, there is no “intent” at all.
As with any hijack attack, the feasibility is quite low. Most of these attacks require that the hijacker be in the same broadcast domain as the intended victim. Given this, it stands to reason that if you aren’t also seeing ARP cache poisoning attacks or TCP Syn flooding (or some other DoS attack against the victim), you aren’t seeing a valid hijack alarm. Of course, the challenge here is that these activities usually occur in an area not monitored by a NIDS, so you’ll need other corroborating data to see it (HIDS/NNIDS, router logs).
In any case, these alarms are not very useful on their own. Where they become valuable, in my opinion, is when they appear in concert with other alarms (e.g. SigID 7105 - ARP Inbalance-of-Requests).
I hope this helps,
Alex Arndt
