topic Seriously Cisco/SourceFire??? in Network Security

Sourcefire URL filtering - odd behavior

David Inabinet — Tue, 12 Mar 2019 12:37:46 GMT

I'm seeing some strange behavior with our new ASA 5545-X with the Sourefire URL filtering.

I'm intermittently able to get to known bad sites that should be blocked. For example, we are testing the porn URL filtering and our device is configured to NOT allow any Nudity. For some time, I'm able to browse playboy.com or some of the other known bad sites. Then, without any configuration changes, the sites get blocked. It also seems that after an undetermined amount of time, the sites are allowed, at least for the first attempt then they are blocked again - sending users to the block page.

Also, a few sites (well known Adult sites) are allowed when, clearly, they should be blocked.

Is anyone seeing anything like this?

Yes. This happens in my lab.

Collin Clark — Sat, 28 Feb 2015 15:45:16 GMT

Yes. This happens in my lab. I'm running 5.3 and I'm hoping the upgrade to 5.4 fixes it.

Same here running same code.

mikgruff3 — Sat, 28 Feb 2015 21:06:10 GMT

Same here running same code.

Seriously Cisco/SourceFire???

David Inabinet — Sun, 01 Mar 2015 20:25:34 GMT

Seriously Cisco/SourceFire????? This is your URL filtering? This is a joke.

I have a TAC case open and I'm curious to hear what the tech I speak to will say when this is happening with 5.3 for everyone.

I'm extremely disappointed.

I'm seeing this same behavior

snowmizer — Mon, 02 Mar 2015 16:01:12 GMT

I'm seeing this same behavior. I shouldn't be allowed to access www.playboy.com when I've got a rule configured to block "Adult and Pornography" sites. When I look at the connection events it appears that the "URL category" isn't getting set on any of my web browsing type traffic. I verified that I have "Enable automatic updates" turned on and the "URL filtering" update shows it was last updated on 2/26/15.

What's up with this?????

Remember that this is an IPS

Collin Clark — Mon, 02 Mar 2015 21:53:33 GMT

Remember that this is an IPS appliance that has had multiple add-on's like URL filtering, NAT, VPN, etc. If you want tried and true URL filtering you should look at the WSA.

I understand your point but

David Inabinet — Mon, 02 Mar 2015 23:27:07 GMT

I understand your point but if the product doesn't work they shouldn't sell it or at least label it as "Beta". It is touted as a top tier URL filtering solution.

I spoke with TAC today. They are aware of the issue and will be getting back to me with a workaround until an official patch is released.

I opened a ticket yesterday

snowmizer — Tue, 03 Mar 2015 13:36:24 GMT

I opened a ticket yesterday and had a tech call me back and resolve this issue. There is a bug that is fixed in v5.3.1.2 and v5.4. After the tech applied the fix the issue was resolved.

I am having the same issue

Philippos Ioannou — Fri, 27 Mar 2015 08:18:53 GMT

I am having the same issue even with 5.4. it started 3 days ago. what is the solution

I am having this same issue

Margarita Malacara Cruz — Tue, 07 Apr 2015 01:32:10 GMT

I am having this same issue but we are running v5.4.1 build 59.

My customer has a rule configured to block "Adult and Pornography" as well as "Music" sites. After successfully reaching www.vainaporno.com and www.suenamp3.com, the Connection Events show no URL category set for any of these sites.

Is there a way to block uncategorized sites? He prefers to create a new rule allowing permitted sites 'on-demand' after the Connection Event has been reviewed.

Also, according to the

Margarita Malacara Cruz — Tue, 07 Apr 2015 01:52:03 GMT

Also, according to the Brightcloud URL / IP Lookup tool, the site www.vainaporno.com is actually categorized as "Adult and Pornography". But the Connection Events on the Defense Center don't show any URL category set.

http://www.brightcloud.com/tools/url-ip-lookup.php

we had the same issue and got

bernhard.hoerl — Tue, 12 May 2015 17:01:31 GMT

