URL Filtering - Where to implement it

So today was very interesting. In my role, I manage our firewalls (palo) and we have URL filtering enabled on it. It's been this way for a long time. Today, a user had an issue with a website being filtered, but it turned out not to be by our firewall. The server team just recently deployed a new version of AV, and enabled URL Filtering on the clients. Long story short, it started a mini war between the two Directors of each area. I can't lie, it was a little fun to watch. What added to it was the category that was blocked, was not a category that we block on the firewall.

The argument from my Director (network) was, we force users to connect to VPN (full tunnel), so even if they are remote, their internet traffic was going through the firewall. The server side's argument was, they feel the extra protection is good, and for those occasions where someone either doesn't connect to VPN (maybe account locked, or expired password, or disabled service somehow), those machines are no longer protected from the firewall, but will be with AV.

While I see both sides and think extra protection is good, this could lead to some issues/inconveniences. For example, if a certain blocked site has a legitimate business purpose, it will need to be unblocked from both sides.

So my question to TE is....who was right, and how would you implement it?

If it was my decision, I probably wouldn't do url filtering on either AV or firewall. I'd probably opt for a proxy, like Cisco Web Security or <add other vendor here>

I definitely do something similar to you, URL filtering on the borders using Palo Alto

you can always add extra layers on the end point like HIPS, more AVs, DLP client, etc....it gets messy to manage though and does slow things down. Is it necessary to have URL filtering somewhere other than the border? I'm not sure...I don't think so, but curious to see what everyone thinks

The best practice standard to filter URL's is at the border, usually that means either the firewall or a proxy. I've worked in environments where we did filtering at the firewall and now at an environment where we do filtering at the proxy. Anyway, thats the best practice since those are the devices that first "see" or capture the traffic. You want to limit unwanted content close to your perimeter not after it has gone through.
Now, the AV filtering is good as a backup to catch anything that passes those 2 devices above. Once it has been identified it has to be send to the firewall guys so they can change the firewall policies and update with the mew url that needs filtered. Once that has been done then it will no longer be filtered at the AV. This is the best approach in my opinion. A layered defense and not a war between where it should be blocked. Ultimate you would want to block as much as possible at your perimeter not after.

The best practice standard to filter URL's is at the border, usually that means either the firewall or a proxy. I've worked in environments where we did filtering at the firewall and now at an environment where we do filtering at the proxy. Anyway, thats the best practice since those are the devices that first "see" or capture the traffic. You want to limit unwanted content close to your perimeter not after it has gone through.
Now, the AV filtering is good as a backup to catch anything that passes those 2 devices above. Once it has been identified it has to be send to the firewall guys so they can change the firewall policies and update with the mew url that needs filtered. Once that has been done then it will no longer be filtered at the AV. This is the best approach in my opinion. A layered defense and not a war between where it should be blocked. Ultimate you would want to block as much as possible at your perimeter not after.

I think this sums it up exactly. "A layered defense and not a war". Couldn't say it any better.

I think the big problem is their AV filtering rules didn't match the firewall rules, which needs to happen first. I think that cause a misunderstanding, where my director feels if both are enabled, theirs will activate first. Unfortunately, this argument happened in a room, so I decided not to address it until tomorrow.

We're an MSP and sell our clients web security at the DNS level (Cisco Umbrella). We set all DNS forwarders to OpenDNS DNS servers and there is a lightweight client that we install on client workstations that gives always on dns filtering. It's very easy to manage, intuitive, and just works. I think it's the best solution for SMBs... which is most of our client base.

We've had bad experiences with URL filtering not blocking URLs when it should at the firewall level (Cisco Firepower) because of "bugs" so we are trying to move all of our clients off of that at the moment.

We're an MSP and sell our clients web security at the DNS level (Cisco Umbrella). We set all DNS forwarders to OpenDNS DNS servers and there is a lightweight client that we install on client workstations that gives always on dns filtering. It's very easy to manage, intuitive, and just works. I think it's the best solution for SMBs... which is most of our client base.
.

I'd say so! I've also looked at Umbrella, pretty cool product. It was out of budget though.

Looks like my thinking was wrong. My expectation was, if both AV URL filtering and Firewall filtering set say the category of "Alcohol" to block, the firewall would catch it first. This is not the case. I just did a test and my AV is actually displaying the block message.

Unless security is not a priority, I wouldn't do URL filtering on a Firewall or AV. Couple reasons for this:
- Firewall URL filtering is URL filtering "lite." They rarely have the ability to make dynamic decisions based on the content of the page when they don't know the URL reputation. It's URL filtering lite for a reason. If you look at MIERCOM tests with firewalls vs dedicated web content servers, you can see how much a firewall gets spanked hard in comparison
- DLP integration on a firewall sucks. Same with AV for the most part
- Most stuff on the interwebs is getting encrypted. You can push more security to the endpoint but trying to decrypt everything at the firewall will make it cry. PAN doesn't have a dedicated chipset for decryption like A10, F5, Firepower (not active in Firepower yet tho - full disclosure), etc. I did a recent episode of The Network Collective on this subject: Episode 4

I'd say so! I've also looked at Umbrella, pretty cool product. It was out of budget though.

Umbrella is awesome and it has some awesome points that both dedicated web content servers - i.e. being able to use analytics to determine how new a domain is, tracking IPs to see if other malicious domains were recently registered to the same IP, tracks malicious behavior over time, etc. It also doesn't do certain things a dedicated proxy can do (i.e. DLP integration). Cool stuff tho

