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

Bypassing Endpoint Web Control: Third Party Browsers/Scripts

Greetings, 

 

While getting ready to deploy the Endpoint Software from Sophos Central, we noticed that the Endpoint Web Control can be bypassed using third party browsers such as QTWeb.  Application Control can fix the use of that browser, but the general fear over here is that software that Application Control has never heard of can be used to bypass Web Control policies we have put in place.

The feature request would be that Endpoint Protection monitor port 80/443 requests, instead of only applying to popular browsers.  In the immediate, does Sophos (or anyone in the community) have any advice for locking http/https requests to conform to our Web Control policy?

 

Thanks in advance, 
Eric



This thread was automatically locked due to age.
Parents
  • Hello Eric,

    may I ask what the primary goal of your Web Control polices is? Reducing risks, minimizing "unproductive" time, restricting private use,  or?

    There's no (near) perfect solution you can implement solely on the endpoints (unless you lock them down). Whether Web+Application Control is adequate depends on how perseverant and/or desperate your users are trying to bypass Web Control and what the damages (in the broader sense) to your company/organization are if they succeed. Apart from using non-standard browsers Web Control can be bypassed by other means, thus applying Web Control to ports 80 and 443 won't bar determined users from visiting forbidden sites (and it might have unwanted side effects).

    If you really need strict and tight control there's IMO no way around a gateway solution.

    Christian   

  • Christian, 


    Thank you for writing back.  I feel the initial shock to my group is similar to when the board game "Guess Who?" came out.  The commercial clearly showed to us kids the cards talking, then you or a friend got the game, and it was like - wait - we have to do the talking?  The Endpoint Web Control feels a bit like that, where our expectations may have been a little a high.  Our primary goal would be restricting port 80 and 443 web traffic when a device is off our LAN, and it seems like we had the expectation that it ran all the traffic through 127.0.0.1, and would determine allowed/blocked data based on that.  I couldn't visit site XYZ no matter what browser, or more basic methods I employed like curl or wget.

    The fear that is out there is that in the ever changing cat & mouse game of bypassing rules is that someone would be able view restricted content while using a browser (or script) we never heard of over HTTP/HTTPS.  I do agree with you that we need a gateway solution to truly regulate the data going across these ports, no matter the client.

  • Hello Eric,

    it ran all the traffic through 127.0.0.1
    Web Control
    isn't a local proxy, it intercepts browser traffic with an LSP or a WFP driver (while the article is for Central it basically applies to SESC as well). And how could an arbitrary application's traffic be redirected through 127.0.0.1?

    the ever changing cat & mouse game
    you can't completely solve social or behavioural problems with technology, there's often a contradictory outcome. A not so extreme example is a government department that advises its citizens to "patch early patch often" so that they dont fall victim to cybercrooks while at the same time it aims to strengthen surveillance by using a federal trojan - wonder by what means they'd get the trojan on a suspect's device?
    Perhaps you hope that you can avoid conflicts or legal action with technology but this is not possible in all cases. A gateway solution will definitely raise the bar for potential offenders but it too won't be perfect.

    Christian 

  • Christian, 


    Thank you for your time.

    Questions were asked, and I thank you for answering them.

     

    -Eric

Reply Children
No Data