Guidescope: System Administration

System Administration

Introduction

The Guidescope Proxy is a remarkably flexible Web proxy that can be easily incorporated into most network configurations. This white-paper addresses several configuration options. Its intended audience is the person charged with administering the "network plumbing" that lets browsers reach the Web. As such, it will not spend a lot of time with "basic networking concepts" but assumes familiarity therewith.

Basic configuration

One of the things that we assume is that each browser talks directly to the Guidescope Proxy. Thus the Guidescope Proxy should be placed so that it is directly accessible to each client browser. The reason for this is that we use the client browser's IP address as a key for segregating each browser's history from its peers. If the client's IP addresses is obscured by an intervening proxy, or other masquerading techniques such as a Network/Port Address Translation (NAT/PAT) device, then all of the historical information will be merged in the proxy, thereby exposing each user's history to the other users who share their IP address. This would be a Bad Thing.

Hence, if the Guidescope Proxy is part of a proxy-chain, it should be the link in the chain that's closest to the browser(s).

Case Studies

The following case studies provide instructions and examples of the most common network proxy configurations.

Case 1

The simplest and, in terms of the number of users, the most common configuration for accessing the Web today is for a single user to connect to their ISP who provides a direct connection from the user's host to the Web.

[ (browser) ]<----->[ ISP infrastructure ]<======> Web

In this case, the easiest thing to do is to:

Load/run the Guidescope Proxy onto the personal host, and
Set the browser's to point to the Guidescope proxy on "127.0.0.1:8000"

The connections then look like:

[ (browser) <-> (GS) ]<----->[ ISP infrastructure ]<======> Web

This is what you get with the default built-in configuration.

Case 2

The first complication we consider is when the ISP doesn't provide direct access to the Web but instead requires that the users go to the Web via their Web proxy, usually a caching proxy, like Squid or Microsoft Proxy. For example:

[ (browser) ]<-->[ ISP ]<==> [ISP's proxy] ]<======> Web

In this case, the user simply configures the Guidescope Proxy to "chain" to the ISP's proxy:

[ (browser) <-> (GS) ]<-->[ ISP ]<==> [ISP's proxy] ]<======> Web

After configuring the browser as in Case 1, this "proxy chain" can be established by either:

Visiting the special URL "http://set.proxy/host:port", where host is the ISP's proxy host and port, or
Creating a file in the directory with the Guidescope software called "forward.ini" that contains the single line:
```
*   host:port   .    .
```
Note there are four fields and the last two are "." (dot).

This is the simplest configuration for a "forward file." It does nothing except send all requests on to the specified host and port.

Cases 1 and 2 are the two most common cases for non-business or SOHO users. For business users, the configurations are often more complex. Let's examine a few more examples:

Case 3

The business maintains its own "internal" network and provides a "packet filtering gateway," often simply a router, to provide access to the Web.

Since here we assumed that it doesn't already use a proxy for the employees' access to the Web, then this is much like a the situation in Case 1 and the Guidescope software can be either:

Run on each user's personal host, as in Case 1, or:
Run on a single server:
1. A host can be nominated as the business' proxy.
2. The software should be installed only on that host.
3. All users should point their browsers at that machine.
If this is the case, the Guidescope Proxy's configuration file would look something like this:

# bind port 8000 on all host
# addresses on this machine
listen-address :8000

# don't allow proxy users to
# change configuration options
disable-user-debug-config
disable-user-proxy-config

Option B is probably the better of the two, is clearly the easiest to implement, and requires the fewest resources. The Guidescope software itself is very "lightweight" so it can usually be run on a single machine that's shared without incurring a performance penalty.

Case 4

The business maintains its own "internal" network and provides a "Web proxy" to provide access to the Web.

This is much like Cases 2 and 3 and is best handled the same way:

Install the Guidescope software on a machine that is configured to proxy-chain to the business' proxy, then
Point the browsers at the Guidescope proxy.

The Guidescope configuration file would look just like the one in Case 3.B and the forward file would look like the one described in 1.B:

*    host:port    .      .

If the business' proxy is not a simple Web proxy but is instead a SOCKS4 proxy, simply change the forward file to read:

*    .   socks4  host:port

The above four cases (which are really just slight variations on the two basic situations of either having or not having an existing proxy) cover most of the "real world" configurations we've seen to date. If you have one that's markedly different, please let us know!

We have never personally seen the situation we use for an example in the next Case study but if we can imagine it, somebody is bound to have one in use that's even worse, so here goes:

Case 5

The business maintains a packet filtering gateway for access to the World Wide Web but it also has a firewall between the business' network at large and the Intra-network controlled by the Human Resources department. Assume that the HR department runs their own Web proxy called `hr-proxy' for their internal domain `hr.example.com'.

This situation would be very difficult for a regular browser to handle because it requires using a proxy for some "internal" domains but NOT for access to the rest of the Web. The Guidescope Proxy's forwarding lets you handle this easily. Just create a forward file that contains:

*              .               .   .
hr.example.com hr-proxy:2000   .   .

The first line sends requests directly to the Web but the second line sends those to `hr.example.com' to the HR proxy. This could be a little confusing unless you remember that, in the the forward file, the "last match wins."