Rules and Filters

In certain circumstances, you may want to implement some form of security by filtering specific protocols, hosts, or even entire networks. These functions are similar to access lists in Cisco routers and firewalls. To achieve this functionality, the VPN 3000 Concentrator requires you to define a rule or a set of rules to be applied to a filter. When multiple rules are applied to a filter, the concentrator tests the conditions of the first rule. If the criterion matches, the rest of the rules are not processed. If there is not a match, the next rule is tested. In cases where none of the rules match, the concentrator performs the default action that is defined in the filter. After the filter is created, you can apply it to interfaces, users/groups, and LAN-to-LAN tunnels.

Out of the box, the VPN Concentrator has four preconfigured filters. Three of these filters are predefined for interfaces, and the fourth is created for a CPP firewall policy (discussed in Chapter 7, "Advanced VPN 3000 Feature Configuration"). The four filters are as follows:

• Private (Default) This default filter is preconfigured for the Ethernet 1 interface (private interface). The default rules applied to this particular filter allow all inbound and outbound traffic to be forwarded. This filter is not enabled on any interface by default.

• Public (Default) This filter is applied to the Ethernet 2 public interface by default. The rules applied to this filter allow inbound and outbound traffic for GRE, IPSec-ESP, IKE, PPTP, L2TP, ICMP, VRRP, and NAT-T protocols. All other protocols are denied in accordance with the default rule for this filter when a match is not met.

• External (Default) This preconfigured filter is designed to be used on Ethernet interface 3 (external interface), which connects to the corporate DMZ. No rules are associated with this filter and it is not applied to any interface by default.

• Firewall Filter for VPN Client (Default) When utilizing CPP for a firewall policy, this preconfigured rule can be pushed down to connecting clients. The only rule applied to this filter is to allow all outbound traffic.

Filter configuration steps and concepts are likely to appear on the exam.

To begin, you must create or modify rules that define the parameters that you are trying to filter. In the Configuration | Policy Management | Traffic Management | Rules screen, Cisco has predefined a list of rules you can modify to your specific needs. You can also add your own filter rule, copy an existing rule, or delete a rule in the list.

In Figure 6.1, a new rule called Mr. Ed is being created so Mr. Ed can administratively configure and monitor the VPN 3000 Concentrator across the Internet. To achieve this functionality, the concentrator must allow inbound and outbound HTTPS traffic on the public interface. The top section of the rule page states the name of the rule and the direction of packets that are being inspected. In the Action drop-down box, you can determine whether you want to forward or drop that packet, in addition to logging the occurrences of a match for the rule. You also can specify whether to apply an IPSec SA (authentication, encryption, and so on) to any packets that match the criteria in this rule. Because this rule is being configured to allow HTTPS traffic to be forwarded, we are creating an inbound rule that will be forwarding as its action.

Figure 6.1. Rule definition screen.

The next section enables you to specify the Layer 3 or Layer 4 protocol for which the rule is defined. You can specify the protocol in the drop-down box or indicate the protocol number that is derived from the protocol field inside an IP header. Here you can be more granular in your rule definition for such protocols such as TCP, UDP, ICMP, ESP, and AH. In addition, if the rule is being utilized for TCP, you can further define whether it applies to an established TCP session that was initiated from the source network. Using the example, this particular rule is to be applied to the TCP Transport layer protocol because HTTPS utilizes TCP at Layer 4 of the protocol stack. In addition, because the request is initiated from Mr. Ed who is outside of the concentrator's internal network, the established rule is not turned on.

Established TCP sessions are sessions that contain an ACK or RST in the TCP header. Because the initial TCP packet in a session connection does not contain an ACK in the header, this additional option forces the concentrator to drop all sessions that did not originate from its network.

In the Source and Destination parameters, you can specify the source and destination host or network for which the rule applies. To determine the source and destination IP addresses, you have the option of using a predefined network list (see Chapter 4, "Cisco VPN 3000 Remote Access PreShared Key Configuration") or using an IP address and inverse wildcard mask in the appropriate fields. Because it is wise to secure the administration of the concentrator, the rule is configured to accept HTTPS from Mr. Ed's network of 172.16.2.0/24 and destined for the concentrator's public interface of 192.168.1.101/32.

In instances where the protocol defined is TCP or UDP, the remainder of the rule definition enables you to extend the criteria to specific TCP and UDP ports or port ranges. In addition, if the rule is defined for ICMP, you can define the ICMP packet type (echo request, echo reply, and so on) that this rule is testing. Because TCP sessions choose a random TCP port as the source, the example allows the full range of TCP ports above the well-known range (ports 1024 and up). The destination port for incoming packets is going to use port 443, which is the TCP port assigned for HTTPS.

Additionally, an inverse rule needs to be created for outbound HTTPS that has a source address of the public interface of the concentrator and a destination of Mr. Ed's 172.16.2.0 network.

As soon as all the rules are defined, you can apply them to a filter or several filters. As depicted in Figure 6.2, the Configuration | Policy Management | Traffic Management | Filters screen enables you to add, delete, or modify filters, as well as assign rules to an existing filter. The example is going to add the created rules to the default public filter that is assigned to the public interface. Thus, the Public (Default) filter needs to be selected, and then the Modify Filter button needs to be pressed.

Figure 6.2. Filter definition screen.

At this point, you are presented with a screen similar to Figure 6.3. Here you can define the filter name as well as determine the default action if there is not a match for the rules assigned to this filter. The two check boxes on this screen allow additional security measures, which define whether the filter will allow source-routed packets or fragmented packets to pass. In addition, it is always good practice to assign a description for convenience so you or other administrators can easily determine the purpose of the filter.

Figure 6.3. Filter modification screen.

Source-Routed and Fragmented Packets

Source-routed packets explicitly state the route to follow to their destination, rather than following normal routing policies. These packets can pose a security threat; therefore, the check box is automatically unchecked so the concentrator does not forward them. In addition, IP packets may be fragmented by devices because of MTU size limitations to be reassembled on the receiving end. Because this is quite normal, the concentrator allows them to be passed by default. However, malicious code is sometimes sent in fragmented packets so security devices will allow them to pass. If security is a high concern and this option is checked (to allow the fragmented packets), be sure that the organization has an Intrusion Detection System (IDS) or firewall to detect these attacks.

After you have completed the parameters on this page, click on the Apply button to return to the filter menu. At this point, you are ready to add the Mr. Ed rules to the filter. Figure 6.4 represents the screen that is displayed to add rules to the filter. Recall that the filter performs top-down processing of the rules, so it is imperative to place rules that are more specific on the top, followed by general rules toward the bottom. In addition, all filters must have at least one forward statement in the assigned rules. Without a forward statement, all traffic for the filter will be dropped. You can prioritize the rules by moving them up or down in the filter's active list.

Figure 6.4. Rule assignment to filters.