Introduction to FPM

So you are labbing it up and are just about at the end of your rope with this Flexible Packet Matching. If you see one more task with FPM you are going to blow a gasket! Don’t worry, you’re not alone. Many students have difficulty with FPM. I think it’s because it just needs to be laid out the right way. So, never fear! IPexpert is here. Let me give you the “What you need to know” version of FPM.

Basically, FPM is a Stateless Packet Classification Mechanism used in Cisco IOS to deploy custom filters to various types of traffic. When I say stateless what you should be understanding from that is that FPM only looks at 1 packet at a time, and has no concept of a flow of traffic. This is packet by packet inspection. FPM goes beyond the static attributes that are traditionally seen when using Access Control Lists and enables filtering based on not only static attributes, but arbitrary bits or bytes at any offset within the entire packet payload or entire packet header, as well as the ability to specify multiple attributes in a packet. In other words, what makes FPM so flexible is that it can “see” a ton of stuff in the packet, which lets us have a lot more control than an ACL ever offered us.

Now FPM starts with a PHDF file, so lets break that down.

PHDF Files

FPM makes use of XML files called Protocol Header Description Files to map out the fields in various headers. You can think of this as a road map for FPM, whereas otherwise it would not know how to find the destination-port filed in a TCP header, the PHDF gives it a map to follow and locate the correct field. PHDF files are used any time you enter the “match field” command in an FPM class-map. The PHDF files are located at “system:/fpm/phdf/”. These files need to be loaded prior to configuring FPM.

load protocol system:/fpm/phdf/ip.phdf
load protocol system:/fpm/phdf/tcp.phdf
load protocol system:/fpm/phdf/udp.phdf

Once you have the PHDF loaded you can create a policy that utilizes what they can “match.”

Creating a Filter Policy

Creating a Filter Policy with FPM usually requires the following steps:

1. Load a PHDF (for protocol header field matching)
2. Define a class map and define the protocol stack chain (traffic class)
3. Define a service policy (traffic policy)
4. Apply the service policy to an interface

For FPM to match traffic you must be able to identify traffic. FPM identifies traffic using a class-map. There are two types of class-maps used in FPM, stack and access-control. When using a loaded PHDF, the class specification begins with a list of the protocol headers in the packet. This is done using a class-map command with type “stack”. The class-map type stack is not that difficult to understand. FPM, by default, only knows about the IP header. If you dont define the “stack” then you are stuck filtering on what’s in the IP header only. However, when you define the stack it gives you the ability to say, “First I want you to look at the IP header for this, then we go look at the TCP header for this.” Again, without a class-map type stack FPM cannot go look at information that is in any header other than the IP header.

class-map type stack [match-all | match-any]

match field   {eq | neq}  [mask ] next

-or-

match field   {gt | lt | range | regex } next

If no stack-type class map is specified, the default protocol stack is IP only and you will be limited in what FPM can be used to match.
Once the stack of protocols is defined, a class map of type “access-control” is defined for classifying packets.

class-map type access-control [match-all | match-any]

match field   { eq | neq }  [mask ]

-or-

match field   { gt | lt | range | regex }

The next step is to create a policy map that can be attached to one or more interfaces. This policy map will specify the name of the previously created class-map as well as the action of drop.

policy-map type access-control childPM

class DEST

drop

Policy-map type access-control parentPM

class SOURCE

service-policy childPM

The Final step is to apply the policy using the “service-policy” command.

interface FastEthernet0/0
 service-policy type access-control input parentPM

FPM Example 1: Blocking SSHv1

Begin by loading the PHDF’s:

load protocol system:/fpm/phdf/ip.phdf
load protocol system:/fpm/phdf/tcp.phdf

Next you’ll want to create the class-map type stack so that FPM knows where to look. In this case we are creating a class-map type-stack that tells FPM that we are going to start in the IP header by looking at the protocol field and making sure it is 0×06, which is TCP. Then we are telling FPM the next thing to look at is the TCP header. When looking at the TCP header we have instructed FPM to look into the destination port field and match on port 0×16 which is port 22, or SSH. The next IP is simply there to say, “OK, no more, lets get on with things now.”

class-map type stack match-all TCP
 match field IP protocol eq 0x6 next TCP
 match field TCP dest-port eq 0x16 next IP

Next we have told FPM with a class-map of type access-control, that is should start looking at the IP payload. Now this is where it’s a bit interesting. The IP Payload “is” where the TCP header starts. The TCP header is 20 bytes. So we are telling FPM to start looking at the packet 20 bytes AFTER the IP header. In other words, look at the data AFTER the TCP header. From there we want to look at 28 bytes for the string defined in the regular expression.

class-map type access-control match-all SSHv1
 match start IP payload-start offset 20 size 28 regex "^SSH\-1\.[0-9]+"
!

Next a policy-map is created that refers to the access-control class-map. Remember that without referencing the stack FPM will have no idea where to look.

policy-map type access-control SSHv1
 class SSHv1
   drop
   log

So next we tell FPM, look at the class TCP, which refers to the stack class. Once you know its TCP traffic on port 22, then I want you to look at the SSHv1 class, the access-control class for the regex string that identifies SSH version 1.

policy-map type access-control FPM
 class TCP
  service-policy SSHv1

Finally we wrap this up by applying the policy to the interface.

interface FastEthernet0/0
 service-policy type access-control input FPM

Ok, so now you’re thinking…”I got this! FPM is in the Bag.” Well, let’s see just how well you got this.

This next example actually has a problem. Can you spot what it is?

FPM example 2: Find the Problem

class-map type access-control match-all TELNET_BLOCK_CM

 match field IP dest-addr eq 192.168.30.1

 match field IP protocol eq 6

 match field TCP dest-p eq 23

policy-map type access-control TELNET_BLOCK_PM

 class TELNET_BLOCK_CM

  drop

int fa0/1

 service-policy type access-control input TELNET_BLOCK_PM

Did you spot the issue? If you said that we cannot use the “match field TCP dest-p eq 23 line in the class-map type access-control then you’re right and you deserve a pat on the back. Now the question is, Why? Well, the reason we cannot use the “match field TCP dest-p eq 23 line in the class-map type access-control is because we have not defined a class-map type stack that tells FPM, “Once you look at the IP header I want you to look at the TCP header.” The fix here would be to create a class-map type stack with the stack definition.

The Wrap-Up

Well, obviously there is more that can be done with FPM, however I’m confident that you now have a better understanding of how the stack-class works in allowing you to match traffic more granularly. If you’re feeling bold I challenge you to create an FPM policy that blocks telnet from a specific host, one that blocks all ICMP echo’s and one that blocks all fragmented packets. Each of these should be easy enough to test and will make you more proficient in configuring FPM when asked to do so on the CCIE Security Lab Exam.

-Happy Labbing!

Brandon Carroll – CCIE #23837

Senior Technical Instructor – IPExpert

Mailto: bcarroll@ipexpert.com
Telephone: +1.810.326.1444
Fax: +1.810.454.0130

Introduction to FPM, 3.0 out of 5 based on 2 ratings