Transparent Squid Proxy

Over the holidays, I had a user experience and attempted browser hijacking. It appeared to have bypassed my squid proxy. My updated configuration now sends all web access via squid. The old firewall rules, that allowed direct access to the Internet, have been replaced with a transparent Squid proxy. This runs on my existing Squid Proxy using another port.

Configuring Squid

Enabling the transparent proxy is simply done by adding a single line to the configuration. The following lines enable a web proxy on port 3128 and a transparent proxy on port 3129. HTTPS access does not work on the transparent proxy and must either be allowed direct Internet access or handled by the web proxy.

http_port 3128
http_port 3129  transparent

After upgrading my squid 2.9 implementation I upgraded to squid 3.0. This has the localnet definition and acl commented out. Service for the LAN is enabled by removing the comment marks from the appropriate lines. To enable the 192.168 private network block the following lines are needed. (They are comments at the appropriate place  in the Ubuntu squid.conf file.)

acl localnet src 192.168.0.0/16        # RFC1918 possible internal network
http_access allow localnet

Configuring Shorewall

I build my iptables rules using Shorewall on two firewalls. My external/wifi router/firewall runs OpenWRT, and my internal router/firewall is an Ubuntu server hosting a DMZ with virtual servers. To handle web servers on non-standard ports I have a WebX macro that handles the extra ports. The parameter $SQUID contains the IP address of my squid server.

On the wifi firewall, I changed two rules to use DNAT (Destination Network Address Translation) for outgoing web traffic. This traffic was previously allowed.  The new rules read:

HTTP(DNAT)      loc             dmz:$SQUID:3129  -     -     -  !192.168.0.0/24
WebX(DNAT)      loc             dmz:$SQUID:3129

On the Ubuntu server, I ran into problems with configuring my DNAT rules until I replaced dmz with net in the destination. It requires additional rules as it needs to pass traffic that has already had DNAT applied and handle redirection for the server.

ACCEPT          loc             dmz             tcp     3129
HTTP(DNAT)      $FW             net:$SQUID:3129 -       -    -  !192.168.0.0/24,127.0.0.1
HTTP(DNAT)      loc             net:$SQUID:3129 -       -    -  !192.168.0.0/24
WebX(DNAT)      loc             net:$SQUID:3129

The ordering of your firewall rules is important. If you run services on one of the ports covered by the WebX macro, you will need to accept those connections before the WebX(DNAT) redirection or exclude the original destination excluded as was done for the HTTP(DNAT) specifications.

Shorewall macro.WebX definition

The above rules refer to a non-standard WebX macro. The following is a sample macro. Over time you may find you want to add or remove ports, depending on the sites your users’ access. Alternatively, you can allow the squid server more open access to the Internet, and require the use of the web proxy for non-standard ports. This needs to be placed in your Shorewall directory or a directory on your Shorewall CONFIG_PATH. I use /etc/shorewall/common which is added to my CONFIG_PATH.

#
# Shorewall version 4 - WebX Macro
#
# /etc/shorewall/common/macro.WebX
#
#       This macro handles traffic for extra Web ports.
#
###############################################################################
#ACTION SOURCE  DEST    PROTO   DEST    SOURCE  ORIGINAL        RATE    USER/
#                               PORT    PORT(S) DEST            LIMIT   GROUP
PARAM   -       -       tcp     81,82,4004,6180,8000,8010,8080,8081,8088,8180,8880 # Extra Web ports
PARAM   -       -       tcp     7001                            # AFS

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Cookie Consent with Real Cookie Banner