- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
05-27-2013 02:12 AM
Hi ,
Why do we see url filtering logs although there is no any url profile ?
logs related to denied app. like ultrasurf and hot-spot shield
10-29-2014 06:22 AM
Bug 52549 Fixed in 5.0.9 - The dataplane was generating URL logs for denied traffic even though no URL-filtering profile was configured for the applicable policies. A fix was made to generate URL logs only when URL filtering profiles are applied.
05-27-2013 06:51 AM
Check if you have URL categories configured in security Rules.
05-27-2013 06:55 AM
No not selected.But there is in QOS,but logs are blocked-url.That makes it strange.
05-27-2013 07:07 AM
URL filtering profile is needed for generating URL logs.Can you check the security rule that is triggering this log by clicking the magnifying glass icon alongside any of these URL logs.
05-27-2013 08:10 AM
If the rule Hotspot did not have URL-filtering profile when this log was generated (5/26-15:47).This does not seem to be an expected behavior.
05-27-2013 08:50 AM
yes.seems to be a bug but I was not sure.I saw this on many POC's.
05-27-2013 08:49 PM
This seems to be easily reproducible.
DP logs:
192.168.187.100[15243]-->46.51.130.1[80]
May 27 23:14:14 pan_ctd_run_detector_i(pan_ctd.c:6318): app 109 time 3600
192.168.187.100[15243]-->46.51.130.1[80]
May 27 23:14:14 pan_ctd_handle_reset(pan_ctd.c:6014): handle reset
May 27 23:14:14 pan_ctd_handle_reset(pan_ctd.c:6025): ***setapp to 802 (old app 109)
May 27 23:14:14 pan_ctd_handle_reset(pan_ctd.c:6028): orig_app is 109
May 27 23:14:14 pan_appid_set_timeout(pan_appid_proc.c:331): session 47111 appid 802 set timeout 3600
May 27 23:14:14 pan_urlcache_lookup(pan/src/pan_urlcache.c:903): In pan_urlcache_lookup, e 0, c 252
May 27 23:14:14 pan_urlcache_lookup(pan/src/pan_urlcache.c:957): TRIE LOOKUP: url 46.51.130.1/hss-sd/
May 27 23:14:14 pan_urlcache_lookup(pan/src/pan_urlcache.c:1008): res 1, PAN_URL_TRIE_NOT_IN_DB 4, cat.num 1,cat.cat[0] 255, PAN_URL_CTGR_NOT_RESOLVED 252, pan_url_trie_is_rfs_expired 0, ucache->cloud_up 1
May 27 23:14:14 pan_urlcache_lookup_ext(pan/src/pan_urlcache.c:1094): Add to the vector
May 27 23:14:14 pan_ctd_handle_reset_and_url(pan_ctd.c:7931): appid 802(from 109), num. of categories 1
May 27 23:14:14 pan_ctd_app_policy_lookup_i(pan_ctd.c:4812): Session id(47111): rule changed to trust-2-untrust from rule1 action(1); logging(2); profile id(0) category unknown(16383)
192.168.187.100[15243]-->46.51.130.1[80]
May 27 23:14:14 pan_ctd_url_log_action(pan_ctd.c:4466):
url '46.51.130.1/hss-sd/hss-sdu.php' category: unknown, action 0
192.168.187.100[15243]-->46.51.130.1[80]
May 27 23:14:14 pan_ctd_handle_app_denied(pan_ctd.c:4852): app denied
May 27 23:14:14 pan_ctd_handle_app_denied(pan_ctd.c:4859): sending app block notify page
May 27 23:14:14 pan_ctd_run_detector_i(pan_ctd.c:6409): pan_ctd_handle_reset_and_url() returns 2
May 27 23:14:14 pan_ctd_process_token(pan_ctd.c:5566): pan_ctd_run_pattern_match() failed 2
Session 47111
c2s flow:
source: 192.168.187.100 [trust-L3]
dst: 46.51.130.1
proto: 6
sport: 15243 dport: 80
state: INIT type: FLOW
src user: unknown
dst user: unknown
s2c flow:
source: 46.51.130.1 [untrust-L3]
dst: 172.17.128.187
proto: 6
sport: 80 dport: 63281
state: INIT type: FLOW
src user: unknown
dst user: unknown
start time : Mon May 27 23:14:13 2013
timeout : 90 sec
total byte count(c2s) : 6534
total byte count(s2c) : 362
layer7 packet count(c2s) : 11
layer7 packet count(s2c) : 6
vsys : vsys1
application : hotspot-shield
rule : trust-2-untrust
session to be logged at end : False
session in session ager : False
session synced from HA peer : False
address/port translation : source + destination
nat-rule : nat-trust-2-untrust(vsys1)
layer7 processing : completed
URL filtering enabled : False
session via syn-cookies : False
session terminated on host : False
session traverses tunnel : False
captive portal session : False
ingress interface : ethernet1/4
egress interface : ethernet1/3
session QoS rule : N/A (class 4)
session tracker stage deny : l7 proc
session tracker stage l7proc : session deny
05-27-2013 11:15 PM
Yes it is but how will we disable that url log
05-27-2013 11:33 PM
The hotspot-shield application has dependencies on both the web-browsing and ssl applications. As the session transitions between applications it could match different policies, which could in turn apply a different set of security profiles.
If the traffic flow from this particular client was legitimate web-browsing instead of hotspot-shield, which security policy would it hit? Does that policy have URL filtering applied?
It is possible that the first few packets after the TCP handshake hit a different policy which has URL filtering enabled. Shortly after the URL is sent by the client and is logged, the application transitions to the hotspot-shield application and it's associated security policy.
If you can reproduce this URL log behavior on a test machine a good test would be to create a security policy for that source IP for web-browsing and ssl without any profiles enabled. If creating that test policy stops the logs from generating for that particular client then the scenario I describe above is the likely cause and would be expected behavior.
05-27-2013 11:34 PM
Can you please open a case with support and add this link as a reference .
Regards,
Ameya
05-27-2013 11:49 PM
no url filtering for any rule.Thanks.
10-29-2014 06:22 AM
Bug 52549 Fixed in 5.0.9 - The dataplane was generating URL logs for denied traffic even though no URL-filtering profile was configured for the applicable policies. A fix was made to generate URL logs only when URL filtering profiles are applied.
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!