topic Re: How to completely deny a specific url-category? in General Topics

How to completely deny a specific url-category?

rps — Thu, 04 Mar 2010 18:15:16 GMT

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)?

Re: How to completely deny a specific url-category?

rmonvon — Thu, 04 Mar 2010 19:43:11 GMT

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.

Re: How to completely deny a specific url-category?

rps — Fri, 05 Mar 2010 05:17:46 GMT

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).

Re: How to completely deny a specific url-category?

mikand — Sun, 08 Jan 2012 16:24:45 GMT

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?

Re: How to completely deny a specific url-category?

rmonvon — Mon, 09 Jan 2012 14:20:19 GMT

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.

Re: How to completely deny a specific url-category?

mikand — Tue, 10 Jan 2012 07:11:49 GMT

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)?

Re: How to completely deny a specific url-category?

rmonvon — Tue, 10 Jan 2012 20:23:41 GMT

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,

Re: How to completely deny a specific url-category?

mikand — Tue, 10 Jan 2012 22:06:34 GMT

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).

Re: How to completely deny a specific url-category?

rmonvon — Wed, 11 Jan 2012 13:40:55 GMT

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.