• No end user configuration is required (via wpad.dat or Group Policy etc);
• If something breaks, it’s extremely simple to remove;
• Most people wouldn’t even know it was in place;

There are some downsides to this approach however:

• HTTPS traffic cannot be silently routed through the proxy server;
• NTLM authentication cannot be used

The best place to start is by setting up a Linux server. This can be physical or virtual, running whichever distribution you prefer (I’d go with Ubuntu, but the choice is yours). If linux isn’t your bag, the following Ubuntu install documentation will help.

This guide will use the following example configuration information:

Install and configure Squid

Once your Linux system is up and running, you’ll want to install the latest (stable) version of Squid. If you went with Ubuntu this couldn’t be easier:

# aptitude install squid3

We can accept a very basic configuration. The only change you need to make is to set the default squid port to be “transparent”. Change the following in /etc/squid3/squid.conf

http_port 3128 transparent

Configure iptables on the proxy server

We also need to configure the Linux kernel firewall (iptables) to forward any traffic routed to it on port 80 to the port used by our proxy server. This can be done as follows:

# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

Save our current iptables configuration using the iptables-save command:

# iptables-save > /etc/iptables.rules

We now need load the configuration whenever the network interface comes up, edit /etc/network/interfaces adding the following line to the relevant interface.

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.168.253
netmask 255.255.255.0
gateway 192.168.168.254
pre-up iptables-restore < /etc/iptables.rules

Finally, we’re onto the firewall configuration. This is going to vary depending on your device (Cisco PIX, Juniper Netscreen etc). My familiarity is with the ScreenOS product line so that’s what I’ll cover here.

Policy based routing (PBR) allows us to setup some pre-defined rules which determine how traffic is routed. In our scenario we want to route any outbound traffic from our corporate LAN destined for port 80 via a server on our network (or in a DMZ). The below instructions are for Juniper Netscreen firewalls running ScreenOS.

Policy Based Routing (PBR) requires ScreenOS 5.4 or later

Extended ACLs

An extended ACL is the criteria for matching certain traffic; each ACL can contain multiple matching rules. You may wish to match all traffic on port 80 destined for a few subnets, in which case you’d create an Extended ACL with multiple entries.

Create an ACL matching traffic from the corporate network for outbound HTTP traffic:

set access-list extended 10 src-ip 192.168.168.0/24 dst-port 80-80 protocol tcp entry 10

We also need to create an ACL so that our proxy server trafffic doesn’t get routed back to itself:

set access-list extended 20 src-ip 192.168.168.253/32 dst-port 80-80 protocol tcp entry 20

Match Groups

A match groups is a collection of one or more Extended ACL‘s, with a human-readable name. Create a match group named “Proxy” with an ID of 10 containing our extended ACL.

set match-group name Proxy
set match-group Proxy ext-acl 10 match-entry 10

We need to create another match group so that we can exclude systems from being routed through the proxy

set match-group name DirectHTTP
set match-group DirectHTTP ext-acl 20 match-entry 20

Action Groups

A group of one or more actions to perform, when multiple actions are available the first action is used. Create an action group which routes traffic to the proxy server on our internal network.

set action-group name Proxy
set action-group Proxy next-interface ethernet0/0 next-hop 192.168.168.253 action-entry 10

We now need to create another action group that routes traffic as it would do normally:

set action-group name DirectHTTP
set action-group DirectHTTP next-interface ethernet0/2 action-entry 10

Policy

A policy combines what we’ve created so far. When no policy is matched the normal routing tables are used. Create a new policy named “Proxy” with two entries. The first ensures that non-proxy traffic gets routed normally, the second routes traffic through the proxy.

set pbr policy name Proxy
set pbr policy Proxy match-group DirectHTTP action-group DirectHTTP 10
set pbr policy Proxy match-group Proxy action-group Proxy 20
exit

Policy Binding

The final step is to apply (or, ‘Bind’) the policy so that it takes effect. We have a few choices as to where we can bind the policy:

• A virtual router
• A zone
• An interface

We can apply multiple bindings, in which case the most specific binding takes effect. In our configuration we’ll bind the policy we’ve created to traffic passing out of our “Trust” interface:

set interface ethernet0/0 pbr Proxy

And there you have it, your outbound HTTP traffic is now being silently routed through a proxy server.

##
# Fix support.microsoft.com
##
acl fixSupportMicrosoft dstdomain support.microsoft.com
reply_header_access Accept-Encoding deny fixSupportMicrosoft
request_header_access Accept-Encoding deny fixSupportMicrosoft

What you’re doing there is preventing the Microsoft support site from gzip’ing their content.

So, without further ado go checkout my Squid Top Site Report Generator and get yourself some reporting goodness.

However, I wanted to produce a report visible to anyone who wanted to view the previous days statistics so modified a Perl script written by someone in 2003,since in all likelihood I’ll be updating it from time to time you can download yourself a copy here. I’ll try and get a demo up tomorrow as an example of its output.