Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 3 subscribers
  • Views 28255 views
  • Users 0 members are here
Options
Suggested
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

Sophos EndPoint & Barracuda Web Filter

mrcjc

I am attempting a post before contacting technical support directly to see if anyone else is having this issue or might know a fix. Currently we run about 400 AV's in our enviorment and use a front end web filter from Barracuda. I created a specifc account for sophos to manage/install updates for all the clients, I am running an update client at every physical location, with a updating policy pointing to the apporpiate update nodes per site.

Everything works great, our issue is this. When Sophos client reaches out for updates "Assuming that is what this is" in our barracuda we see "SUM" this is the user I made in AD for accessing the update node per out AV clients "PC's". At first this didnt seem like an issue. However after further use, it appeared that once Sophos EndPoint used this account via Active Directoy, it gave our users wide open access to the internet "By passing our barracuda" In fact the traffic still goes through the Barracuda it just shows the user as "SUM" when in reality we know it is an actual user based on the clients IP from any specifc location with in our company.

My question is, why does my AV client reach out to Sophos online if I have it configured to only talk to the Update node on site?

Here is an address it reaches out too:

http://http.00.s.sophosxl.net/V3/01/86.37.194.173.ip/

What is this and how can I stop the clients from trying to talk to sophos directly. I only want them to get their updates via our specifed nodes.

Here is another example:

I have a user blocked from facebook but the computer reaches out that ‘‘‘‘sophos proxy above’’’’ and then it finds the IP.  Which pretty much renders our web barracuda useless.  It doesn’’’’t do it all the time though. So it almost uses Sophos as a proxy and then redirects to the web address.

Any help on this would be greatly appricated! As of right now some of our users have figured out there is some sort of loop hole in our web filter and are abusing the heck out of the internet! Even with managers warning them it doesnt appear to be enough, we need to get a solution for this and quickly.

Thank you,

Chris

:51458


