IDSM2 4.1 and POS

[jstewart]

With IDSM1 I used to span my wide-area ATM (WS-X6101-OC12-MMF) VLAN's, but now we have upgraded to IDSM2 4.1 and POS (OSM-2OC12-POS-SI) for wide-area on hybrid Cat 6509's with Sup 2 (7.6(2)) and MSFC2 (12.1(11b)E4). How do I select the POS blade traffic for the IDSM2? If I direct it to the IDSM2mod/7 interface should I inactivate the IDSM2mod/8 interface in the device manager? I remember reading that you now use the IDSM2mod/1 interface for resets, how do I define the POS interface for that? Thanks.

[marcabal]

IDSM2 ports as seen in Cat OS:

port 1 is the TCP Reset port - no additional configuration needed for this port by default it trunks all vlans including the hidden vlans used by your POS ports

port 2 is the Command and Control port - place this port in the command and control vlan

port 7 & 8 are both Sensing interfaces for the IDSM2 - they can be configured as span/rspan destination ports or vacl capture ports

NOTE: In most deployments the users will just send packets to port 7 and not need to send anything to port 8. The user should avoid sending the same packets to both 7 and 8 as this will slow down IDSM2 performance. It is just some rare scenarios where the user may want to send certain packets to port 7 and different packets to port 8.

So for your deployment you can just use port7, and even disable port 8 within IDM as you mentioned. NOTE: TO disable port 8 requires you upgrade to version 4.1. Version 4.0 had ports 7 and 8 linked together for enabling and disabling.

If you were monitoring a standard ethernet port then you could span the traffic to port 7.

Now that you have switched from an ATM port that can be spanned to a POS port that can not be spanned, you have to make some decisions.

- You could span the local network ports instead of the POS ports (depending on deployment this may be more traffic than the IDSM2 can handle).

- You could use the "mls ip ids" commands in the MSFC configuration to mark packets for capture similar to the VACL Capture feature. - NOTE: You will want to use IP Logging to verify that the sensor is seeing both the traffic entering as well as leaving the POS interfaces. Some configurations may result in the IDSM2 only seeing traffic in one direction

- or You could use VACL Capture on the local network vlans to to capture packets which would be routed out through the Wan port.

Of the 3 options I would suggest using VACL Capture on the local network vlans.

You would need to create a VACL the would

1) permit traffic between local networks without using the capture keyword

2) permit traffic between the local networks and all other networks using the capture keyword (this way traffic that would go out through the wan port would be marked as capture packets)

Then apply that VACL to the local network vlans.

Then Configure port 7 to be a VACL Capture port, and a trunk port of all vlans (which includes the hidden vlans for the POS ports)

[jstewart]

Thank you for answering my questions and getting me pointed in the right direction.

I see a problem with the VACL capture suggestion, as I would like the IDSM2 to see not only the traffic going out over the WAN/POS connection; but also, more important, the traffic coming in through the WAN/POS connection. The two-way aspect of the VACL's make configuration on multiple / equal-cost interfaces difficult when trying to capture the incoming traffic.

On the other hand, your second suggestion of using "mls ip ids" looks like a good choice for WAN/POS input capturing. I could 'permit' my site-internal subnets, deny everything else, and add the ACL to the /1 and /2 POS interfaces. That should capture everything (correctly-routed) entering the site from the WAN.

To capture the traffic leaving on the WAN/POS interface I would have to define an ACL which denies my site-internal subnets and permits everything else. I could use "mls ip ids" to add this ACL to all of my local Ethernet and ATM VLANs on the router.

Does this sound like a viable solution?

[marcabal]

In response to your first question:

The VACL will actually allow you to see the packets going out as well as coming in through the POS connections.

Let me give you an example using HTTP:

I create the following VACL to capture my HTTP traffic:

set security acl ip COPYHTTP permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255

set security acl ip COPYHTTP permit tcp any any eq 80 capture

set security acl ip COPYHTTP permit tcp any eq 80 any capture

set security acl ip COPYHTTP permit ip any any

You will notice that I initially permit traffic going back and forth between two addresses on my internal 10.0.0.0 network so that it will be permitted but not captured.

The next 2 lines will then capture both directions of my web traffic. This in effect will capture both incoming web traffic as well as outgoing web traffic.

The last line simply permits all the remaining traffic without capturing it.

NOTE: If I wanted to capture ALL traffic in and out of the POS ports rather than just web traffic then I can remove lines 2 and 3 and simply make the last line "permit ip any any capture" in order to capture ALL the rest of the traffic.

NOTE2: If I had several internal networks then I just have to add the additional permit lines to permit packets between these different networks before putting in the capture lines.

Now let's say I have 10 internal vlans (1-10).

I apply the VACL to ALL 10 internal vlans:

set security acl map COPYHTTP 1-10

Now I configure my sensor port 4/1 to be a trunk port of ALL possible vlans:

set trunk 4/1 on dot1q

set trunk 4/1 1-1005,1025-4094