we had the same issue and got the url filter to work properly with a workaround from tac

by adding a monitor rule with the same categories we tried to block above the block urls rule the filter seems to work as it should. by adding this the website is first categorized and then the blocking rule matches

i hope this was helpful!

Nobody seems to know the

alberx — Fri, 15 May 2015 11:36:57 GMT

Nobody seems to know the solution? I have this and other extrange behaviour allowing traffic to supossedly blocked sites, not receiving the http response page, or not filtering some of my networks.

I think they should come up

Philippos Ioannou — Fri, 15 May 2015 11:53:13 GMT

I think they should come up with a major release to fix these issues, because they will lose a lot of customers like this. this is a joke of a product. nowhere near WSA

very disappointed. even using user access under terminal services does not work properly. it binds the username with IP of the server so at the end of the day its the Ip that has access and if you have different access levels for the user on the RDP a big mess happens.

rubbish to me

We worked a case on this with

jonathanross1 — Thu, 04 Jun 2015 20:40:53 GMT

We worked a case on this with Sourcefire support before they were fully assimilated by Cisco.

My conclusion.......The URL Filtering is pretty much garbage.

Here is the response from support:

"The feature is working as designed, with no plans to change this. However, it's possible they could make this an enhancement. In order to consider that, they would need to understand the specific use case and clarify why you want the change."

"It appears the reason the first attempt passes is because the AC rule category will not match when a cloud lookup has to be done on the URL and the result has not yet been received. It instead matches the later "Allow" rule, so further requests to the same host will be permitted as long as the browser keeps the connection open."

"Note that each Snort instance (appliance) keeps its own individual cache of URL cloud lookups, so a different connection from a different IP address could still go through, if it is load-balanced to a different Snort instance."

"The maximum size of each Snort instance's cache for URL cloud lookups is fixed. When the limit is reached, the least recently used entries are discarded."

"So essentially, the first attempt may pass because a cloud lookup has to be done on the URL and the result has not yet been received."

Last week I upgraded to new

alberx — Fri, 05 Jun 2015 08:48:22 GMT

Last week I upgraded to new releases for DC ans sensors. It solved my problems with http reponse page, and it seems URLs are now well categorized and blocked correctly. Try to upgrade maybe it helps.

In 2nd quarter 2015 Cisco Will release 6.0 trying to give more functionalities. I hope also improvements in general behavior, but unfortunately these improvements (web portal as example) does not include time based rules or much more complete http response pages with information about categories bloking sites.

running 5.3. Playboy blocked

Austin Clark — Fri, 05 Jun 2015 12:31:59 GMT

running 5.3. Playboy blocked, weird url above not blocked the first time. Blocked it the second. I'm literally, fine with that because I'm going to give the information to peoples managers regardless if they got one free peek or not.

Hi,

S.ashok S — Mon, 09 Nov 2015 16:46:30 GMT

Hi,

We are running 5.4 but still it is not working as expected. Many of the bad known websites are allowing even after blocked all related sites and application categories.

Kindly suggest if any solution for this issue.

Thanks,

Ashok

You could add them to the

Austin Clark — Fri, 13 Nov 2015 15:17:16 GMT

You could add them to the security intelligence global black list.

Hi All,

Dinkar Sharma — Mon, 16 Nov 2015 09:09:59 GMT

Hi All,

This issue is due to the device behavior which has been corrected in 6.0 release.

"The first time Snort looks up a URL for filtering, if the URL isn't in shared memory or request cache, it requests the URL from the cloud, but allows the URL to go through. By the time it get's a response from server about it's category, the url is allowed. If you refresh the page or open a new page with same URL it's get's blocked."

This was tested and reproduced by TAC in lab and enhancement request was filed to change this behavior. The ENH request is CSCuu42562 and this issue has been fixed in latest release 6.0.

http://www.cisco.com/c/en/us/td/docs/security/firepower/60/relnote/firepower-system-release-notes-version-600.html

Thanks,

Dinkar