Traffic inspection best practices

Colin Higgins — Mon, 11 Mar 2019 23:03:06 GMT

Since the ASA, by default, has a global inspection policy enabled that uses the default-inspection-traffic class-map, what is the best way to apply additional policies on the system while retaining this global policy?

Let's say I want the system to take a closer look at http traffic.

Should I

1. Take it out of the policy-map global-policy

2. Create a new policy based on http class-maps

example:

class-map type inspect http match-any MyHTTPClass_drop

match req-rsp-content-type mismatch

match request uri length gt 1024

policy-map HttpPolicy

class MyHTTPClass_drop

drop connection

service-policy MyHTTPClass_drop interface outside

So the idea here is to leave the default policy active for all interafaces (global) but use custom policies applied to individual interfaces for specific types of traffic. Is this how it is typically done?

Also, what happens if I leave http inspection in the policy-map global-policy along with the new policy? Which one takes precendence? Does the ASA look at he global policy before looking at the interface policy? Or better yet, what if the interface policy is enable on the outside interface (like above) but the globsal policy is enable everywhere? Will the traffic coming from inside to the outside hit the global policy and then the ASA will ignore the outside interface policy?

Traffic inspection best practices

Maykol Rojas — Tue, 08 May 2012 00:10:14 GMT

Collin,

Basically we need to wrap it up and make differences between the class maps and policy maps that exists.

There are mainly 2 types of Class maps and Policy maps. The one that carry layer 3/4 (well know as IP, TCP/UDP) and the layer 7 inspections (the one that actually look into the payload of the packet and make sure the fields are correct).

Now the ASA by default comes with a default inspection policy with its own default inspection class map. If you look at the Inspection default class map, it just matches some of the well know protocols with their respective well known ports and on the policy map it actually does the inspect (which is just basically going to check if for example FTP actually does come in port 21).

Goin back to your question and example that you put

class-map type inspect http match-any MyHTTPClass_drop

match req-rsp-content-type mismatch

match request uri length gt 1024

policy-map HttpPolicy

class MyHTTPClass_drop

drop connection

This is not correct, we need to define first what we want to check and then where we are going to apply it. For example, starting with the layer 7 is correct, cuz we decide and check what we want to verify on the HTTP packet, so:

class-map type inspect http match-any MyHTTPClass_drop

match req-rsp-content-type mismatch

match request uri length gt 1024

Then, after the layer 7 is created, then we apply an action to it using a Policy map of Layer 7, like this:

Policy-map type inpspect http URI-AND-MISMATCH

class MyHTTPClass_drop

reset log

We have defined what we are going to do with the content type mismatch and if an URI exceeds the 1024 size. Now, we need to apply this, we need to tell the firewall where to look for this information (By that I mean what port, cuz it gives you the flexibility of Match this information on a non standard port, that is where layer 3/4 Information class maps kick in)

There are 2 ways, on the default policy map or you can create a custom one and apply it on an interface, I am going to show you both, first the default, basically it will be like this:

Policy-map global_policy

class class_default-inspection-traffic

inspect http URI-AND-MISMATCH

There in the layer 3/4 policy map, under the class default, the ASA knows already that when you put the inspect http on the class default, you are looking for http data on port 80. Addtionally you can add your custom layer 7 inspection policy which is going to look for the URI and request-respond mismatch under the HTTP protocol.

The other way will be almost the same, but instea applied on an interface and with the class maps and policy maps of Layer 3/4 configured by you

class-map HTTP

match port tcp eq 80

Policy-map HTTP

class HTTP

inspect http URI-AND-MISMATCH

Service-policy HTTP interface inside

That would be basically it. Now going back to your questions.

1-So the idea here is to leave the default policy active for all interafaces (global) but use custom policies applied to individual interfaces for specific types of traffic. Is this how it is typically done?

R/ Class default inspection will have you fix ports-to-protocol mappings as you saw. If you want to be very granular, saying matchinn an access list or a non standard port, you cannot do that on the default class map as it only supports inspection option. That is where an when you need to create granular inspections and class maps, hence forcing you to configure per interface if you will. Depends most of all, on how granular you wan to be.

2-Also, what happens if I leave http inspection in the policy-map global-policy along with the new policy? Which one takes precendence?

R/Basically first it goes to the ones applied on the interface and then the global policy, you can only have one policy per interface and one global policy.

3/Does the ASA look at he global policy before looking at the interface policy?

No, first it goes to the interface one and then the global.

Will the traffic coming from inside to the outside hit the global policy and then the ASA will ignore the outside interface policy?

Policy just applies and action to the traffic defined on the class map, it will go per interface looking for a policy, if it finds a match, it applies the action, if not, it will look for the global.

A bit long explanation and I am sorry, but hope it makes some sense. Here, this explains how to apply HTTP inspection polices (both layer 3 and 7) it will give you better guidance and understanding.

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080aee442.shtml

Mike

Traffic inspection best practices

Colin Higgins — Tue, 08 May 2012 14:06:58 GMT

Mike: great answer! Exactly what I was looking for.

I would also add, that I think at the end of the day, the ASA follows this procedure in regards to processing traffic:

1. NAT/PAT

2. Access list

3. QoS ingress policy

4. Set connection limits and TCP options

5. Send traffic to the CSC module

6. Application inspection (interface, then global)

7. Send traffic to the IPS module

8. QoS egress policy

9. QoS priority handling

10. QoS traffic shaping

Traffic inspection best practices

Maykol Rojas — Tue, 08 May 2012 15:49:12 GMT

Collin,

I am glad that it helped you to understand a bit more about Modular policy framework. Just one thing, the ACL goes first, as if the packet is denied it wouldnt process the rest of it.

Mike

topic Traffic inspection best practices in Network Security

Traffic inspection best practices

Traffic inspection best practices

Traffic inspection best practices

Traffic inspection best practices