> For example, if a user suspected that we were using a transparent proxy
> to limit their access, they can have a different proxy setup on a remote
> site and enter that address as the proxy address in their browser.
One reason I don't like transparent proxy is the "sneaky" aspect of the
whole thing, plus you end up having to permit unproxied access to
TCP/443 for SSL, and then dealing with legitimate web services
running on arbitrary high ports, etc.
In the end, it's just (IMHO) easier to go non-transparent. I always
recommend requiring explicit proxy configuration via PAC/WPAD,
and blocking all other paths to the Internet, and watching the logs
for users/apps trying to tunnel out through the proxy.
Every modern PC/MAC/Unix graphical browser can use Netscape's standard
Proxy Automatic Configuration. We support approximately 25K users
and have a default deny policy for all ports and protocols towards
all Internet destinations, with minimal user complaints.
For HTTP/HTTPS, in over six years we have had to configure exactly
two exceptions for applications unable (unwilling) to use a proxy
for HTTP/HTTPS requests.
> Henrick is right though, Im not sure there is a good
> way to do it with a transparent proxy. Ive been thinking about
> using a radius server or NTLM (I think) and making everyone have
> a username and password to get to the internet. But, that would
> be quite a nightmare to set up.
Another advantage of explicit proxy is the better/cleaner handling of
proxy user authentication.
> And finally, if that isn't sufficient, build a whitelist of allowed
> sites and block everything else..
This is really the only truly effective solution.
I tried this once when I was working in a SEC-regulated environment
where controlling communications was important, and it worked fine
(except for the ever-growing list of exempt "VIP" users.)
Whitelisting also mitigates most worms/trojans/spyware/web bugs,
and makes using Internet proxies to go around the filter all but impossible.
Kevin
Received on Sat Apr 22 2006 - 11:07:35 MDT
This archive was generated by hypermail pre-2.1.9 : Mon May 01 2006 - 12:00:02 MDT