This thread was automatically locked due to age.
  • 0

    Those are SXL (Live lookup) requests, not updates.

    The are done for files and for web requests.

    :51470
  • 0

    Thanks for confirming this, is there anyway to stop this from happening? It seems as if when the AV client reaches out it allows the user to by pass our barracuda.

    :51500
  • 0

    Hello mrcjc,

    you're using a flowery language rather than giving a technical description (no offence meant) so I'm not sure I understand you correctly. Maybe you can rephrase and restructure your presentation of the issue.

    In the hope it is of some help I'll try to explain what the software on the endpoint does (and does not):

    • Updating: Assuming the endpoints update from a Web CID they make a connection to port 80 on the specified server, if necessary (when requested by the server) authenticating with the username and password in the policy. If a(n explicit) proxy is required it has to be configured in the policy, the Internet Options proxy setting is ignored.

    Now to this SXL stuff, to quote from the Glossary: Client machines will performed (sic!) SXL lookups to Sophos hosted SXL servers. The servers contain an expanded data set that may be checked by clients for different reasons. Live protection uses SXL lookups to check if there is any additional information about a file SAV is scanning. SXL lookups are also used for Web Protection (to determine if a high risk website is being requested), Web Control (to determined (sic!) the web category of the requested website) and SAV Whitelisting.

    Live Protection (part of AV-scanning) uses DNS for queries and optionally (and if required) HTTP for uploads. There is no authentication involved.

    Web Protection makes HTTP requests (as the one you've quoted) to asses the potential risk of a site (name or IP) or URI requested by the browser. AFAIK it uses (on Windows) the Internet Options proxy settings. Depending on the response received It either allows the browser to proceed or blocks the request (presenting an appropriate error page when applicable). Note that it just intercepts the browser request, it neither performs a lookup on behalf of the browser nor does it redirect (or proxy) the traffic. 

    Can't see what should enable the user to bypass the Barracuda. I'd rather suspect an inappropriate configuration of the Barracuda - but then, I have no knowledge of these (and in addition I might have misread you).

    Christian   

    :51522
  • 0

    I appricate the reply, Allow me to explain in further detail.

    We have 2 different scenarios here

    Scenario 1:

    We have a web proxy in place (barracuda) and blocks users based on websites, categories, etc.  So while ‘‘‘‘facebook.com’’’’ is blocked a user is not allowed access into that website.  With the install of Sophos AV, we noticed that users are randomly allowed access into the facebook website.  After looking at the proxy web logs, it shows the user going to this website

    http://http.00.s.sophosxl.net/V3/01/79.208.201.54.ip/ (just grabbed a random example but same concept).  If that were the facebook IP at the end, our AV has essentially ‘‘‘‘bypassed’’’’ our web proxy and allowed them through to the website.  Basically our web proxy doesn’’’’t see anything wrong with a sophosxl.net web request and just allows the site through after it passes any spyware/virus checks.  It pretty much deems our web proxy useless.  There doesn’’’’t seem to be a fix for this but is there an option to turn this off this live checking in the console?

    Scenario 2:  We set up a username in our AD environment called ‘‘‘‘SUM’’’’.  In our updating we set the computers to update every 10 hours to an appropriate Update Manager (Local).  So as a computer checks in, it uses the username ‘‘‘‘SUM’’’’ to download updates from the Update Manager.  Which is all fine and dandy but it essentially opens up the window for 10-20 minutes while the SUM username is active.  Once it is finished doing what it needs to do, the web proxy sees the computer switch back to the original AD username.  At the end of the day, we see this SUM username rack up about 2-4GB of internet download as a cumulative across the board.  If we set the computers to update every 2 hours, the total internet download comes out to 15-20GB a day.  It’’’’s not like a user knows when that window opens up but if they happen to ‘‘‘‘catch’’’’ the window then it is a free for all again.  Because it has to switch to this special username to update, it wreaks havoc for us behind the scenes using a proxy.  A typically user with no access shows like this:

    Rharris:  facebook.com blocked

    Rharris:  msn.com blocked

    SUM:  youtube.com allowed

    SUM:  espn.com allowed

    Rharris:  youtube.com blocked

    I hope this is more clear cut than my previeous explenation.

    Thank you,

    :51568
  • 0

    Hello mrcjc,

    thanks, a lot clearer now.

    we noticed that users are randomly allowed access into the [facebook] website ... h__p://http.00.s.sophosxl.net/V3/01/79.208.201.54.ip/ ... our AV has essentially ‘‘‘‘bypassed’’’’ our web proxy and allowed them through to the website

    Let me explain the request to sophosxl.net first. Another form you've certainly seen is h__p://http.00.s.sophosxl.net/V3/01/bpfc.irevfvta.pbz.w/. The former enquires about an IP which is used in reverse order (thus the actual IP is 54.201.208.79), the latter about a name ROT-13ed (in the example ocsp.verisign.com). The response (just a few bytes) indicates whether the site/IP is considered "clean and harmless" or why not. Based on this information the browser request is blocked or allowed to proceed in its original form. Thus there's nothing on the endpoint which would enable the user to bypass the Barracuda - other than the preceding request to sophosxl.net, but if this request were actually the cause then a user could, even without Sophos, simply browse to sophosxl.net (or any other permitted site) before initiating a connection to a disallowed one. Ok, while replying to the second part it occurred that this might indeed "open a window". Apparently when a non-user/system process tries to make an HTTP connection the user (seen by the Barracuda) is "switched" ...

    While it's not recommended as a long term solution you can of course disable Web Protection and solely rely on the Barracuda - but you'd still have the second problem.

    So as a computer checks in, it uses the username ‘‘‘‘SUM’’’’

    Sophos (in particular AutoUpdate) has no knowledge of the Barracuda and no means to identify to it. Actually AutoUpdate first sends an unauthenticated request and only after getting the 401 in return it retries using the credentials. Thus the primary question is, how is the update user (SUM) associated with the request - again, it's not Sophos that does this. the computer switch[es] back to the original AD username - is there a piece of software on the endpoints which complements the Barracuda? Otherwise - how can a computer switch back? 

    I see that restricting access for the SUM user would block "preferred" users during the update and has probably deemed unacceptable. If you can't or don't want to use SMB/UNC for the update locations the answer can only be found in the Barracuda (or, perhaps, on the network level, i.e. bypassing the Barracuda for connections to the update locations).

    Christian 

    :51572
  • 0

    Chris,

    I am having the same issue.  Can you tell me how you got around this?

    Or any insight.

    TIm

    :56342
  • 0

    There may actually be a super simple answer to this... We ran into the exact issue but with Meraki Content filtering... The SophosUpdateMrg service account kept triggering logon events that were then causing end user PC's to show the SophosUpdateMgr as the logged in user.

     

    We just created a local account on the Sophos Server which is not a DC in our case, and changed the update policy to user servername\SophosUpdateMgr instead of domain\SophosUpdateMgr. Now updates still happen but the stupid service no longer interferes with 3rd party web filtering.

     

    Also make sure to update the share and NTFS permission on the UpdateManager directory to match.

     

    Hopefully this continues to work in the long term, but seems good for now.

  • 0 in reply to Steve Congdon

    Hello Steve Congdon,

    I'd not call the service stupid - if you don't want the share to be public a common ("service") account has to be used as the endpoint has to be able to update without a user being logged on. "Smart" web filtering came much later and arguably it's a shortcoming of the guess-who's-logged-on logic.

    Christian

Unfiltered HTML