UnderstandingFlexiblePacketMatching(理解FPM)
Flexible Packet Matching is a new feature that allows for granular packet inspection in Cisco IOS routers. Using FPM you can match any string, byte or even bit at any position in the IP (or theoretically non-IP) packet. This may greatly aid in identifying and blocking network attacks using static patterns found in the attack traffic. This feature has some limitation though.
创新互联公司是专业的鄂托克前网站建设公司,鄂托克前接单;提供网站设计、网站建设,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行鄂托克前网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!
a) First, it is completely stateless, e.g. does not track the state/history of the packet flow. Thus, FPM cannot discover dynamic protocol ports such as use by H.323 or FTP nor cannot it detect patterns split across multiple packets. Essentially, you are allowed to apply inspection per-packet basis only.
b) Additionally, you cannot apply FPM to the control-plane traffic, as the feature is implemented purely in CEF switching layer. Fragmented traffic is not assembled for matching, and the only inspected packet is the initial fragment of the IP packet flow.
c) IP packets with IP options are not matched by FPM as well, because they are punted to the route processor.
d) Lastly, this feature inspects only unicast packets and does not apply to MPLS encapsulated packets.
Configuring an FPM filter consists of a few steps.
(1) Loading protocol headers.
(2) Defining a protocol stack.
(3) Defining a traffic filter.
(4) Applying the policy & Verifying
Let’s look at every of these steps in depth.
Loading a PHDF (optional). PHDF stands for Packet Header Definition file. Those files use XML syntax and define the structure of various packet headers, such as Ethernet, IP, TCP, UDP and so on. They are very helpful in making filtering more structured, as with the PHDFs loaded you may filter based on the header field names and their values, instead of matching fixed offsets in the unstructured packet body. You may load the files into the router’s memory using the command load protocol
Defining a protocol stack (optional). This step uses the PDHFs loaded previously and allows specifying the protocol headers found in the traffic you want to inspect. Using the protocol stack definition induces structure in the packets being inspected. This allows for filtering based on header field values and specifying offsets in the packet relative to the header fields. Additionally, you may define various protocol stacks (e.g. UDP in IP, UDP in GRE in IP) and reuse the same access control policy with various stacks.
You define the protocol stack using the command class-map type-stack match-all
The order of the match statements is important – it defines the actual header stacking along with the “layer x” keywords. The layers are counted bottom up starting at the stack bottom and “layer 1” is the default. The other important thing is that every next match statement should define the protocol specified in the next clause of the previous match statement. This is a basic consistency check illustrated using the arrows in the diagram. Notice that most of the times you could just use a single-protocol stack, as you commonly deal with TCP or UDP protocols encapsulated in IP headers.
Now a few words about the match operator. This command uses the syntax match field
By default, the protocol stack is matched stating AFTER the data-link level header. That is, the first header defined in the stack is match against the header going after the L2 header. In real life, this is commonly the IP header. However, sometime you may want to match the layer2 header fields as well, e.g. Ethernet addresses. To make the protocol stack match starting at L2 level, use the command stack-start l2-start.
At this point, having just stack class-maps you may already apply traffic filtering to the packets matching the configured stack. To accomplish this, create a policy-map of type “access-control” and assign a stack class to the policy-map. For example:
class-map type stack TCP_IN_IP_IN_ETHER statck-start l2-start match field ETHER type eq 0x800 next IP match field layer 2 IP protocol eq 0x6 next TCP ! policy-map type access-control DROP_TCP_IN_IP_IN_ETHER class TCP_IN_IP_IN_ETHER drop
There is basically just a a couple of actions available with the access-control policy-maps: drop and log. You may also use the send-response command under a class to make the router send an ICMP unreachable response.
Of course, using just stack class-maps might be inflexible, as you cannot match the packets payload. You may however use this for filtering based on addresses, protocol flags and so on.
Defining a traffic filter. Traffic filter is defined by means of special class-map of type “access-control” and configuring a respective policy-map of the same type. Using this type of class-maps you can match the protocol field values using the command match field
In addition to matching the protocol header fields, you can match the packet payload at a fixed offset against a pre-defined value, value range, string or regular expression. You may base the offset off the defined protocol header field (e.g. +10 bytes from TCP flags) using the command match start
match start TCP checksum offset 100 size 1 ... match start IP version offset 0 size 1 ...
Of course, this type of offset “basing” is only possible if the respective protocol definition has been loaded and the containing stack-type class map has this protocol defined.
Irrespective of the protocols loaded/defined, you may base the offset from the L2 or L3 packet starts (absolute offsets). For example if the packet is IP in Ethernet, than L2-start is the first bit of the Ethernet header and L3-start is the first bit of the IP header. The command syntax is match start {l2-start|l3-start} offset
match start l3-start offset 0 size 1 eq 0x2 mask 0x3 match start l2-start offset 36 size 5 string ABCDE
Creating an access-control policy-map. You have two options here. You may create a simple access-control policy-map, which has just the basic access-control assigned, without nesting. For example:
class-map type access-control PASSWORD match start l3-start offset 0 size 100 regex ”.*[pP][aA][sS][wW].* ” ! policy-map type access-control DROP_PASSWORD class PASSWORD drop
When using this simple non-nested syntax, you may only use the absolute offsets with the command match {l2-start|l3-start} and cannot reference any protocol header fields.
You may use a more flexible approach, by nesting the filtering policy under a stack-type class-map configured in containing policy-map. This allows for using protocol headers in filtering policy or basing the offsets from the packet header fields. Notice that the nested filtering policy may only use the protocol headers defined in the containing stack class-map. Here is an example that looks for string “TEST” in TCP packets:
class-map type stack TCP_IN_IP match field IP protocol eq 0x6 next TCP ! ! Protocol fields matched in the filtering policy ! must be for the protocols defined in the stack ! class-map ! class-map type access-control match-any FILTER_CLASS match start TCP payload offset 0 size 4 string TEST ! policy-map type access-control FILTER_POLICY class FILTER_CLASS drop ! policy-map type access-control STACK_POLICY class TCP_IN_IP service-policy FILTER_POLICY
Applying the traffic filtering policy. Finally, the access-control policy map should be applied to an interface either inbound or outbound using the interface-level command service-policy type access-control {input|output}
And now, let’s look at a sample task. We would like to filter ICMP echo packets with the stings “AAAA” inside them, encapsulated inside IPIP tunnel. Here is the diagram for the testbed scenario:
And now, the configuration to be applied to R6′s Fa0/0:
load protocol system:fpm/phdf/ip.phdf load protocol system:fpm/phdf/icmp.phdf load protocol system:fpm/phdf/ether.phdf ! ! Three protocols in stack: Ether/IP/IP ! class-map type stack match-all ICMP_IN_IPIP_IN_ETHER stack-start l2-start match field ETHER type eq 0x800 next IP match field layer 2 IP protocol eq 4 next IP match field layer 3 IP protocol eq 0 mask 0xFF next ICMP ! ! Access-Control Policy, matches on the ICMP payload ! class-map type access-control match-all ICMP_ECHO_STRING_AAAA match field ICMP type eq 8 match start ICMP payload-start offset 0 size 256 regex ".*[aA][aA][aA][aA].*" ! ! Access-Control Policy-Map ! policy-map type access-control LOG_ICMP_ECHO class ICMP_ECHO_STRING_AAAA log ! ! Outer policy map, matches the protocol stack. ! policy-map type access-control STACK_POLICY class ICMP_IN_IPIP_IN_ETHER service-policy LOG_ICMP_ECHO
Next, a basic verification of our configuration. We send ICMP packets loaded with AAA characters (ASCII code 0×41) from SW1 to SW2 and see if they match the policy-map in R6:
Rack1SW1#ping 192.168.0.8 data 4141 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.0.8, timeout is 2 seconds: Packet has data pattern 0x4141 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms Rack1SW1# SCRack9AS>6 [Resuming connection 6 to R6 ... ] Rack1R6#show policy-map type access-control interface fastEthernet 0/0 FastEthernet0/0 Service-policy access-control input: STACK_POLICY Class-map: ICMP_IN_IPIP_IN_ETHER (match-all) 5 packets, 670 bytes 5 minute offered rate 0 bps Match: field ETHER type eq 0x800 next IP Match: field layer 2 IP protocol eq 4 next IP Match: field layer 3 IP protocol eq 0 mask 0xFF next ICMP Service-policy access-control : LOG_ICMP_ECHO Class-map: ICMP_ECHO_STRING_AAAA (match-all) 5 packets, 670 bytes 5 minute offered rate 0 bps Match: field ICMP type eq 8 Match: start ICMP payload-start offset 0 size 256 regex ".*[aA][aA][aA][aA].*" log Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any
A quick final notice on use the logging statement with the access-control policy-maps. The rate-limiting mechanism for those is the same as used for the access-lists, and configured using the commands ip access-list log-update|logging.
Further Reading:
Flexible Packet Matching
FPM Deployment Guide
PS
The configuration in this post have been implemented and tested using IOS 12.4(24)T on a 2811 ISR. You may encounter bugs and errant behavior in earlier IOS releases, and I suggest you always using the latest image for FPM implementation.
From:INE
分享标题:UnderstandingFlexiblePacketMatching(理解FPM)
当前地址:http://scyanting.com/article/ppjggd.html