What's the difference between ACL and FPM? In detail, please, but in a simple, easy-to-understand way.
2 Answers
I assume you're asking to compare Cisco Access Control Lists (ACL) and Cisco Flexible Packet Matching (FPM).
Packets contain a number of fields, such as:
- IP source address
- IP destination address
- TCP Source Port
- TCP Destination Port
- UDP Source Port
- UDP Destination Port
ACLs
Traditional ACLs can only permit or deny based on a limited number of fields (some of most commonly used fields are listed above); these fields are well-known throughout the internet. However, traditional ACLs cannot filter inside the payload of an IP packet, for instance if someone wanted to block certain kinds of Tibco RV UDP Multicast payloads, it's impossible to do so with traditional ACLs. Traditional ACLs look like this...
! Note: this ACL is only granular to a TCP port
access-list 102 permit tcp any any eq 80
access-list 102 permit tcp any any eq 443
access-list 102 permit tcp any any eq 23
access-list 102 permit tcp any any eq 25
access-list 102 permit tcp any any eq 110
access-list 102 deny ip any any log
!
interface FastEthernet0/0
ip access-group 102 in
FPM
However, FPM can block / allow on any bit inside a single packet header or payload1, as long as there is a valid PHDL file loaded for the field that needs to be blocked or allowed. FPM can define a hierarchy of classes and policies to implement very granular control over the packets that are allowed or denied.
This is an example policy, taken from the FPM docs, which matches a UDP packets sent by the Slammer Worm. It would be impossible to block the hosts infected with the Slammer Worm using ACLs unless you block both good and bad SQL traffic by individual IP source addresses.
load protocol disk2:ip.phdf
load protocol disk2:udp.phdf
!
class-map type stack match-all ip-udp
description "match UDP over IP packets"
match field ip protocol eq 0x11 next udp
!
class-map type access-control match-all slammer
description "match on slammer packets"
match field udp dest-port eq 0x59A
match field ip length eq 0x194
match start l3-start offset 224 size 4 eq 0x4011010
!
policy-map type access-control fpm-udp-policy
description "policy for UDP based attacks"
class slammer
drop
!
policy-map type access-control fpm-policy
description "drop worms and malicious attacks"
class ip-udp
service-policy fpm-udp-policy
!
interface GigabitEthernet0/1
service-policy type access-control input fpm-policy
End Notes:
1 FPM's limitation of inspecting a single IP packet is non-trivial, since that means it's possible to circumvent FPM if an attack manages to split the attack signatures across multiple IP fragments, or TCP packets (since the TCP stream is reassembled at the receiver). That said, it's a still very powerful tool as long as you understand the limitations of the technology.
Access Control Lists (ACL) are network statements that permit or deny access to a given set of conditions based on the first match.
Standard ACLs are the oldest forms of ACLs and operate in an incredibly broad manner. They only match based on a single IP address, and because of this limited functionality, they operate much faster other types under most circumstances; this is not taking into account hardware-based acceleration.
Suppose we want to limit access to a single host, below is what we would do.
rtr(config)# access-list 1 permit 10.1.1.100 0.0.0.0
This ACL functionality is refined even further with the introduction of Extended ACLs. This allows you to specify source and destination IP addresses, as well as port numbers and a few other parameters (e.g., tos, precedence, etc.). The added functionality this provides also comes with a downside: increase overhead and packet inspection.
Suppose we wanted to refine the scenario above even further to limit this host to a single IP and allow HTTP access.
rtr(config)# access-list 199 permit tcp host 10.1.1.100 host 192.168.1.1 eq 80
Flexible Packet Matching (FPM) is really the newest ACL that’s available. The primary focus is for intrusion prevention/detection because of its extensive matching characteristics. You can seemingly define any parameter inside a packet for inspection. Like anything with additional features though, this comes with a significant performance toll. I grabbed this next example from Cisco’s documentation on FPM and modified it to match the relevant fields.
Suppose we want to refine the above restriction even further. We want to allow access from that single host, and prevent any of those ‘trusted’ users from passing malicious queries (specifically "GET \%") to the single host.
rtr(config)# load protocol flash:ip.phdf
rtr(config)# load protocol flash:tcp.phdf
rtr(config)# class-map type stack match-all ip_tcp
rtr(config-cmap)# description "match TCP over IP packets"
rtr(config-cmap)# match field ip protocol eq 0x6 next tcp
rtr(config-cmap) # description "Match HTTP Exploit Packets"
rtr(config-cmap)# match field tcp dest-port eq 80
rtr(config-cmap)# match field ip source-addr eq 10.1.1.100
rtr(config-cmap)# match start tcp payload-start offset 0 size 32 regex ".*GET \%"
rtr(config)# policy-map type access-control fpm_tcp_policy
rtr(config-pmap)# description "policy for TCP packets"
rtr(config-pmap)# class http_psirt_class
rtr(config-pmap-c)# drop
rtr(config)# policy-map type access-control fpm_policy
rtr(config-pmap)# description "policy HTTP Get exploitation"
rtr(config-pmap)# class ip_tcp
rtr(config-pmap-c)# service-policy fpm_tcp_policy