Cisco Flexible Packet Matching

While reading for my CCNA security exam I ran across an interesting link from cisco (You have to admit, if you dig deep enough some of cisco’s documentation is excellent)

It describes their Flexible Packet Matching (FPM) engine, available on certain routers and switches. To me this seems a fancy way of saying that they implemented an application firewall, capable of reading into Layer 7. In typical cisco style the easiest way to get to the guts of the system is by seeing an example CLI configuration. Taking the same example (blocking skype) as is presented in the document:


!—Load Protocol Header Description File
load protocol system:/fpm/phdf/ip.phdf
load protocol system:/fpm/phdf/tcp.phdf
!—Defines Protocol Stack and Match Criteria (FPM filter to block
Skype traffic)
class-map type stack match-all ip_tcp
match field IP protocol eq 6 next TCP
class-map type access-control match-all skype
match start TCP payload-start offset 0 size 4 eq 0x17030100
!—Define Policy and attach class-map stack, and service policy to
policy-map type access-control child
class skype

policy-map type access-control parent
class ip_tcp
service-policy child
!—Apply Service Policy to the outside Interface which connects to
the PC running Skype, and attach policy-map-name to service policy

interface FastEthernet1
ip address
ip nat outside
ip virtual-reassembly
service-policy type access-control input parent


Now, when faced with a cisco config, I like taking things “bottom up”. So starting from the bottom section, we see that a service-policy named “parent” is applied in the “input” direction of the FastEthernet1 interface.

Taking is one section up, we see that the “parent” policy-map matches packets of type TCP and also includes a policy called “child”. Again, taking it one section up we see that the “child” policy matches packets of class “skype” and also logs + drops these packets.

The penultimate section from the top defines class ip_tcp, which predictably check the protocol field to make sure the packet is TCP. Then come the skype class, which checks the immediate start of the TCP data portion for the tring 0x17030100

This approach is interesting because it allows for modularity. In the sense, you can use the same class (example ip_tcp) multiple times in the configuration without having to define it every time you want to use the class.  In other words, in the above config we have:

(policy parent) = (class ip_tcp) + (policy_child) = (class ip_tcp) + (class skype)

This allows an admin to write modular config file which should be easier to read and maintain.

I do have a bit of reservations about this system. First of all, its still based on a signature system… so it’s not as “behaviour analysis” oriented as CISCO would like… a security admin will still need to make a packet capture and analyse it to write the above config.

Also, there is an interesting point in page 3 of the guide:

Cisco IOS Flexible Packet Matching (FPM) cannot perform IP fragmentation or TCP flow

If that means “no ip fragmentation reassembly” then that would be weird because we know that one popular method of slipping attacks past IPS and similar devices is to fragment a packet in such a way as to disrupt a signature. For example, if the signature string is


Then the attacker could fragment a packet in such a way as to have (aaab) in one packet, and (bbccc) in another packet. Cisco seems to admit their FPM will not detect this… though presumable the IPS engine will. Still, something to watch out for

Privacy Settings

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.