This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Web Filtering issue

Hi.
From about two weeks ago, we are having strange problems with our Web Filtering.
It seems that for some web pages (most work fine) takes a long time to load, and when they do, they load partially, or without the images (Gif, jpeg&#8230[;)] which they contain.
Just for example for problematic sites: 9GAG - Just For FunNBA & ABA Basketball Statistics & History | Basketball-Reference.comPro-Football-Reference.com - Pro Football Statistics and History.
If I enable the HTTP in the FireWall – all works fine.

We are working with Transparent Mode, no Blocked website categories.

I have tried to disable virus scanning and disable URL Filtering – didn't help.

Something look strange in the HTTP Log (I was trying to reach [url]http://9gag.com/):

2013:12:21-10:51:04 mhoote httpproxy[10748]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="GET" srcip="xx.xx.xx.xx" dstip="54.216.33.177" user="" statuscode="200" cached="0" profile="REF_DefaultHTTPProfile (Default Proxy)" filteraction="REF_DefaultHTTPCFFAction (Default content filter action)" size="2" request="0x33bcd1f8" url="http://http.00.t.sophosxl.net/V3/01/200.202.230.54.ip/" exceptions="av,auth,content,url,ssl,certcheck,certdate,mime,fileextension,size" error="" application="cffs"

I wonder if someone has any idea.
[:(]


This thread was automatically locked due to age.
  • Regarding the sophosxl.net requests:

    Is your srcip system running the Endpoint Security and Control client with Web Protection not disabled?

    Michael Dunn mentions sophosxl lookups in this post: https://community.sophos.com/products/unified-threat-management/astaroorg/f/80/t/65092

    It would be nice if the sophosxl lookups were cached, or cachable, on the UTM (for a configurable duration).  

    It would also be nice to see a discussion of the implications and considerations of those look ups, their life on the wire and in the logs wherever they may be.  Maybe a "xl_local_db" like "sc_local_db" (but supported)?
  • Hi teched.

    I have tried both with and without  Endpoint Security - no different.
  • I did some tests on some local clients with Sophos Endpoint (UTM) and it looks like it is the Antivirus Policy that causing my sophosxl queries.

    From my on-box PDF documentation, 11.2.1:
    Web protection: If enabled, the website URLs are looked up in the Sophos online database of infected websites.


    Is the srcip that of the client system(s) or the UTM?  My clients without Endpoint Security and Control (mobile devices) don't have sophosxl.net lines associated with their IPs.

    Note, this is Web Protection in Antivirus settings and not Web Control.

    I'll have to ponder Antivirus Policy and Web Control a bit more - I keep coming up with more questions for myself than answers.
  • i've been using the sxl system for quite some time..it's worked fine.  The sxl system DOES do some caching of lookups and content.  I'm wondering if you were having some connectivity issues between yourself and the target sites as they have been working fine here.
  • Hi guys.

    sophosxl is the cloud categorization service used by Endpoints and UTMs (when Web Control is enabled).

    In a normal working system the Endpoint will be doing SXL requests, and the UTM will see that it is an SXL request from an Endpoint that it configured from that UTM.  It will bypass the proxy (eg not do things like AV scan on the SXL traffic) and not log.  In fact, the UTM will bypass all web proxy checks (unless the dual scan is turned on in EP Web Control Advanced) for all traffic coming from valid endpoints.

    If you are seeing traffic to sophosxl.net in your proxy log that means there is an endpoint which is doing SXL lookups but is not properly registered with that UTM.  You will likely see all of that computer's traffic (normal web browsing) also logged on the UTM.

    There are valid reasons this could happen. For example if you have a work UTM and a home UTM, a work laptop configured by the work UTM and then brought home.  The home UTM would see the sophosxl traffic, not recognize it as being for itself, and log it.

    More likely something is not right in the registration or configuration.  You may want to check if that device giving those messages appears as connected under the Endpoint Protection.  You may also want to take the laptop with the endpoint out of the network (eg direct internet).  Make a web policy change on the UTM that should affect the endpoint.  It likely will not work.

    The quick solution is just to reinstall the endpoint.  The complex is to determine why the EP is not registered with the UTM correctly.
  • ok so i was told something different..so if you turn on ep then the web proxy is still using cffs?  I was told that sxl was the future and everything would get routed through that.  so i guess it's back to the cff caching settings again if i want decent proxy look-up speeds..[:(]
  • also so if you are using ep it bypasses the utm?  The point of having the utm is to provide another layer of security..so this effectively means if you install an ep it punches by your utm thereby eliminating at least one scanning engine's worth of protection(avira)..not a good deal in my book.  I do see where you can go into advanced and manually enable it..however i think that should be the default and not the optional setting.  In it's default configuration enabling EP DECREASES your security instead of increasing it.
  • Reply to William's first post:
    I'm not sure I understand the first comment.  In this scenario everything is using SXL not CFFS.

    There are SXL requests generated by the UTM and there are SXL requests generated by the Endpoint.  Normally the ones generated by the Endpoint are not logged by the UTM (doing so clogs up logs).  The fact that they are logged indicates the UTM does not recognize that Endpoint as being one of its own.

    Reply to William's second post:
    Yes, if you are using the EP with Web Control then it bypasses the UTM for the majority (not all) httpproxy scanners.  Basically the web protection offered by the endpoint and the web protection offered by the UTM are equivalent so by default we only enforce policy at one location.  Those people who want both belt and suspenders can turn on the dual scan.  As for what the default should be...  That can be debated.

    One side effect is that when you start using Endpoint then processing work is moved from the UTM to the Endpoint.  That means that a UTM that may struggle with 100 connected computers runs just fine with 200 connected endpoints.
  • Just a note that we adopted the "Sophos Cloud AV" service and are having the same issue. I think changing the exception in the UTM to include logging has fixed the problem, but I won't know until tomorrow when we hit peak use around midday.
  • Reply to William's first post:
    I'm not sure I understand the first comment.  In this scenario everything is using SXL not CFFS.

    There are SXL requests generated by the UTM and there are SXL requests generated by the Endpoint.  Normally the ones generated by the Endpoint are not logged by the UTM (doing so clogs up logs).  The fact that they are logged indicates the UTM does not recognize that Endpoint as being one of its own.

    Reply to William's second post:
    Yes, if you are using the EP with Web Control then it bypasses the UTM for the majority (not all) httpproxy scanners.  Basically the web protection offered by the endpoint and the web protection offered by the UTM are equivalent so by default we only enforce policy at one location.  Those people who want both belt and suspenders can turn on the dual scan.  As for what the default should be...  That can be debated.

    One side effect is that when you start using Endpoint then processing work is moved from the UTM to the Endpoint.  That means that a UTM that may struggle with 100 connected computers runs just fine with 200 connected endpoints.


    so is everything routed to sxl now?  if so why is the http proxy still doing cff lookups?