Home / / Implementing PBR and Squid as a Transparent Proxy

Implementing PBR and Squid as a Transparent Proxy

, ,



There are various methods of implementing URL filtering in an organization, my preferred approach is to silently route traffic through a proxy server. This has a few distinct advantages:
  • 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 CentOS, but the choice is yours).

This guide will use the following example configuration information:

Corporate network 192.168.168.0 / 24
Corporate network gateway 192.168.168.254
Trust (Internal) interface on firewall ethernet0/0
Untrust (External) interface on firewall ethernet0/2
Proxy server address 192.168.168.253

Install and configure Squid

Once your Linux system is up and running, you’ll want to install the latest (stable) version of Squid. 
 
# yum 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.
 

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. 




















    







      

    































          



            
          






























Powered by Blogger.