Whitelist rule - confusion on URL filtering...

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Whitelist rule - confusion on URL filtering...

L4 Transporter

We have a whitelist rule that allows out http/https as a service and "any" as the application.

All the URL categories in the profile applied to that rule are set to "Block" and there are some URLs in the whitelist.

The destination address is set to "any".

Today we noticed someone hit that rule using SSH on port 443 and it was allowed out.

I'm guessing that I'd misunderstood how the PAN applies URL filtering and that only certain applications hit URL filtering and other applications simply hit the rule and would be allowed out so long as they were using port 80 or 443?

Could someone please explain how the Palo Alto knows whether to apply URL filtering or not? Smiley Happy

6 REPLIES 6

L3 Networker

Seems you should have a deeper look on your rule set and begin to use the features you paid for Smiley Wink

If you allow any application on port 80 and 443 and only apply an URL policy, you can not controll the traffic in your network.

You allow anything that can use port 80 oer 443 (and thats more or less everything you might not want to allow) :smileyplain:

The URL filter belongs to the content ID engine while the application "filter" belongs to the APP ID engine.

URL filters only check the URL used in the traffic and nothing else. This is matched to traffic to websites accessed through HTTP and HTTPS.

So SSH traffic will not be filtered because the SSH might only be used to tunnel other applications and there is no URL to match to. And SSH on 443 is decrypted so the firewall can not see what happens in the tunnel. You have to use decryption to look in the session and take action.

If you only allow web-browsing, no one can use SSH to tunnel other application traffic.

Maybe you should first try to use application "web-browsing" instead of "any" with service "application-default" or "service_http and service_https" (wit app default 443 is not allowed and needs a second rule but port 8080 is allowed).

HTH

L3 Networker

AFAIK URL Filtering only applies to web-based applications.

L4 Transporter

Thanks both, and then we're into that lovely game of having to know explicitly what you want to either allow or block when I might want to say "I don't care what it is so long as it's going to www.vmware.com".

L3 Networker

In this case you could use address group or address object for the destination in the policy and use app=any, service=80 and 443

L7 Applicator

If I understand you situation correctly, you do need to change the application from "any" to "web-browsing" for this rule.  You seem to want to only permit web browsing with your url policy on ports 80 and 443.  This would prevent then ssh on 443 being permitted by this rule.

For the port 8080 web sites you can do the same using the application web-browsing to prevent other uses of the port.

Steve Puluka BSEET - IP Architect - DQE Communications (Metro Ethernet/ISP)
ACE PanOS 6; ACE PanOS 7; ASE 3.0; PSE 7.0 Foundations & Associate in Platform; Cyber Security; Data Center

As i understand the OP he wants to allow any application as long as it goes to a special (whitelisted) url.

So in this case he should use application "any", service "http and https" (so only port 80 and 443) and destination "whitelisted address / address group".

It just takes some work to specify the destination address group if there are multiple IP addresses to add.

  • 3756 Views
  • 6 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!