[squid-users] Squid: forward to another squid server with authentication

Wed Dec 16 02:49:55 UTC 2015

On 16/12/2015 1:03 p.m., Amaury Viera Hernández wrote:
> Hello everyone. This is a more detailed explanation about my
> trouble:
> 

The more detailed explanation makes it clear that you are not going to
be able to use the login=PASSTHRU workaround for getting NTLM to work.
Clients that are intercepted simply *cannot* authenticate to a proxy. So
there is nothing to pass through.

That leaves you with Negotiate or Basic authentication credentials
explicitly added by your proxy.

Be aware that doing what you intend will make you and your student
account personaly responsible for *all* traffic that goes through your
proxy to the upstream. If anyone else manages to hook into your wifi AP,
they will essentially have free access and you pay the costs.

<snip>
> 
> I'm using ubuntu 15.10 with squid3 (3.3.8)
> 
> I have this configuration in squid.conf (This is very functional for
> local domain(without proxy authentications, against the local
> domains, for example: intranet.uci.cu, but for internet domains I
> need to authenticate(cache_peer my proxy with the proxy of my
> university)) )
> acl SSL_ports port 443
> acl Safe_ports port 80          # http
> acl Safe_ports port 21          # ftp
> acl Safe_ports port 443         # https
> acl Safe_ports port 70          # gopher
> acl Safe_ports port 210         # wais
> acl Safe_ports port 1025-65535  # unregistered ports
> acl Safe_ports port 280         # http-mgmt
> acl Safe_ports port 488         # gss-http
> acl Safe_ports port 591         # filemaker
> acl Safe_ports port 777         # multiling http
> acl CONNECT method CONNECT
> acl localdst dstdomain
> acl mi_red src 10.42.0.0/24
> http_access allow mi_red

So anyone connecting from 10.42.0.0/24 is allowed through this proxy.
With absolutely zero protections. That is bad.

At the very least move the "allow mi_red" line down ...

> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> http_access allow localhost manager
> http_access deny manager

... to here.

> http_access allow localhost
> http_access deny all
> http_port 10.42.0.1:3128 transparent

3128 is the registered Squid port for foward/explicit-proxy
communications. It should remain in squid.conf but without the
"transparent" mode flag.

You should probably also set this port to be "127.0.0.1:3128" for yoru
situation.

You should pick another port number randomly for the intercept and use
that for "intercept" mode traffic. There are also additional parts to
the firewall script, which I will cover below.

Also, notice that NAT port is "intercept" not "transparent".

Please run "squid -k parse" and fix any warnings it produces about other
things. I'm only mentioing the big ones which that old version  might
not be able to mention.

> coredump_dir /var/spool/squid3
> refresh_pattern ^ftp:           1440    20%     10080
> refresh_pattern ^gopher:        1440    0%      1440
> refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
> refresh_pattern (Release|Packages(.gz)*)$      0       20%     2880
> refresh_pattern .               0       20%     4320
> cache_mem 512 MB
> cache_dir ufs /var/spool/squid3 2048 16 256
> cache_effective_user proxy
> cache_effective_group proxy
> half_closed_clients off
> maximum_object_size 1024 KB
> cache_swap_low 90
> cache_swap_high 95
> memory_pools off
> error_directory /usr/share/squid3/errors/es/
> access_log /var/log/squid3/access.log squid

This ...

> cache_peer 10.0.0.1 parent 8080 0 no-query default no-digest login=avhernandez:MyPass
> never_direct allow all

... is correct for sending Basic auth credentials to the upstream. That
may work, but is not very secure.

Your Squid should also be capable of the login=NEGOTIATE method of
authentication. If that works with the upstream proxy (it may or may
not) then it is better to use than Basic.

First do the firewall fixes below before experimenting with these
changes though.

> 
> I'm using this firewall script
> 

Best practice is to use the iptables-restore tool when scripting
firewall actions. Otherwise there are gaps in timing between the -F
flush command and rule setup during which any active traffic can slip
past your intended rules and have long-lasting effects on the connection
states.
IIRC it was setup the firewall manually with your rules, and use the
restore tool to save a config snapshot for fast loading by the script.

