Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 3 subscribers
  • Views 28260 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.
Parents
  • 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
Reply
  • 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
Children
No Data
Unfiltered HTML