NOTE: vlans 1006-1024 are restricted vlans, not having these on the trunk does not affect the capturing of POS traffic

Now I configure it to be a Capture port:

set security acl capture 4/1

Now a discussion of what happens for an internal web client A on vlan 10 connecting to a web server B through the POS ports:

A sends the SYN packet on vlan 10 to B

The supervisor marks it as a capture packet and sends it to the MSFC on vlan 10 for routing.

At the same time the sensor will see it because it is a capture port for vlan 10.

The MSFC sends it on a hidden vlan out to the POS port to B

B responds with a SYNACK packet to A

The MSFC receives it from the POS port on a hidden vlan.

The MSFC routes it to vlan 10.

The supervisor marks it as a capture packet and sends it to A on vlan 10.

At the same time the sensor will see it because it is a capture port for vlan 10.

So you see that the VACL is capturing both the client and the server traffic routed in and out of the POS port.

There is a little bit of weird interaction between the VACL and MSFC routing to be aware of.

(NOTE: I know it affects routing between ethernet vlans, but I believe it also affects routing with POS ports):

The additional packets from A to B is handled a little bit different:

A sends the ACK packet on vlan 10 to B

The supervisor gets it and recognizes that a flow had already been established. This allows the PFC to do the routing instead of having to send it all the way to the MSFC. So the PFC routes it to the hidden vlan of the POS port, and at the same time marks the packet for capture.

This is the weird part because now the packet is marked for capture on the hidden vlan of the POS port instead of vlan 10.

BUT because our sensor is a capture port for ALL vlans (including the hidden vlan of the POS port), our sensor will see the packet just fine.

The sensor receives the packet at the same time the POS port receives the packet and sends it out to B.

The reverse happens for the additional packets from B:

B sends additional packet in through the POS port to A:

The supervisor gets it and recognizes an established flow. The PFC (instead of the MSFC) routes it to vlan 10 at the same time it marks it for capture.

The sensor is a capture port for vlan 10 and sees the packet at the same time it is sent to A.

So VACL Capture on internal vlans can be used to capture traffic passing both directions through the POS ports.

If the VACL is only being used for Capture then it is fairly easy to create, and the same VACL can ne applied to all of the internal networks.

BUT if the VACL is used for denying traffic and other things, then it becomes more difficult and could result in a unique VACL per vlan, in which case the mls ip ids may be easier to use.

In response to your question about "mls ip ids"

If I remember correctly the mls ip ids will usually be applied against packets coming in the designated interface.

So the acl to be used with mls ip ids on the POS interfaces will need to permit traffic from "any" address to an internal network address.

BUT you will ALSO need to put the mls ip ids on the interfaces for your internal vlan networks as well.

The acl to be used with the mls ip ids on the internal vlan interfaces will need permit traffic from the internal network to "any" address.

The IDS needs to see both sides of the traffic so when using "mls ip ids" instead of VACLs you really need to use the command on All interfaces of the MSFC so you can capture the packets regardless of which interface they get routed in from.

And just like with VACLs, the sensor port still needs to be a capture port for ALL vlans. The packets will still wind up being captured on both the internal vlans as well as the hidden vlan of the POS interface.

SIDE NOTE: I have seen some situations where "mls ip ids" implemented on a single interface was capturing traffic in both directions on that interface. This was happening in IOS running on the MSFC, but was not happening on Native IOS running on the Sup/MSFC combination. This is because the mls ip ids code was written slightly different for each platform because of differences in the code paths. So the statement that a "mls ip ids" will capture the packets coming in that interface is true, however sometimes the "mls ip ids" may even capture packets leaving on an interface. This can sometimes lead to duplicate packets when applying mls ip ids to multiple interfaces. To prevent the duplicate packets, the ACL used with mls ip ids can be written to specifically match just the packets coming in the interface so it won't even have the possibility of matching packets going out the interface.

Capturing only one side of the connection would cause false positives, false negatives, and performance degradation of the sensor.

So you should use mls ip ids on both (or all) interfaces to ensure the sensor sees both sides of the connection.

[jstewart]

I am still having problems with capturing POS traffic for the IDSM2 (sig-S57) on a hybrid 6509 (Sup2 7.6(2)/12.1(11b)E4). I have tried a number of configurations and I have not been able to generate alerts for traffic leaving my network over the POS module.

1.) If I use a security acl with PERMIT IP ANY ANY CAPTURE on my internal VLANs then I only see alerts for traffic going to other internal VLANs and for traffic entering my local network through the POS module.

2.) If I use an extended access list in the MSFC IOS with PERMIT IP ANY ANY and MLS IP IDS on the POS interface, I only see traffic entering my local network through the POS module.

3.) If I use an extended access list in the MSFC IOS with PERMIT IP ANY ANY and MLS IP IDS on my internal interfaces, then I only see alerts for traffic going to other internal VLANs and for traffic entering my local network through the POS module.

[wardwalk]

Hi James, I'll put together a setup to match yours (sup2 hybrid 6509) and contact you via email with assistance.

Thanks,

Ward.