Flexible Packet Matching Concepts and Configuration

On modern networks, there are a number of different methods that an attacker can use to take advantage and break into a network. As time goes, on these methods become more complex, and the ability to detect them mirrors this and must also become more complex. Keeping up with this cycle is the job of attack detection vendors and security specialists. A situation can develop when a new attack occurs before a method of detection has been created; these attacks are referred to as zero-day attacks. When these situations occur, it is important that the organization has the ability to setup a series of filters that can isolate the attacking traffic from the production network. This is one of the situations where the Flexible Packet Matching (FPM) feature can be put to use. This article takes a look at the FPM feature, what it can be used for and the basic steps that would be used to configure it.

Flexible Packet Matching Concepts

The FPM feature offers an extended filtering facility that provides engineers the ability to match based on a number of non-traditionally available methods. FPM removes previous filtering restraints that existed when trying to match based on specific fields in a packet as well as provides the ability to match specific bits in a packet at arbitrary depths. For example, if a signature pattern was found by the organization's information security staff, FPM could be configured to match this pattern regardless of where it existed within the packet.

There are two methods that can be used when implementing FPM to match packets. The first uses a Protocol Header Description File (PHDF), this file is simply an XML file that defines all of the fields within a specific protocol that can be used to match on. For example, one exists for IP, another exists for TCP and yet another one exists for UDP. The second method allows the engineer the ability to match based on a specific length and depth within the packet. With these two abilities combined, the engineer can match almost any possible combination.

There are a few important restrictions that exist with the FPM feature that an engineer must be aware of:

• FPM is stateless and cannot match based on ongoing traffic flows
• FPM currently only works with IPv4 unicast traffic
• FPM does not work with IP traffic that utilizes the options field
• FPM does not match noninitial fragment traffic

Flexible Packet Matching Configuration

The configuration of the FPM feature utilizes the familiar class-map, policy-map and service-policy command structure. This command structure is used by many of Cisco's features and operates in the same way. The class-map commands are used to classify what traffic is going to be matched, the policy-map commands are used to determine what action will be taken with the matched traffic, and the service-policy command is used to apply the configuration to a specific interface.

The configuration of the FPM class map can be a little confusing as two separate FPM class map types exist depending on the matching criteria that will be used. The stack class map type is used when matching will be based on specific fields that are loaded with the PHDF file. The access-control class-map is used when matching is based on fields defined with the PHDF file and when matching is only based on an arbitrary location within the packet. In an attempt to make this process clear, an example of both will be shown later in the article.

The configuration that is required to set up FPM is shown in Table 1.

Table 1

Flexible Packet Matching Configuration Examples

To ensure that a basic understanding of FPM configuration exists, a couple of examples will be shown that will give a configuration starting point. The first of these examples will use the FPM feature to match traffic based on a one byte string (0xAB) located at offset 200 starting at the layer 3 packet.

router(config)#class-map type access-control match-all sample-class
router(config-cmap)#match start l3-start offset 200 size 1 eq 0xAB
router(config-cmap)#policy-map type access-control sample-policy
router(config-pmap)#class sample-class
router(config-pmap-c)#drop
router(config-pmap-c)#interface fastethernet0/0
router(config-if)#service-policy type access-control input sample-policy

The second example will take advantage of the PHDF capabilities and match all FTP traffic on port 21 that also has a matching 2 byte string (0x1234) at offset 150 starting at the layer 2 frame boundary.

router(config)#load protocol system:fpm/phdf/ip.phdf
router(config)#load protocol system:fpm/phdf/tcp.phdf

router(config)#class-map type stack match-all sample-stack-class
router(config-cmap)#match field ip protocol eq 0x6 next tcp

router(config-cmap)#class-map type access-control match-all sample-access-control-class
router(config-cmap)#match field tcp dest-port eq 0x15
router(config-cmap)#match start l2-start offset 150 size 2 eq 0x1234

router(config-cmap)#policy-map type access-control sample-nest-policy
router(config-pmap)#class sample-access-control-class
router(config-pmap-c)#drop

router(config-pmap-c)#policy-map type access-control sample-policy
router(config-pmap)#class sample-stack-class
router(config-pmap-c)#service-policy sample-nest-policy

router(config-pmap-c)#interface fastethernet0/0
router(config-if)#service-policy type access-control input sample-policy

Summary

As can be seen from the examples, the FPM feature can be used for a vast number of matching possibilities and should be in the tool bag of any engineer requiring this functionality. It should certainly be a feature that all Cisco security engineers should be aware of, should a situation arise where an attack without a current existing signature is found. Hopefully the information contained within this article will show those unfamiliar with the feature the possibilities that exist and that can be implemented should the need arise.