Understanding Inspection Points in Check Point

I was just about to put some FW Monitor templates on my blog for quick reference when I need to troubleshoot some issues in Check Point but I thought it would be a nice thing to explain this first (for myself too, as I keep forgetting this stuff :D).

When traffic flows through a Check Point Security Gateway (look here if you want to know about the architecture) it has to cross a series of inspection points. This post tries to explain what those inspection points are and how to troubleshoot traffic flows based on the inspection points. The next post will show how to use the FW Monitor.

Edit: Check the bottom of the post for an update version of the inspection point in R80.x

Continue reading

Advertisements

The Fixup Protocol

The Fixup protocol does exactly what a set of MPF commands do. It adds the stateful inspection feature for the specified protocol to the default-inspection-traffic class map referenced in the global_policy policy map. So instead of typing all the MPF commands you only need to type the fixup protocol command followed by the name of the ‘protocol’ to enable application inspection for that protocol. Below is an example which shows how ICMP inspection is added to the global_policy with the fixup command and the regular MPF commands.

ciscoasa(config)# fixup protocol icmp
 OR
ciscoasa(config)# policy-map global_policy
ciscoasa(config-pmap)# class default-inspection-class
ciscoasa(config-pmap-c)# inspect icmp

It also gives you an option to change the default port number for the protocol to be inspected. In the below example, HTTP inspection will be applied to any traffic destined for port number 8080 instead of the default port number of 80.

ciscoasa(config)# fixup protocol http 8080

Note: It ONLY modifies the default global_policy! If you have other policy maps applied to different interfaces, you will need to follow the MPF structure.

If you’re in for a read, the Cisco Documentation has pretty much everything you need to know about this protocol.

Inspecting and Policing OSI Layers 3-4 (Configuration)

This post builds up on the previous one. In this post we’ll be seeing how to create basic Policies for Inspecting/Policing traffic at the OSI Layers 3-4.

Scenario: Traffic from internal hosts destined to the internet needs to be capped at 5mb. They have a web server which is hosted at a different location reachable via the internet. Allow the internal users to be able to ping the web server for testing purposes.

Note: The required ACLs and NAT statements are already in place.

1. Define a Layer 3-4 class-map

First, we need to create ACLs that will be matching the type of traffic on which the policies will be applied. These are NOT interface ACLs, they are only created to match certain type of traffic and refer it in the class-map. (You have to separately define interface ACLs to permit the traffic through the ASA)

ciscoasa(config)# access-list icmp_inspect extended permit icmp 10.1.1.0 255.255.255.0 host 1.1.1.1 log
ciscoasa(config)# access-list ratelimit_inside extended permit ip 10.1.1.0 255.255.255.0 any log

Now define the Layer 3-4 class map by referencing the above ACLs in it. Here we are defining two class-maps. One will be for inspecting ICMP and the other for limiting the bandwidth utilization of the internal hosts.

ciscoasa(config)# class-map ratelimit_class
ciscoasa(config-cmap)# match access-list ratelimit_inside
ciscoasa(config-cmap)# class-map icmp_class
ciscoasa(config-cmap)# match access-list icmp_inspect

2. Define a Layer 3-4 policy-map

Once the class-maps are defined, use policy-maps to define the action to be taken when matching a particular class-map. You can add as many class-maps as you want in a single policy-map but every class-map that you add has to have a specific action assigned to it.

ciscoasa(config)# policy-map company_policy
ciscoasa(config-pmap)# class icmp_class
ciscoasa(config-pmap-c)# inspect icmp

ciscoasa(config)# policy-map company_policy
ciscoasa(config-pmap)# class ratelimit_class
ciscoasa(config-pmap-c)# police input 41943000 4194304
ciscoasa(config-pmap-c)# police output 41943000 4194304

Did you notice how the prompt changes when you add each command? When you create a policy-map it enters the config-pmap prompt, then when you refer a class-map it goes into the config-pmap-c prompt wherein you define an action for the traffic matching that class.

3. Apply the policy-map to the appropriate interfaces

Since we are only concerned with the internal hosts on the inside interface we will apply the policy-map we created to the inside interface only.

ciscoasa(config)# service-policy company_policy interface inside

Verification:

InternalHost#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/27/44 ms


ciscoasa(config)# show service-policy inter inside
Interface inside:
 Service-policy: company_policy
 Class-map: icmp_class
 Inspect: icmp, packet 20, drop 0, reset-drop 0
 Class-map: ratelimit_class
 Input police Interface inside:
 cir 49143000 bps, bc 4194304 bytes
 conformed 5 packets, 570 bytes; actions: transmit
 exceeded 0 packets, 0 bytes; actions: drop
 conformed 0 bps, exceed 0 bps
 Output police Interface inside:
 cir 49143000 bps, bc 4194304 bytes
 conformed 15 packets, 1710 bytes; actions: transmit
 exceeded 0 packets, 0 bytes; actions: drop
 conformed 0 bps, exceed 0 bps

With the packet counts showing some numbers, you can be assured that the traffic is being matched and the class-maps and policy-maps are working as desired. :-)

Modular Policy Framework – The basics

While Access Control Lists filter traffic based on Layer 3 and Layer 4 information, Modular Policy Framework (MPF) augments ACLs with additional functionality such as Deep Packet Inspection (DPI), prioritizing certain traffic flows, limiting bandwidth for certain applications, etc by using Layer 5-7 policies.

Here’s the basic structure of a Service-policy and how it is created and linked with its underlying commands.

Class-maps – The which?

Here you define which traffic is to be matched.

ciscoasa# sho run class-map inspection_default 
!
class-map inspection_default match default-inspection-traffic

Policy-maps – The what?

This is where you define what is the action to be taken when traffic is matched against a specific class-map.

ciscoasa# show run policy-map global_policy
!
policy-map global_policy
 class inspection_default
 inspect dns preset_dns_map
 inspect ftp
 inspect h323 h225
 inspect h323 ras
 inspect rsh
 inspect rtsp
 inspect esmtp
 inspect sqlnet
 inspect skinny
 inspect sunrpc
 inspect xdmcp
 inspect sip
 inspect netbios
 inspect tftp

Service-policy – The where?

Service-policy in MPF is what access-group is to ACL. It specifies where to apply the policy-map, i.e. globally (all interfaces) or on particular interfaces.

ciscoasa# show run service-policy
!
service-policy global_policy global

By default, there is a service-policy applied on all interfaces of the ASA known as the global_policy. This policy applies (policy-maps) certain inspection to the traffic that match the (class-maps) default inspection traffic. The commands used as an example above  are the default configurations for the global_policy.

You can apply only one policy-map per interface apart from the already existing global_policy.

This should cover the basics of MPF. Soon I’ll be posting a lab on this one where we’ll be digging deeper into MPF and it’s configuration.