url log without profile

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

url log without profile

L6 Presenter

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

1 accepted solution

Accepted Solutions

L4 Transporter

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.

View solution in original post

13 REPLIES 13

L5 Sessionator

Check if you have URL categories configured in security Rules.

No not selected.But there is in QOS,but logs are blocked-url.That makes it strange.

1.png2.png

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.

22.png

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.

yes.seems to be a bug but I was not sure.I saw this on many POC's.

This seems to be easily reproducible.

Hotspot-logs.PNG

Rule Used Capture.PNG

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

Yes it is but how will we disable that url log

L4 Transporter

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.

Can you please open a case with support and add this link as a reference .

Regards,

Ameya

no url filtering for any rule.Thanks.

L4 Transporter

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.

  • 1 accepted solution
  • 4386 Views
  • 13 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!