IDS-4215 Promiscuous

js.franklin · ‎02-13-2007

Setting up a 4215 with 4FE. VER 6.0(1)E1 sig S268.0 Just getting familiar with system. I've placed the f0/1 int on internal net and span to the 4215 f0/1. Question: Do you need an alternate tcp reset interface if running promiscuous? If so where would you place the additional interface? There's not a whole lot of information out there. I've read over the config and cr and how to on the Cisco web site. Let me know if anyone has any good strategies to setup the IDS as promiscuous to monitor and get familiar with the product.

marcabal · ‎02-13-2007

The "alternate tcp reset interface" is the exception rather than the rule.

In most deployments the TCP Resets will be sent back out the same interface that monitored the traffic.

However, there are some deployments where this will not work. Some switches do not allow incoming packets from their span ports. So the sensor will send the TCP Resets but the switch will drop them. If your sensor is monitoring with a TAP then the TAP will drop them because it does not accept packets coming from the monitoring ports.

In these situations where the device that the monitoring port is connected to will drop the TCP Reset packets, then you can use the "alternate tcp reset interface" configuration.

You would plug a second interface of the sensor (an unused monitoring port) into the switch. Configure that port for the same vlans being monitored by the promiscuous port connected to the span. Configure that unused monitoring port as the "alternate tcp reset interface" of the port connected to the span, and Enable that unused port (but do NOT add it to the virtual sensor, it will not be monitored).

Now when an attack is seen the sensor will generate a TCP Reset, but instead of sending it the Resets out of the port where the attack was detected it will instead send those packets out of the "alternate tcp reset interface" port.

js.franklin · ‎02-13-2007

That explanation clears things up. I'm not using a tap. The internal network is fairly simple and consists of two Cisco 3560-48TS with a single trunk connection between them with one vlan. I don't believe that the monitoring (destination) span port can respond. If I understand you correctly then I believe that in this scenario that I will need to add the second reset interface. Let me know if I'm off the track here.

marcabal · ‎02-13-2007

You are on the right track and appear to have a good grasp of the fundamentals now.

As for the 3560 switch, I believe that the 3560 actually Can be configured to allow the TCP Resets on the Span destination port (I think they put this feature in specifically for monitoring by a Cisco sensor).

So you would not need the "alternate tcp reset interface" configuration with a 3560, but would need some additional options on your span session in the switch config itself.

According to the config guide for a 3560 running IOS, a span is capable of receiving incoming traffic (TCP Resets), but requires a few extra options on the monitor command to enable it:

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat3560/12235se/scg1/swspan.htm#wp1260596

If all of your traffic is on a single vlan then the "ingress vlan " may be all that you need added.

NOTE: I have never tested this on a 3560 so I am just having to rely on the user's guide here.

sebastan_bach · ‎09-01-2007

hi marcabal can u pls tell me that when we are normally connecting the ids sensor port to the switch. we leave the switch poert to the dynamic state right. we don;t configure the port as a access or trunk port.

so when using a alternate interface for tcp reset can u pls tell me what should be my config

on the switch for that port.

i am struggling on this to get it done.

can u pls help.

regards

sebastan

marcabal · ‎09-03-2007

Whether to configure the span port also as an access port of a trunk port is very dependant on the specific switch and software versions running on that switch. Some Cisco switches will require them to be trunk ports for traffic from multiple vlans to be sent to the sensor, while others require a special option on the span command itself.

You will need to read through your switch documentation to determine the right configuration of the port and the span commands to get the specific traffic you want.

As for TCP Resets there are 2 options.

Option 1 is to send the tcp resets back out the interface that is monitoring the traffic (this is the standard method). But it does require the following:

a) The switch will allow incoming packets on the span port. Some switches do allow it, others do not, and some require a special configuration option.

b) If the traffic is not 802.1q encapsulated then the switch itself must put those tcp reset packets onto the same vlan where the traffic is coming from. If only 1 vlan is being monitored then this is usually not a problem, but if monitoring multiple vlans then this is a problem and the tcp resets will usually only work for one of the vlans at most.

c) If the traffic IS 802.1q encapsulated then the sensor will send the resets out with 802.1q trunk headers, and the switch must be able to accept these and send them to the corresponding vlan.

Option 2 is to use an "alternate tcp reset" interface. In this situation a second interface of the sensor must also be plugged into the switch. In most cases this interface is NOT monitored by the sensor and is Only used for sending resets. Within the configuration of the monitored interface you specify the other interface as the alternate tcp reset interface.

When plugged into the switch you still have similar issues as I mentioned with option 1.

Either all traffic is on the same vlan in which case the switch port for the alternate tcp reset interface needs to be an access port for that same vlan.

OR the traffic has 802.1q headers, in which case the switch port for the alternate tcp reset interface Must be a trunk port and tunk all possible vlans where that traffic may be coming from so that the switch will accept those incoming 802.1q encapsulated tcp reset packets.