How to completely deny a specific url-category?

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.

How to completely deny a specific url-category?

L3 Networker

When you setup url-filtering you can choose from one of the following actions:

Allow (permit access)

Block (block access and notify user)

Continue (block access and notify user and let user continue anyway if they want to)

Override (same as continue but password is needed to continue)

Alert (only log the entry)

The problem I have is that I have put web-advertisements as "block", the downside is that the user will get the blockpage instead (which is better than the ads but still somewhat odd, specially for the users who not always understands that the page they are visiting are allowed but the ads are not).

Are there any plans to add an action such as "deny" which would just drop the traffic (perhaps send RST to shutdown the transaction)?

Or how can I accomplish to completely deny requests if they match url-category "web-advertisements" (or whatever category one might want to deny in a way so that the client wont get any block response-page at all)?

8 REPLIES 8

L6 Presenter

Here's a sample custom block page that keyed on the category name and served the corresponding message.    If you look at the sample html code, you can see categories like games, travel, & kids:

case 'games':
            document.getElementById("warningText").innerHTML = "Do you really need to play games all day?";
            break;       
        case 'travel':
            document.getElementById("warningText").innerHTML = "Where do you really want to go?";
            break;       
        case 'kids':
            document.getElementById("warningText").innerHTML = "you're too old for this.";
            break;      

You can customize this to match on 'web-advertisements' and serve a blank message, like a space.  Give this a try.

Ooops sorry for the double post.

I thought I had already asked this in a thread but I wasnt able to locate it (which made me think I didnt asked) so I asked again, the original thread https://live.paloaltonetworks.com/thread/1266?tstart=0

Thank you for the workaround, ill try it out along with a request to our support for a deny function (perhaps a deny grouped by sending empty data to the client).

Reuse of topics 🙂

Does 4.1 support some kind of "TCP-RST" (or just a drop) for specific url-categories?

As an example if I want nothing to be sent to the clients if they request a page that belongs to the category "Web Advertisements".

Because I assume that setting appid:web-browsing and url-category:web advetisements (block) along with a deny in the end of this rule the client will still be served the block page or in which order is the url-category thinging happening in the internal flow of a PaloAlto-device?

The TCP reset is supported for application blocking but unfortunately, not for URL filtering.

You could create a HTML response page that contains a 1-pixel image and use a redirect method in the URL block page.  When users visit a site for category "Web Advertisements", redirects them to the 1-pixel image.

Thanks.

What do you think is the probability that if I file this as a feature request (TCP-RST for url-categories) this can be implemented (this somewhat feels that if this by design would be possible then this would have already been implemented)?

I don't think you want a TCP reset nor a simple drop of packet.  If the browser receives a tcp-reset, the browser would display the default TCP ERROR page and the user would see this error embeded on the web page.  If the browser does not receive any reply (packets are simply dropped), it would display a different error page like a TCP Timeout, or Server Not Responding error page.  I believe in both cases, the browser will react and display an error page.

Thanks,

Well thats what it does today when you set url-category:advertisements to block, the users get this custom block page instead and starts asking questions about that instead of just a white/empty page (this looks somewhat funny when you visit most sites who does iframe and shit to get ads on their pages these days).

And setting the blockpage to a white (empty) page wont help since you cannot have several different block pages in PA (because I want the information to reach the client for other blocked categories - the custom page brings some data for the tech to search on along with information to the client how to get in contact with support etc).

Using a deny based on url-category should work the same way as if you manually set the adserver hostname in your hosts file to point to 0.0.0.0 or 127.0.0.1 - the browser cannot reach the adcode and will therefor not display any ads (compared to when the PA today sends a custom block page instead).

I agree with you that deny, tcp reset, and packet drops will produce the same result where the users will see errors on the web page.  That's why I think a request to do tcp reset/drop is not necessary as it will not produce the desired result.

If we set the adserver hostname to 0.0.0.0, the contents will not be displayed but there will be red X's where the contents are supposed to be.  So the result is that users will see broken links via the red X's, think something is wrong, and call the helpdesk.

While the method of 1-pixel image is not perfect, it is the best option.  You don't have to set it for all category, just the ads category.

Thanks.

  • 4565 Views
  • 8 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!