Regular expressions in URL filtering

cancel
Showing results for 
Search instead for 
Did you mean: 

Regular expressions in URL filtering

Not applicable

Any chance there will be support for regular expressions in URL block/allow lists and custom URL groups? It is annoying to have to enter both a base domain name and the domain name with "*." to completely allow/deny a domain.

It would be much preferred if I could put a single line that covered both "exampledomain.com" and "www.exampledomain.com" and gain the additional ability to do something like allow/deny exampledomain.com/examplepath[0-9]/* should I want to do so.

From my understanding this isn't currently implemented, but I would love to see it as a feature in the future.

7 REPLIES 7

L4 Transporter

Hello,

currently there is no support for regualar expressions in url filtering.

There is also not a plan to support regular expressions in url filtering as it would be very resource intensive/expensive.

thanks

What about making the PAN to automatically include subdomains when you create the basedomain in the urlfilter?

So you only have to write:

youtube.com

instead of:

youtube.com

*.youtube.com

I agree with rps... We have a huge list of custom URL's that we want to block and it would make it twice as huge to have to write both the domain name and the wildcard for the subdomains.

I'm resurrecting this post as this is something that has always bothered me about PAN OS.


@kbernard Sometimes it doesn't only double.  As an example, I've seen content delivery networks and many popular social networking sites that have a ridiculous amount of nested sub domains.  In these cases you will find yourself creating multiple "per period delimited wildcard" entries for every child of a zone.  As an example consider the following:


pdf.downloads.cd.foo.com


To ensure you allow each sub domain that could potentially exist as a descendant of foo.com you would need the following:


foo.com

*.foo.com

*.*.foo.com

*.*.*.foo.com


As a suggestion to Palo Alto Networks, Why not follow the RFCs that govern DNS, they certainly seem applicable in this situation.

When dealing with wildcard resource records, the "*" label will match any descendant of <anydomain> while not affecting <anydomain> itself.


@swhyte The "limited wildcard" delimited by a period label "." seems unnecessary and TBH more resource intensive/expensive than the alternative.

@rroberts - I agree about moving to the RFC standard. When we used Websense we just entered the root domain and the product took care of the primary domain and all subdomains automatically. I know this could be potentially problematic if you wanted to block the main domain only, or some combination of it and some of the subdomains, but this can easily be worked around with exceptions/whitelisting.

Is there a way around this?

what we see is that when we block *.*.foo.com - All surfing over the internet is being blocked.

The multi wildcard in a *.* format is unsupported and it would block all raffic if added to a block list.

The example you gave shold be *.foo.com

~Phil

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!