URL Filtering - Where to implement it

MitM

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>

UnixGuy

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

TheFORCE

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.

MitM

Thanks for the replies UnixGuy and TheForce.

TheFORCE wrote: »

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.

bhcs2014

Yikes. Might be time to review your org's change management process?

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.

MitM

bhcs2014 wrote: »

Yikes. Might be time to review your org's change management process?

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.

MitM

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.

Iristheangel

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

Iristheangel

MitM wrote: »

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

MitM

Iristheangel wrote: »

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.

UnixGuy

@Iris:

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

Iristheangel

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

UnixGuy

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

MitM

I don't believe PanDB is using BrightCloud. I know there is an option to purchase a BrightCloud license. With the wildfire license it makes more sense to use PanDB instead of BrightCloud.

For my company it serves the purpose. For a larger company, I'd do things different.

UnixGuy

We use wildfire as well

Iristheangel

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"

Iristheangel

Example of this on here: https://urlfiltering.paloaltonetworks.com/testasite/urlquery

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

MitM

@iris absolutely right.

Iristheangel

*quickly injects zero day malware and pr0n into blog*

MitM

Now we can't visit your blog

Iristheangel

Naw, you're good. You have PAN and AV. They're letting it through!

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:


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

MitM

Haha no worries. I don't work for Palo Alto. I saw that same thing posted somewhere else yesterday. LinkedIn maybe hmmm

ForcePoint is formerly Websense.

Iristheangel

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/

UnixGuy

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

I think they're consolidating those feeds in one plan in Pan 8 (haven't used it yet): https://live.paloaltonetworks.com/t5/PAN-OS-8-0-Articles/PAN-OS-8-0-IP-Block-List-Feeds/ta-p/129616

MitM

Interestingly enough they didn't. The firewall is from an acquisition of Stonesoft.

Iristheangel

Ohhhh I used to have a Stonesoft IPS back in the day. Our architect fiddled with it one time and accidentally locked everyone out - No fault of the IPS, just someone fiddling where they shouldn't have

MitM

This wasn't the point of this thread but since it was brought up, I'll mention it....@Iristheangel jinxed me. We had users unable to browse the other day, due to some SSL Decryption session limit/issue on PAN. I wasn't in the office at the time, so I didn't troubleshoot it, but my co-worker decided to failover to clear the sessions