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