cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2198
Views
0
Helpful
4
Replies

ZBF: Using "policy-map type inspect http" to inspect and filter certain HTTP-hosts

Hello!

I have a very simple (so I thought) requirement, which I want to solve with ZBF. Although it seems simple, I can't get it to work with Cisco IOS Zone-Based Firewalling (ZBF).

The requirement is to simply filter HTTP-requests to a certain server. Only a certain hostname in the request should be allowed. The server serves also other hostnames (= vhosts), but these should not be allowed.

ZBF seems to have the necessary capabilities for this simple task.

First you have to define a regex + class-map to match the hostname:

parameter-map type regex SERVERNAME.REGEX

pattern .SERVERNAME

!

class-map type inspect http match-all SERVERNAME.SET

match request header host regex SERVERNAME.REGEX

Then, you can define a http inspection policy, which matches this class:

# Example 0

policy-map type inspect http SERVERNAME.ONLY

class type inspect http SERVERNAME.SET

  reset

Example 0 does exactly the opposite of what I want to achieve - it resets the connection to the vhost I'd like to pass through, and allows the rest (which I would like to block). It's just a test to confirm the regex is working as expected.

How can I turn this around to allow the specific class, and deny everything else?

# Example 1

policy-map type inspect http SERVERNAME.ONLY

class type inspect http SERVERNAME.SET

  allow

class type inspect http HTTP.ANY

  reset

For Example 1 I configured a class-map which matches anything, and configured the policy-map to reset this class (so resets anything). Only the class above (SERVERNAME-SET) should override this and allow the traffic. The problem is - it doesn't work. Everything is reset. It seems that ZBF evaluates all classes within the policy-map, no matter if a previous clause matched or not. The connection is always reset, no matter of the previous clause.

# Example 2

policy-map type inspect http SERVERNAME.ONLY

class type inspect http HTTP.ANY

  reset

class type inspect http SERVERNAME.SET

  allow

In Example 2 i just swapped the two class entries within the policy-map. It didn't change anything. It seems that independent of the order, "reset" is dominant over "allow".

It would help a lot, if it was possible to define negative matches within a class-map:

class-map type inspect http match-all SERVERNAME.NOTSET

match not request header host regex SERVERNAME.REGEX

This is possible on the ASA. While the configuration syntax is very similar in IOS for ZBF, it is not possible there (I use IOS

153-3.M).

Any other ideas? I would really appreciate it, because I'd need this simple functionality.

Thanks a lot,

Florian

4 Replies 4

Julio Carvajal
VIP Alumni
VIP Alumni

Hello,

On the Any class match you should be matching any other website (pattern *)

I see what you mean but it should be like this:

policy-map type inspect http SERVERNAME.ONLY

class type inspect http SERVERNAME.SET

  allow

class type inspect http HTTP.ANY

  reset

What do you think?

For more information about Core and Security Networking follow my website at http://laguiadelnetworking.com

Any question contact me at jcarvaja@laguiadelnetworking.com

Cheers,

Julio Carvajal Segura

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

Hi jcarvaja!

I don't understand. Isn't your suggestion exactly how I tried it in my example 1?

# Example 1

policy-map type inspect http SERVERNAME.ONLY

class type inspect http SERVERNAME.SET

  allow

class type inspect http HTTP.ANY

  reset

I can report that this does not work as expected. In this configuration, *everything* is dropped. "HTTP.ANY" matches any HTTP-request (as expected), but the policy-map then resets *every* HTTP-request (not as expected). Obviously the policy-map doesn't exit evaluation when it hits it's first match.

It has to be done differently, but how?

Greetings,

Florian

Hello Florian,

LOL

Yeah, same thing (a hard night I guess)

Try this:

Let's say the website is google

parameter-map type regex Google

  pattern \.google\.com

Then use the same configuration that you and I agree with

So can you provide the entire configuration for the patterns, L7 policies and class-maps and L4 policies and class-maps (Missing some information)

The match not is only available for the uri not for the header host  (at least in 15.1(4) )

For more information about Core and Security Networking follow my website at http://laguiadelnetworking.com

Any question contact me at jcarvaja@laguiadelnetworking.com

Cheers,

Julio Carvajal Segura

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

Hello jcarvaja,

the complete config from top to bottom (reverse way of configuring) is:

policy-map type inspect SERVICES.ACCESS

class type inspect PROTO.HTTP

  inspect

  service-policy http SERVERNAME.ONLY

class type inspect PROTO.HTTPS

  inspect

class type inspect PROTO.SSH

  inspect

class class-default

  drop log

!

policy-map type inspect http SERVERNAME.ONLY

class type inspect http SERVERNAME.SET

  allow

class type inspect http HTTP.ANY

  reset

!

class-map type inspect http match-all SERVERNAME.SET

match request header host regex SERVERNAME.REGEX

class-map type inspect http match-any HTTP.ANY

match request uri regex HTTP.ANY

!

parameter-map type regex SERVERNAME.REGEX

pattern .servername\.local

parameter-map type regex HTTP.ANY

pattern .*

As described, this resets *every* connection. Again: If "allow" and "reset" is swapped within the policy-map, it then works as expected (but the other way round, unfortunately). Which means: In this case, the only host which should work is correctly reset, while all other connections (which should be blocked) are allowed. This leads to the conclusion: "reset" overrides any other action in the policy-map. Unfortunately, I have no idea how I can achieve the simple task with these tools.

You're right regarding that "match not" supports uri only as a parameter in IOS. I tried of course to use it to solve this problem. This could make it possible to match the right servername, because an URI to my knowledge contains the servername. But, sadly, in my testings, I found that the "uri"-variable doesn't really contain the whole "uri" - just the path/request *after* the servername.

Regards,

Florian

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: