[squid-users] Host header forgery detected on domain: mobile.pipe.aria.microsoft.com

[Eliezer Croitoru]

Hey Alex,

The main issue now is the extensive logging.
For a tiny server with a single desktop client the cache.log  are expending a *lot*.
I have a problem with discarding these logs but for this specific case where the ttl is very low ie: lower < 30/20/10 seconds
We can expect for this to happen so we can disable the logs since the service continue to work with this low ttl.
The only and main issue is the extensive logging which is wrong.

Should we continue this on Squid-dev?

Eliezer

----
Eliezer Croitoru
Tech Support
Mobile: +972-5-28704261
Email: ngtech1ltd at gmail.com
Zoom: Coming soon


-----Original Message-----
From: Alex Rousskov <rousskov at measurement-factory.com> 
Sent: Wednesday, January 6, 2021 10:42 PM
To: squid-users at lists.squid-cache.org
Cc: Eliezer Croitoru <ngtech1ltd at gmail.com>
Subject: Re: [squid-users] Host header forgery detected on domain: mobile.pipe.aria.microsoft.com

On 1/6/21 2:49 PM, Eliezer Croitoru wrote:

> I am trying to think about the right solution for the next issue:
> SECURITY ALERT: Host header forgery detected on conn18767
> local=52.114.32.24:443 remote=192.168.189.52:65107 FD 15 flags=33 (local IP
> does not match any domain IP)

As you know, this has been discussed many times on this list before,
including recently[1]. I doubt anything has changed since then.

[1]
http://lists.squid-cache.org/pipermail/squid-users/2020-November/022912.html


> All of the hosts use the same DNS service in the LAN however for some reason
> both squid and the client are resolving different addresses
> in a period of  10  Seconds.

The "however for some reason" part feels misleading to me -- what you
observe is the direct, expected consequence of the low-TTL environment
you have described. There is no contradiction or uncertainty here AFAICT.


> The solution I am thinking is to force a minimum of 60 seconds caching using
> dnsmasq or another caching service.

FTR: Increasing DNS response TTL will reduce the number/probability of
false positives in forged Host header detection. No more. No less.


> Can we teach (theoretically) squid a way to look at these short TTLs as
> something to decide by an ACL?

Yes, it is possible. There is positive_dns_ttl already which specifies
an upper bound. One could add a similar positive_dns_ttl_min option that
would specify the lower bound. Like virtually any Squid directive, it
can be made conditional on ACLs.

IMO, violating DNS TTLs is not the right solution for this problem
though. See my response on the [1] thread for a better medium-term solution.


HTH,

Alex.