[squid-users] Squid 4.x and Peek and Splice - Host Header Forgery

[garryd at comnet.uz]

On 2016-10-18 18:32, John Wright wrote:
> Hi,
> 
> I have a constant problem with Host header forgery detection on squid
> doing peek and splice.
> 
> I see this most commonly with CDN, Amazon and microsoft due to the
> fact there TTL is only 5 seconds on certain dns entries im connecting
> to.  So when my client connects through my squid i get host header
> issues due to the contstant dns changes at these destinations.
> 
> I have ready many things online but how do i get around this.  I
> basically want to allow certain domains or ip subnets to not hit the
> host header error (as things break at this point for me ).
> 
> Any ideas ?
> 
> One example is
> 
> sls.update.microsoft.com [1]
> 
> Yes my client and Squid use same DNS server, i have even setup my
> squid as a bind server and tried that just for fun same issue.  Fact
> is the DNS at these places changes so fast (5 seconds) the dns
> response keeps changing/
> 
> I just need these approved destinations to make it through
> 
> 
> 
> Links:
> ------
> [1] http://sls.update.microsoft.com/

Hi,

Are you sure, that Squid and all your clients use same _caching_ DNS 
server? For example, here results from my server for name 
sls.update.microsoft.com:

$ dig sls.update.microsoft.com
...
sls.update.microsoft.com. 
3345	IN	CNAME	sls.update.microsoft.com.nsatc.net.
sls.update.microsoft.com.nsatc.net. 215	IN A	157.56.77.141
...


Second request after 3 seconds:

$ dig sls.update.microsoft.com
...
sls.update.microsoft.com. 
3342	IN	CNAME	sls.update.microsoft.com.nsatc.net.
sls.update.microsoft.com.nsatc.net. 212	IN A	157.56.77.141
...


Here I see that the TTL for the target A record is 300 seconds (not 5 
seconds), and _caching_ DNS server will serve same A record for all 
clients at least 5 minutes. That behaviour will not introduce false 
positives for host forgery detection.



On other hand, if the DNS server is not _caching_, you would get 
different A records for each request. For example, below are results 
from authoritative DNS server for zone nsatc.net:


$ dig @e.ns.nsatc.net sls.update.microsoft.com.nsatc.net
...
sls.update.microsoft.com.nsatc.net. 300	IN A	157.55.240.220
...


Second request after 5 seconds:

$ dig @e.ns.nsatc.net sls.update.microsoft.com.nsatc.net
...
sls.update.microsoft.com.nsatc.net. 300	IN A	157.56.96.54
...


Here I see, that the DNS server serves exactly one A record in 
round-robin fashion. Same true for Google public DNS services. That 
behavior could cause troubles for host forgery detection.

HTH

Garri