[squid-users] Squid as Transparent Proxy

Tue Oct 10 11:26:47 UTC 2017

On 10/10/17 21:19, davide.motti wrote:
> Hi to everybody,
> 
> Last week I've set up Squid as transparent Proxy and everything seems to
> work fine, it cache HTTP and HTTPS connections without any problem.
> 
> The only think that "worries" me is that if I put the "intercept" flag
> on the http_port and on the https port I'm not able to connect to any
> site, but if I put off the "intercept" flag the I connect to all sites
> in transparent mode (no settings on the client's browser).

The configuration you have is not a "transparent proxy" unless you have 
the tproxy or intercept flags in squid.conf port lines. They are what 
tells Squid to do the MITM "transparent" things.

Also, you do not have any https_port in this config. So port 443 traffic 
cannot be received, no matter how it gets to Squid.

> 
> So I'm running Squid-3.5.27 on Ubuntu Server 16.04 LTS and it was so
> compiled:
> 
> ./configure --build=x86_64-linux-gnu --prefix=/usr --localstatedir=/var
> --libexecdir=${prefix}/lib/squid --datadir=${prefix}/share/squid
> --sysconfdir=/etc/squid --mandir=/usr/share/man
> --with-swapdir=/var/spool/squid --with-default-user=proxy
> --with-logdir=/var/log/squid --with-pidfile=/var/run/squid.pid
> --with-open-ssl=/etc/ssl/openssl.cnf --with-filedescriptors=65536
> --enable-ssl-crtd --enable-linux-netfilter.
> 
> The main squid.config file:
> 
> http_port
> 3128
> http_port 192.168.21.111:3129
> 
> http_port 192.168.21.111:13130 ssl-bump generate-host-certificates=on
> dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl_cert/myRCA.pem
>                       
>                       
>                       
> acl debian src 192.168.7.112
> acl debian src fe80::a2ce:c8ff:fe1e:bfb8
> acl localhost src 127.0.0.0/32
> acl SSL_ports port 443
> acl Safe_ports port 80
> acl Safe_ports port 443
> 
> acl Safe_ports port 21
> acl Safe_ports port 70
> acl Safe_ports port 3128
> acl Safe_ports port 3129
> acl Safe_ports port 403
> acl Safe_ports port 409
> acl Safe_ports port 210
> 
> acl Safe_ports port 1025-65535
> acl Safe_ports port 280
> 
> acl Safe_ports port 488
> acl Safe_ports port 591
> acl Safe_ports port 777
> acl CONNECT method CONNECT
> # HTTP ACCESS
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
>                                                               
> http_access allow localhost manager
> http_access allow debian
> http_access allow localhost
> 
> visible_hostname 20150604-004.intern.modomoto.de
>                                                                                    
> 
>                                                                                    
> 
> acl step1 at_step SslBump1
>                                                                                    
> 
> ssl_bump peek step1
> ssl_bump bump all
> sslproxy_options ALL
> sslproxy_cert_error allow all
> sslproxy_flags DONT_VERIFY_PEER

The above 5 lines disable *all* security that TLS has to offer. Chances 
of your network being " p0wned " are quite high.

This is also possibly why the intercept *appears* to work.

> sslcrtd_program /lib/squid/ssl_crtd -s /var/lib/squid/ssl_db -M 4MB
> sslcrtd_children 10
> 
> Squid iptables rules:
> 
> # Generated by iptables-save v1.6.0 on Mon Sep 25 09:34:12 2017
> *mangle
> 
> :PREROUTING ACCEPT [41705:23328287]
> :INPUT ACCEPT [40269:23242848]
> :FORWARD ACCEPT [6:2262]
> 
> :OUTPUT ACCEPT [32950:6122247]
> :POSTROUTING ACCEPT [33060:6138510]
> COMMIT
> # Completed on Mon Sep 25 09:34:12 2017
> # Generated by iptables-save v1.6.0 on Mon Sep 25 09:34:12 2017
> *nat
> 
> :PREROUTING ACCEPT [2731:496529]
> :INPUT ACCEPT [1440:370186]
> :OUTPUT ACCEPT [3278:202202]
> :POSTROUTING ACCEPT [41:2041]
> -A PREROUTING -s $CLIENT_IP -p tcp -m tcp --dport 80 -j DNAT
> --to-destination
>   $SQUID_IP:$HTTP_SQUID_PORT
> 
> -A PREROUTING -i $CLIENT_INTERF -p tcp -m tcp --dport 80 -j REDIRECT
> --to-ports $HTTP_SQUID_PORT
>                                                                                 
> 
> -A PREROUTING -s $SQUID_IP -p tcp -m tcp --dport 443 -j DNAT
> --to-destination $SQUID_IP:$HTTPS_SQUID_PORT
> -A PREROUTING -i $CLIENT_INTERF -p tcp -m tcp --dport 443 -j REDIRECT
> --to-ports
> $HTTP_CLIENT_PORT
> 
> -A POSTROUTING -o $CLIENT_INTERF -j MASQUERADE
> 
...

Why are you looping port 443 traffic outbound from Squid back into its 
receiving port?

And you have replaced most of the other important details with variable 
names. You have three HTTP ports (with various IPs) and zero HTTPS ports 
in squid.conf so its not even clear what these variables are referring 
to by name.

Please replace your iptables rules with the ones listed at 
<https://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxRedirect>

> 
> My client act as his own router and his iptables rules are the followings:
> 

REDIRECT/DNAT erases the destination IP Squid is connecting to when in 
"transparent" intercept mode. This is what you MUST NOT have any NAT 
between the client browser and Squid machine. Packets MUST be routed 
instead (possibly through a tunnel, but still routed).

> 
> As I told the intercept mode works without the "intercept flag" on the
> http_port directive: I would like just to know if it's normal or I miss
> something in my config.
> 

That is not normal, and not good at all. It hints that; a) the client is 
somehow sending proxy-format HTTP traffic over port 80/443 where only 
origin-format is permitted, or b) the proxy has been hacked to disable 
the CVE-2009-0801 hijacking protections.

Amos