Basic configuration IDSM-2

[ruben.montes]

Hello,

I have some experience with sensors but this is my first time configuring a C6500 with IDSM-2, and I have some design questions. The first question is this: can I mix the use of VACL and SPAN to capture traffic in the same configuration?

Customer is actually using VACL to capture traffic from some machines, but he now wants to monitor all the traffic that comes from and external partner through a VPN concentrator, so I assume for this case I should use SPAN to monitor the VPN's port: am I right?

The config that the customer has is more or less the following:

intrusion-detection module 1 data-port 1 capture intrusion-detection module 1 data-port 1 capture allowed-vlan 1 intrusion-detection module 1 data-port 2 capture allowed-vlan 1

vlan access-map ids 10

match ip address in

action forward capture

vlan access-map ids 20

match ip address out

action forward

vlan filter ids vlan-list 1

ip access-list extended in

permit ip any host 192.168.1.1

permit ip host 192.168.1.1 any

...

ip access-list extended out

permit ip any any

If I want to use SPAN, which is the limitation in the number of source ports I can put in the "monitor session" command?

Should I send this "span" traffic to the sensing interface 8 (data-port 2) or can I still sending it to the data-port 1 (sensing interface 7)?

Why there are two sensing interfaces?

Thanks in advance...

Ruben

[marcabal · Accepted solution]

First thing to understand is that the customer should not configure both data port 1 and data-port 2 to see the same traffic.

The sensor will get duplicate packets, and will at a minimum lower the sensor's overall performance (spending cpu just to throw away the duplicates), and at worst could cause false positives and possibly even false negatives.

So the first thing to do is remove the capture configure configuration on data-port 2, so only data-port 1 is capturing packets.

Now that data-port 2 is freed up you can configure data-port 2 for something else.

So if you want to use span then yes you can now configure data-port 2 as a span destination port

Can you mix VACL and Span configurations?

Yes, but not on the same data-port. One data-port can be a vacl capture port, and the second data-port a span destination port.

However, you will want to try and avoid duplicate packets as much as possible. So you will want to try and configure it so that traffic that will normally be seen on the span destination port would not also be seen on the vacl capture port (usually means modifying the VACL to not capture that traffic).

Should you use Span to monitor the VPN port?

Span is usually the easiest way to ensure you get All of the packets in and out of a specific port. You will need to ensure that you use a port span (instead of a vlan span) and ensure you span both tx and rx traffic so you get both the in and out traffic.

Also ensure that the traffic you are spanning in the unencrypted traffic rather than the encrypted traffic (which would just be ignored by the sensor).

What is the limitation on the number of source ports?

I am not sure, and I believe it may differ based on your IOS version and type of supervisor. So you would need to read the configuration guide for your Cat 6K to determine the limits for your specific switch.

Should you send the "span" traffic to data-port 2 or data-port 1?

A data-port can not be both a VACL Capture pore and a Span destination port. So if data-port 1 is configured for VACL Capture then it can Not be a Span destination port. So configure one port as a VACL Capture port, and the other port as the Span destination port.

Why are there 2 sensing interfaces?

For doing things similar to what you are asking. So you can use 2 different monitoring techniques which would not be allowed on a single port. Or to be able to do promiscuous monitoring on one port, while doing inline vlan pair monitoring on the second port. Or use the 2 ports together in inline interface pair monitoring.

[ruben.montes]

Hi Marcoa,

many thanks for your explanation... I know understand much better how does the IDSM-2 work...

Best regards,

Ruben

[Fernando_Meza]

Great explantion !!!

Cheers,

[ruben.montes]

Hi Marcoa,

one last question...

I have been reviewing the show tech from customer's Cat6500 and they have IOS 12.2(17d)SXB, which means, speaking in SPAN terms, 2 monitoring sessions, 64 rx sources per monitor session or 1 tx or both source per monitor session.

Does it mean that I can only monitor completely (both directions)one port per monitoring session?

Also, if I'm using data port 1 with VACL and data port 2 as destination for "monitor session 1", I suppose I cannot also use data port 2 as destination for "monitor session 2".

If this is true, this means that I can only monitor simultaneously rx and tx in a source port per catalyst box running this image.: am I right?

Does it makes sense to monitor only rx direction for ports connecting with FWs, VPNs and WAN routers or we should monitor both ways?

I have noticed that in this case we cannot do what customers wants unless we upgrade customer's IOS to 12.2(18)SXE or later... With these new IOS is possible to have 128 tx or both sources!

Thanks in advance,

Ruben

[marcabal]

Does it mean that I can only monitor completely (both directions)one port per monitoring session?

Correct.

Also, if I'm using data port 1 with VACL and data port 2 as destination for "monitor session 1", I suppose I cannot also use data port 2 as destination for "monitor session 2".

An IDSM-2 Data Port can be the destination port for only a single monitor session.

If this is true, this means that I can only monitor simultaneously rx and tx in a source port per catalyst box running this image.: am I right?

Correct

Does it makes sense to monitor only rx direction for ports connecting with FWs, VPNs and WAN routers or we should monitor both ways?

If you are going to use port span, then you really need to monitor both tx+rx. The promiscuous sensor can be configured to work when monitoring just a single direction (like just rx), but the sensor will be prone to false positives and false negatives. The sensor really needs to see both directions of TCP connections in order to properly monitor them. To monitor single direction you configure the TCP Reassembly mode to be "asym" which is short for asymmetric. It is generally only used when the sensor is deployed in a network with asymmetric routes.

I have noticed that in this case we cannot do what customers wants unless we upgrade customer's IOS to 12.2(18)SXE or later... With these new IOS is possible to have 128 tx or both sources!

I haven't read the Span notes on the latest IOS releases. I am glad to hear that the number of both sources has been increased per session.

Alternatives:

The alternative to using "both" span on a port basis is to use an "rx" vlan span.

But you have to be very carefull with "rx" spans.

If the vlan is strictly layer 2 (no ip address assigned to the switch for that vlan), then an "rx" span for the vlan will work well. All traffic coming IN from a firewall will be seen as "rx" packets on the firewall port. All traffic going OUT to the firewall will be seen as "rx" packets from the other switch port where they are entering the vlan. So all packets IN and OUT of the firewall would be seen.

BUT if the switch itself Does have an IP Address on that vlan, and the switch routes between that vlan and other vlans, then this is no longer true.

The span works well on physical ports, but the switches IP Address is on a Virtual Interface in the vlan. This Virtual Interface does not play well with span in my past experience. The switch has a feature known as MLS (Multi-Layer Switching), The first packets for a TCP connection (the SYN and SYN ACK) are sent through the Virtual Interface for routing. An "rx" vlan span DOES catch these first packets coming from a Virtual Interface. BUT additional packets are affected by MLS. Instead of routing the packets through the Virtual Interface, the MLS kicks in and the packets are Switched in Hardware to the other vlan, and the packet never actually goes through the Virtual Interface. So the packet will NOT be seen by the "rx" span of the vlan.

Most users DO use the switch for routing, and so my recommendation is generally to use both tx+rx with Port Span to get the traffic. BUT if you are NOT routing, then the alternative "rx" span on the Vlan will work as well.

[vinodkumar.kp]

Hi Marcoa,

Do you have any idea about how to position an IDSM in a VSS scenario.

Regards,

Vinod.