[squid-users] squid 3.5.24 Host header forgery detected

Thu Mar 9 13:25:02 UTC 2017

On 7/03/2017 12:43 a.m., hellname hellname wrote:
> Hello. I have the squid 3.5.24 from source:
> configure options:  '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/include' '--mandir=/share/man' '--infodir=/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=/lib/squid' '--srcdir=.' '--disable-maintainer-mode' '--disable-dependency-tracking' '--disable-silent-rules' '--datadir=/usr/share/squid' '--sysconfdir=/etc/squid' '--mandir=/usr/share/man' '--enable-inline' '--disable-arch-native' '--enable-async-io=8' '--enable-storeio=ufs,aufs,diskd,rock' '--enable-removal-policies=lru,heap' '--enable-delay-pools' '--enable-cache-digests' '--enable-icap-client' '--enable-follow-x-forwarded-for' '--enable-auth-basic=DB,fake,getpwnam,LDAP,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB' '--enable-auth-digest=file,LDAP' '--enable-auth-negotiate=kerberos,wrapper' '--enable-auth-ntlm=fake,smb_lm' '--enable-external-acl-helpers=file_userip,kerberos_ldap_group,LDAP_group,session,SQL_session,unix_group,wbinfo_group' '--enable-url-rewrite-helpers=fake' '--enable-eui' '--enable-esi' '--enable-icmp' '--enable-zph-qos' '--enable-ecap' '--disable-translation' '--with-swapdir=/var/spool/squid' '--with-logdir=/var/log/squid' '--with-pidfile=/var/run/squid.pid' '--with-filedescriptors=65536' '--with-large-files' '--with-default-user=proxy' '--enable-ssl' '--enable-ssl-crtd' '--with-openssl' '--enable-linux-netfilter' 'CFLAGS=-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wall' 'LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security' 'build_alias=x86_64-linux-gnu'
> 
> I also have this configuration:
> max_filedesc 35000
> acl localnet src 172.16.16.0/24
> acl localnet src 172.22.1.0/24
> acl SSL_ports port 443
> acl CONNECT method CONNECT
> acl AdminsIP src "/etc/squid/admips.txt"
> acl BlackList dstdomain "/etc/squid/BL.txt"
> acl BlockInetExlWhite src "/etc/squid/BI.txt"
> acl WhiteList dstdomain "/etc/squid/WL.txt"
> acl manager proto manager

"manager" ACL is now built-in. You can remove that incorrect definition.

> via off
> forwarded_for off
> follow_x_forwarded_for deny all

Remove the above line. It is defining a default, the only thing having
the above configured does is waste CPU calculating the header values.

> visible_hostname my.server.com
> hosts_file /etc/hosts

Above is also the default yes?

> dns_nameservers 172.16.16.11
> ipcache_size 10240
> negative_dns_ttl 5 minutes
> fqdncache_size 10240
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> http_access allow manager
> http_access deny manager

You already just "allow manager". The deny above will not work.

This looks like somebody got a bit confused about the current
best-practice when compared to old config files.

My 'best current practice' recommendation is for te top 4 http_access
lines to be:

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

.. naturally that only applies if an "allow localhost" is one of the
next http_access allow things done (see below).

If what you wanted was actually to allow *anybody* (literally anyone
including external to your network) to view your manager reports. Then
just remove that "deny manager" line.

> cachemgr_passwd password all
> http_access allow localhost
> http_access allow AdminsIP
> http_access deny BlockInetExlWhite !WhiteList
> http_access deny BlackList
> http_access allow localnet
> http_access deny all
> cache deny all
> http_port 0.0.0.0:3128 intercept
> http_port 0.0.0.0:3130
> https_port 0.0.0.0:3129 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl/myCA.pem
> always_direct allow all

Remove that always_direct. It is a bug workaround which was only valid
for a whole 2 months back in 2012 or so for squid-3.1.

> sslproxy_cert_error allow all
> sslproxy_flags DONT_VERIFY_PEER

Please remove the above. I really cannot stress enough how bad it is. It
completely and utterly removes all security from HTTPS.

DONT_VERIFY_PEER is of almost zero benefit and allows several whole
classes of attacks to be performed (completely invisibly to you and your
client) by *other* people attacking your Internet connections. Then
"sslproxy_cert_error allow all" forbids Squid from informing anybody
(including you!) about anything suspicious Squid might still be able to
detect.

Yes errors will happen in TLS/SSL. You *need* to know what those are,
and for that you *need* Squid to be doing the peer/server verification.

_Some_ errors can be ignored when used by certain servers. That is what
sslproxy_cert_error exists for. Use it sparingly.

> acl blocked ssl::server_name "/etc/squid/BL.txt"
> acl step1 at_step SslBump1
> ssl_bump peek step1
> ssl_bump terminate blocked
> ssl_bump splice all
> sslcrtd_program /lib/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB
> coredump_dir /var/spool/squid
> refresh_pattern ^ftp: 1440 20% 10080
> refresh_pattern ^gopher: 1440 0% 1440
> refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
> refresh_pattern . 0 20% 4320
> maximum_object_size 61440 KB
> minimum_object_size 3 KB
> cache_swap_low 90
> cache_swap_high 95
> maximum_object_size_in_memory 512 KB
> memory_replacement_policy lru
> logfile_rotate 0
> cache_mgr  admin at my.server.com  
> 
> All users in my company have enabled auto-proxy-config in OS with wpad url configuration, below you can see wpad.dat:
> function FindProxyForURL(url, host) {
> var proxy_on = "PROXY 172.16.16.30:3130";
> var proxy_off = "DIRECT";
> var network = "172.16.16.0";
> var network1 = "192.168.100.0";
> var subnet = "255.255.255.0";
> 
> var proxy_bypass = new Array(
> "*.slack.com",
> "*.slack-edge.com",
> "*.slack-msgs.com",
> "*slack-files.com",
> "*slack-imgs.com",
> "*slack-edge.com",
> "*slack-core.com",
> "*slack-redir.net",
> "192.168.100.0",
> "127.0.0.1",
> "localhost"
> );
> if (isInNet(host, network, subnet)) {
> return proxy_off;
> }
> if (isInNet(host, network1, subnet)) {
> return proxy_off;
> }
> 
> for (var i = 0; i < proxy_bypass.length; i++) {
> if (shExpMatch(host, proxy_bypass[i])) {
> return DIRECT;

I spy a bug. " return proxy_off; " ? there is no local variable called
DIRECT in this PAC file.

> }
> }
> 
> if (shExpMatch(url, "http:*") ||
> shExpMatch(url, "https:*") ||
> shExpMatch(url, "ftp:*")) {
> return proxy_on;
> }
> 
> // Finally, send all other requests direct.
> return proxy_off;
> }
> 

> I see the problems when to try work with slack app or gmail apps (e.g.
calendar), in the squid log I see many entries:
> 2017/03/06 14:38:03| SECURITY ALERT: Host header forgery detected on local=54.230.99.128:443 remote=172.16.16.123:64857 FD 748 flags=33 (local IP does not match any domain IP)
> 2017/03/06 14:38:03| SECURITY ALERT: on URL: slack.com:443

When the client (172.16.16.123) fetches the URL "slack.com:443" the
server IP your NAT system tells Squid about (local=54.230.99.128:443) is
not listed in the DNS records for the domain slack.com.

This page explains the situation:
<http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery>

Note that your PAC file sasy the proxy should not be used for that
domain. Yet still NAT'ing the traffic into ports 3128 and 3129. The
whole point of having a PAC file is to avoid NAT (and these types of
problem) in the first place.

Amos