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.
policy-map type access-control child
class skype
log
drop
!——–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 policyinterface FastEthernet1
ip address 128.107.163.73 255.255.254.0
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
reassembly.
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
aaabbbccc
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
David Vassallo's Blog 