cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
297
Views
0
Helpful
5
Replies

Sig 3250 assistance

n.oneill
Level 1
Level 1

Hi

Our IDS logged the following alert in the event log:

signature: sigId=3250 sigName=TCP Hijack subSigId=0 version=2.1.1

participants:

attack:

attacker: proxy=false

addr: locality=IN x.x.x.x

port: 27912

victim:

addr: locality=OUT x.x.x.x

port: 80

This sig is set to log and I have had a look at the packet captures but not sure how to check if this is a false positive. My gut feeling is this is ok but just wondered. Any suggestions on what I should look for?

The IN address is our local proxy server and the out address is an internal web server that is running a front end application.

Thanks in advance.

5 Replies 5

a-vazquez
Level 6
Level 6

Signature 3250 will fire when the ratio of data-less ACK packets to data-full ACK packets is 10 / 1 in a telnet, rlogin, or rsh session. The sensor has default threshold of 90 seconds for tracking TCP streams. If no stream activity is seen for 90 seconds, the stream will be dropped from inspection. If 3-Way Handshaking is enabled, all further traffic from a dropped stream will be ignored. If 3-Way Handshaking is disabled, inspection will resume in a new context. The signature monitors tcp ports 23, 512, and 513.

In the post from “a-vazquez” it is mentioned that the signature 3250, monitors tcp ports 23, 512, and 513. Has there been a change in version 4.1.4 to monitor all TCP ports? In our network, I am seeing this signature triggered fairly often. Web servers and proxy servers seem to be the main culprit. Anyone else seeing this?

SIGID: 3250

SubSig: 0

AlarmDelayTimer:

AlarmInterval:

AlarmSeverity: high default: high

AlarmThrottle: FireOnce

AlarmTraits:

CapturePacket: False

ChokeThreshold:

Enabled: True default: True

EventAction: ZERO

FlipAddr:

FragmentThreshold:

HijackMaxOldAck: 200

HijackReset:

MaxInspectLength:

MaxTTL:

MinHits:

MpcPercentThreshold:

MpcTimeout:

Protocol: TCP

ResetAfterIdle: 15

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>ServicePorts:

SigComment: TCP Hijack

SigName: TCP Hijack

SigStringInfo:

SigVersion: 2.1.1

StorageKey: xxxx

SummaryKey: Axxx

SynFloodMaxEmbrionic:

ThrottleInterval: 15

TrafficFlowTimeout:

WantFrag:

mcerha
Level 3
Level 3

As mentioned by the previous poster, this signature looks for an imbalance of data-less vs. data-full ACK packets. If you send a traffic sample to mcerha@cisco.com, I can give you a precise diagnosis.

While I don't have any packet captures to support the position that SigID 3250 is firing on ports other than the three listed, I do have an entry from my SIMS and a screen capture from IDM on the involved sensor (and it was not tuned) that would support that things may be amiss.

Here's the log:

Timestamp - 2004:06:07 14:54:25 GMT

Method - TCP Hijack

Source IP -

Source Port - 3418

Destination IP -

Dest Port - 80

SigID - 3250

NOTE: The screen capture clearly shows that no ports are listed in the "ServicePorts" variable field.

Alex Arndt

Alex, thank you for you reply and support;

I am sorry to push this one back up in the queue but I’d really like to hear any comments from Cisco regarding this signature.

Is there something missing in the signature or is this the way that it was intended for 4.1_4s95??

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: