Configuring VACLs

Configuring VACLs

VLAN Access Control Lists (VACLs) is the tool for controlling redirection of traffic within VLANs—both bridged and Layer 3–switched. Packet filtering can be done based on Layer 2, 3, and 4 headers. VACLs are enforced in hardware and do not produce overhead. In general, they are similar to IOS access lists, the main difference is that VACLs are not direction-specific and capture both ingress and egress traffic. In order to use the VACL feature, you need to have a PFC (Policy Feature Card) installed.

VACLs allow for much more granular control over the selection of traffic forwarded for inspection by an IDS system. It is possible, for example, to capture traffic based on source or destination IP addresses, to filter it by TCP port numbers or capture only packets from established sessions. Furthermore, MSFC (Multilayer Switch Feature Card) can use flows to ensure that packets crossing the backplane between VLANs are not duplicated when captured. VACLs are especially useful when an IDS Module is installed on a Catalyst switch.

Configuring VACLs is more complicated that SPAN settings. The following steps need to be performed:

1. Create a VACL to capture interesting traffic.

2. Commit a VACL to switch hardware.

3. Map the VACL to specific VLANs.

After that, a monitoring port is selected and assigned as a VACL capture port. In the case of IDSM, it will be port 1 on the module.

Note

By default, port 1 on IDSM is set as a trunk port by default and will monitor traffic from all VLANs where appropriate VACLs are configured. If you want to monitor specific VLANs only, you need to clear the unwanted VLANs from this trunk. We show this in detail in Chapter 6.

As usual with high-end switches, configuration commands depend on which software runs on a switch. We will see how VACLs are configured on a CatOS switch and then compare this to an IOS-based one.

Configuring & Implementing: Which Is Better—VACL-Based Capture or SPAN Ports?

Both technologies provide a means for capturing network traffic. Either can be more useful than the other, depending on the circumstances. SPAN sessions are much easier to configure, but they are limited in number (you can have two to six local SPAN sessions and up to 64 RSPAN destination sessions on one switch depending on a model) and can drop or duplicate packets in some cases.

VACLs can capture inter-VLAN traffic (they actually capture traffic based on IP flows instead of matching ports or VLAN names) and this capture is performed with a high degree of granularity. On the other hand, the VACL feature is available only on high-end switches with PFC cards installed. Furthermore, it is possible to have only one VACL per protocol, that is, you can configure only one VACL for IP traffic.

The sidebar "Using RSPAN and VACLs Together" describes how VACLs can be applied to RSPAN VLANs in order to filter traffic in the distributed capturing environment.

On a SET-based switch, VACLs are created using the set security acl command. Its syntax when it is used for capturing IP traffic is as follows:

set security acl ip  permit   
    [operator port]  [operator port] [established]
       capture

The protocol field can be any IP protocol, or the abbreviations tcp, udp, or icmp. For example, this sequence of commands:

Sw6000> (enable) set security acl ip IDSCAP permit tcp 192.168.1.0 0.0.
    0.255 range 1024 32000 10.1.1.0 0.0.0.255 lt 1024 capture
IDSCAP editbuffer modified. Use 'Commit' command to apply changes
Sw6000> (enable) set security acl ip IDSCAP permit ip any any
IDSCAP editbuffer modified. Use 'Commit' command to apply changes
Sw6000> (enable)

creates a VACL which captures traffic with source IP addresses from network 192.168.1.0/24, source ports 1024-32000, and destinations in the network 10.1.1.0/24, as well as destination ports 1–1023. It also has a permit any any at the end, because there is an implicit deny any any at the end of each VACL, and we do not need to really drop any traffic, just select some of it for inspection.

The next stage is to commit the access list to hardware. This is done either for each list by its name or all of them at the same time using the command

commit security acl  | all

For example,

Sw6000> (enable) commit security acl IDSCAP
Hardware programming in progress...
ACL IDSCAP is committed to hardware.
Sw6000> (enable)

The final step in VACL configuration is mapping a created access-list to specific VLANs which have to be monitored. The command is as follows:

set security acl map 

Note

When mapping VLANs using the set security command, valid values for the VLANs are from 1 to 1005, and from 1025 to 4094.

For example, to map our IDSCAP access-list to VLANs 100 and 200, we would use the following set of commands:

Sw6000> (enable) set security acl map IDSCAP 100
ACL IDSCAP mapped to vlan 100
Sw6000> (enable) set security acl map IDSCAP 200
ACL IDSCAP mapped to vlan 200

The preceding steps are common in VACL configuration, but in the case of VACLs with the capture feature, we also need to specify the destination of the captured traffic. This is done using the command

set security acl capture-ports mod/ports…

This command specifies a set of ports as capture destinations. For example, with the IDSM module installed in slot 5, the following command will forward captured traffic to the module (IDSM capture port is port 1, 5/1 in this case):

Sw6000> (enable) set security acl capture-ports 5/1
Successfully set 5/1 to capture ACL traffic.

On IOS based switches, different commands are used, although the same steps are followed. The preceding example would be implemented in the following way. First, an extended IP ACL would be created like so:

R6000 (config)# ip access-list 101 permit tcp 192.168.1.0 0.0.0.255 range
    1024 32000 10.1.1.0 0.0.0.255 lt 1024 

This list does not need a permit any any clause at the end, because it will not actually filter any traffic, only match a part of the traffic for capture. Then, a VLAN access map called IDSCAP is created and configured to match traffic based on IP access list 101 which then captures matched traffic:

R6000 (config)# vlan acces-map IDSCAP
R6000 (config-access-map)# match ip address 101
R6000 (config-access-map)# action forward capture

This map is applied to VLANs that have to be monitored by an IDS:

R6000 (config)# vlan filter IDSCAP vlan-list 100,200

Finally, a port on a switch (or on an IDSM module) is configured as a destination port for captured traffic.

R6000 (config)# interface gigabitEthernet 8/1
R6000 (config-if)# switchport capture

Designing & Planning: Using RSPAN and VACL Together

As was noted in the section "Configuring RSPAN," the task of capturing traffic in a distributed switch structure is difficult and requires a strategic approach. It is very easy to oversubscribe monitoring ports so that switches start dropping spanned packets. VACLs provide a neat way of controlling RSPAN-produced traffic.

You can configure a RSPAN VLAN with interesting traffic, and then further narrow traffic selection down, applying a VACL to this VLAN. The process is not easy though, depending on how complicated the infrastructure is, what software is used on switches (with CatOS configurations being generally more straightforward), and how complicated the conditions for the traffic selection are.

VACL are not compatible with some features of Cisco IOS Firewall for MSFC. You cannot apply VACLs to a VLAN in which there is an ip inspect rule. There is a workaround for this case, though—using the command

mls ip ids 

This command matches incoming traffic against a specified extended IP access-list. If a packet is permitted by the ACL, it is captured. If a packet is denied, it is not captured. Thus, the packet is not actually permitted or denied—it is always forwarded to its destination. The example of configuration is shown next (these commands are executed on the MSFC):

R6000 (config)# ip access-list 101 permit tcp 192.168.1.0 0.0.0.255 range
       1024 32000 10.1.1.0 0.0.0.255 lt 1024
R6000 (config)# interface vlan 100
R6000 (config-if)# mls ip ids 101

After the capture destination is configured on the supervisor engine using the commands described earlier, either

set security acl capture-ports

or in the case of IOS-based switches

switchport capture

Note

For IDS Module to capture packets marked by the mls ip ids command, port 1 of the IDSM must be a member of all VLANs where these packets are routed. When using VACLs, the capture port of IDSM has to be a member of VLANs where monitored packets are internally routed