> #!/bin/sh
> # IP del servidor SQUID
> SQUID_SERVER="10.42.0.1"
> # Interface conectada a Internet
> INTERNET="enp4s0"
> # Interface interna
> LAN_IN="wlp2s0"
> # Puerto Squid
> SQUID_PORT="3128"

Change that to whatever you use in squid.conf for the intercept port.

> 
> # Limpia las reglas anteriores
> iptables -F
> iptables -X
> iptables -t nat -F
> iptables -t nat -X
> iptables -t mangle -F
> iptables -t mangle -X
> # Carga los modulos IPTABLES para NAT e IP con soporte conntrack
> modprobe ip_conntrack
> modprobe ip_conntrack_ftp
> echo 1 > /proc/sys/net/ipv4/ip_forward
> # Politica de filtro por defecto
> iptables -P INPUT DROP
> iptables -P OUTPUT ACCEPT
> # Acceso ilimitado a loop back
> iptables -A INPUT -i lo -j ACCEPT
> iptables -A OUTPUT -o lo -j ACCEPT

ICMP is a mandatory protocol, and needs to be allowed as well.
- When bad traffic is rejected by your machine it is ICMP packets that
do the rejection.
- When something is not quite working right it is ICMP error messages
which allow software like Squid to automatically repair or workaround
the damage. And to help you debug what is going on if manual attention
is needed.

> # Permite UDP, DNS y FTP pasivo
> iptables -A INPUT -i $INTERNET -m state --state ESTABLISHED,RELATED -j ACCEPT

The comment about "UDP, DNS y FTP pasivo" is does not match the rule it
is documenting.

The rule is allowing aready established connections from remote /
Internet clients to the servers running on your machine to fast-track
through the firewall.

That is normal and okay as a rule. The issue I am highlighting here is
that the comment is bad and may be making you think wrong.

You also need this rule to apply to all traffic, on all interfaces
(including "lo"). So remove the -i parameter.

This...

> # Establece el servidor como router para la red
> iptables --table nat --append POSTROUTING --out-interface $INTERNET -j MASQUERADE
> iptables --append FORWARD --in-interface $LAN_IN -j ACCEPT

... No. Remove.

There is a better MASQUERADE rule in the wiki page referenced below.

If you need to allow any traffic forwarding straight through your
machine. Do so only and specifically for individual ports or protocols.
You are not running a carrier network here.

For example; this is where you set DNS queries to be allowed:
 -t FORWARD -p udp --dport 53 -j ACCEPT
 -t FORWARD -p tcp --dport 53 -j ACCEPT

Given the phone involvement you may also want to look into whether it
wants VoIP ports. And email POP/IMAP/SMTP/Submit ports may also be
needed - be extra careful about random hijackers sending Spam on those
ones though.

> # acceso ilimiato a la LAN
> iptables -A INPUT -i $LAN_IN -j ACCEPT

That above one lets unconditionally all remote devices that can connect
to your wifi interface use any service on your machine. Which is bad.
Especially since you also unconditionally allow access through the proxy
in squid.conf.

If you need any rules on INPUT at all, you should make them specific to
the services you want to be available publicly. But remember that these
rules are for accessing services running directly on your machine - not
relevant when connecting to upstream or Internet servers.

Both INPUT and FORWARD are the main firewall protections against traffic
being sent into your machines software, or trying to forward through it
to other machines. Be very careful what you ACCEPT in those table rules.

> iptables -A OUTPUT -o $LAN_IN -j ACCEPT

This...

> # Redirige las peticiones de la red interna hacia el proxy
> iptables -t nat -A PREROUTING -i $LAN_IN -p tcp --dport 80 -j DNAT --to $SQUID_SERVER:$SQUID_PORT
> # Redirige la entrada al proxy
> iptables -t nat -A PREROUTING -i $INTERNET -p tcp --dport 80 -j REDIRECT --to-port $SQUID_PORT

... No. Remove.

For Squid use the rules on this wiki page (in the same order as shown),
instead of both sets above which I marked as "No. Remove".

<http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxDnat>

PS. Also dont forget that IPv6 exists. Your firewall settings *need* to
also correctly setup IPv6 access (or denial) with ip6tables. Since you
are working with a phone it is even more likely that IPv6 will be needed
than on a generic LAN / wifi.
 They should generally match your IPv4 settings. But there are some
small differences.

HTH
Amos