Bypassing Endpoint Web Control: Third Party Browsers/Scripts

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   

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