TCP Hijacks

[ishah]

Hi All,

Using 3.02S6 for the IDSM we have seen multiple sensors alerting for TCP/IP Hi Jacks since upgrade from 3.01S2a software.

Investigating these it seems they are false alarms.

Has anyone else encountered this problem and are Cisco working is fixing this

Inti.

[klwiley]

We were unware of any problem with the hijack signature. Thank you for bringing it to our attention. There was work done on the TCP stream reassembly engine for the 3.0(1)S6 release and it is possible that something has inadvertently affected this signature. We will look into it.

[ishah]

Hi,

thanks for the speedy response.

the signature id's are as follows:

3250,3251

The IDS solutions are behind PIX firewalls for multiple customers and they report these alerts with internal RFC 1918 compliant IP's as well as Internet IP's.

We have seen them for ControlIT, HTTP access, SSH access and including using a secure data path where highjacking is not possible.

We are an ISP but we have also seen these in our closed Security Lab where no hijacking is taking place.

The concern we have is that if we filter these out, we could miss genuine attacks so a quick resolution or signature tune would be a great christmas present.

thanks

Inti

[ishah]

Hi,

I forgot to add we are using CSPM 2.3.3i with IP fragments reassembly and TCP Session Reassembly set to strict

thanks

inti

[seth.leone]

I've seen this alarm in our environment triggered by known telnet session timeouts. We have scripts limiting processor use per session and these timed-out sessions trigger the "Hijack" alarms all the time but I do have to verify them for non trusted sources as well.

[ishah]

Hi,

Each time a initiate a ControlIT session to a machine on the protected network from a secure IP source, this alarm triggers.

I am playing around with the re-assembly settings to try to get these under control as we had 300 yesterday, many from http access.

[klwiley]

On the IDSM the TCP HIJACK alarm is based on the number of old acks seen in a set period of time. In the case of a real hijack situation the network will be flooded with old acks (commonly referred to as an ack storm) from the host that was wedged out of the TCP session.

First let's try to tune the alarm for your environment by default we have the system set to 200 old acks in a 30 second period. You can safely change this to 200 in a 5 second period. If this does not help you can change the threshold to 500 in a 5 second period. If this still doesn't solve your problem then we need to see a traffic trace from one of these ControlIT sessions. You can adjust these through the advanced sig settings in CSPM.

Please let us know how this works out for you.

[ishah]

Hi,

We get this with port 80, port 25 and port 799 tcp on multiple installations with the new IDSM image and CSPM 2.3.3i(multiple servers).

I can't see which settings I need to modify to alter the HIJACK alarm.

I also noticed that removing the TCP HIJACK ports in Port Mapping does not affect these alerts. They still occur.

This alert definately this not fire with the old 2.5S2a image.

Inti.

[lathem]

There is a bug in 3.0(2)S6 where hijack analysis is performed on all monitored tcp streams and not just the ones listed in the TCP_HIJACK portmap. This will be fixed in the next signature update after S10 (S10 is too far along through QA to get it in).

In the 3.0 product the hijack signature was improved to avoid missing actual hijacks under certain conditions. This made the signature much more sensitive.

Another colleague should be replying with more detailed instructions on how to tune signatures under CSPM. If tuning to the values suggested by Kevin do not help, and you can send me a packet capture trace that triggers the alarm, I will examine it to see if I can desensitize it enough to avoid the benign traffic without losing the ability to detect actual hijacks.

Email me at lathem@cisco.com if you want to provide me a packet trace.

[vhernand]

Here are the steps to tune the TCP HIJACK signature using CSPM:

1. Select sensor that needs tuning.

2. Click on the Command Tab.

3. Click on Epilogue radio button.

4. In the Commands/Messages field, enter the following:

ExtendedOptionsSigOfGeneral 3250 200 5

In this case, the 200 is the threshold (# of old acks) and the 5 is the time period in seconds.

5. Click OK button.

6. Click Update button.

7. Double click on sensor and go to Command Tab.

8. Make sure Generated Commands radio button is selected.

9. Click Approve Now to send the configuration changes to the sensor.

[ishah]

Hi,

I have tried this and it seems to have made no difference.

I even set it to 500 5.

Is there any way of checking packetd.conf directly to see if the change has been made ?

Does ExtendedOptionsSigOfGeneral actually apply to Hijacks ?

This is an isp hosted environment using end to end cisco customer pods as follows:

Firewalls ->NAT -> Sensors multiple cat65k vlan span session rxtx to sensor.

Should I raise a TAC case or is there something else I can try first ?

Thanks for all the help guys.

[ishah]

Hi,

I dumped a report systemstatus out and the setting in Packetd.conf is

ExtendedOptionsSigOfGeneral 3250 500 5

The alerts are still coming in so I assume this is being ignored.

I have a TAC case open but I cannot believe this is unique to us as 7 IDSM sensors in different locations are doing the same thing and only started this after being upgraded.