Unless security is not a priority, I wouldn't do URL filtering on a Firewall or AV. Couple reasons for this:
- Firewall URL filtering is URL filtering "lite." They rarely have the ability to make dynamic decisions based on the content of the page when they don't know the URL reputation. It's URL filtering lite for a reason. If you look at MIERCOM tests with firewalls vs dedicated web content servers, you can see how much a firewall gets spanked hard in comparison
- DLP integration on a firewall sucks. Same with AV for the most part
- Most stuff on the interwebs is getting encrypted. You can push more security to the endpoint but trying to decrypt everything at the firewall will make it cry. PAN doesn't have a dedicated chipset for decryption like A10, F5, Firepower (not active in Firepower yet tho - full disclosure), etc. I did a recent episode of The Network Collective on this subject: Episode 4

Security is a priority, we had Websense in the past, but to save costs, we went with firewall url filtering.

I know what you mean. Although, I've been lucky and haven't had any problems with performance from decryption. Palo's new appliances are supposed to have even better decryption performance. I haven't looked much at them yet though.

I'm behind on the Network Collective episodes, but yours is on my list. I want to watch that EIGRP one too.

Agreed that URL filtering on traditional firewall is light...but nextgen(I hate this term) 'firewalls' have good capabilities. I find Palo Alto's Firewall(really IPS/IDS) URL filtering to be top notch.

DLP is another topic and yes it shouldn't be on the firewalls for sure

I wouldn't say it's top notch. It's basically using Brightcloud to do basic URL filtering and no dynamic content identification. Last report stacking it up against dedicated proxies had it at like 67% effective in comparison to Websense's 98%. If it's basic "gets a simple job done," then yes... a firewall works for that. If it's top security (or what I consider would consider "top notch"), it wouldn't be on the firewall

I'm a little confused, so I find to be doing what most proxies do. you can manually add urls / edit to filer them on demand, and they pull lists of categorisations of websites that's dynamically updated from their website. I also submit urls and request re-classifications of websites. I haven't compared it with dedicated proxies, but I dealt with zScalar and that thing was a pain to manage and get to play well with f5.

What I like about Palo Alto is that it's the closest to a one device do it all. Fits the purpose where I work because it's an open environment by nature and we don't really block things other than malware infected websites...

Unix - Most URL Reputation Providers only have some miniscule amount of the web categorized and a reputation put on it. What a web content gateway ideally does goes above just looking at basic reputation filtering. So let's say your FW checks with it's Brightcloud provider and returns a disposition of unknown or it gets miscategorized - It's probably allowed through in most cases without additional inspection. Problem with that is that it has no dynamic way of saying that X site is going to be categorized based on the content in the site itself.

So let's say you get an unknown site or it's misclassified by the first initial look on a web content gateway, it doesn't stop there: It usually looks at the nature of the content and tries to dynamically make a disposition based on the different elements on the page (as well as blocking certain elements of the page). So let's say you allow blogs but block gambling and someone surfs to a page that features a blog about gambling. With a Firewall URL filter, that blog might be categorized as "unknown" or "blog" and that's that. With a Web Content Gateway, it could dynamically make the assessment that it's most likely gambling-oriented regardless of the original designation of being a blog and take action based on that. It's much more powerful that "URL Filtering Lite"

I just checked a hacking site I know of and it shows as a "blog." It's a site that's been around for about 20 years now and details phone phreaking, social engineering and hacking. Meanwhile, my blog which is less than 2 years old shows as "Computers and Technology" (not a blog) which means if you were blogging blogs, I could get right on by

Not to beat up on poor PAN since I was trying to make a point on dedicated web appliances vs trying to fit it all in one box but someone did post this in the INE's CCIE Security chat yesterday: NSS Labs.jpg

Also... I've never heard of Forcepoint but I kind of want to learn more about it after reading the NSS Labs report...

Oh nice. Well I guess I did hear of them. Didn't realize Websense made Firewalls but that's sort of cool. I'm sure I am going to see some blog from NSS Labs at some point like I did a couple years ago: https://www.nsslabs.com/blog/company/seriously/

Ohhh I understand now! So you mean a web gateway would not rely on intel feeds and would attempt to inspect and categorise it manually. It makes sense! Where I work we're not allow to block anything apart from Malware (even explicit material is permitted lol)...so what palo alto does is that if there are files to be downloaded WildFire engine would analyze the file (similar to FireEye..)

I've seen their urlfiltering improve over the past few months, so now when you request a re-classification, they scan it and respond quickly, but yeah they can be liberal about classifying blogs. They've been good with re-classifying phishing websites though.

We also have automated block lists (reputation based) in place from places like alien vault, blocklist.ed , etc...heaps and they block so much and they're too quick to update. I've seen the number of incidents (malware and breaches) where i work drop drastically after implementing those feeds. filters out most Malware C2 & compromised sites..It's a life saver if you have BYoD in a public network..

TechExams.Net is not sponsored by, endorsed
by or affiliated with Cisco Systems, Inc. Cisco®, Cisco Systems®,
CCDA™, CCNA™, CCDP™, CCNP™, CCIE™, CCSI™;
the Cisco Systems logo and the CCIE logo are trademarks or registered
trademarks of Cisco Systems, Inc. in the United States and certain other
countries. All other trademarks, including those of Microsoft, CompTIA, Juniper ISC(2),
and CWNP are trademarks of their respective owners.