Basic configuration IDSM-2

Question

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

Answer 1

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.