On 1/6/21 10:26 PM, Eliezer Croitoru wrote: > The main issue now is the extensive logging. Please note that excessive logging may be the main issue for you and _some_ Squid admins. For many, the main issue is denied transactions. For some, it is cache misses. For some, it is a combination of things. These facts make any single simple solution inapplicable to some use cases. For example, you can trivially decrease the number (or, with a few more code lines, frequency) of these messages, but it will not help with the other problems I mentioned. FWIW, Factory is working on making all level-0/1 messages configurable that way, but we need more time to finish that project. This does not mean that any simple partial solution is going to be rejected, but please be very careful/specific in defining the problem when proposing (or asking for) a solution. > Should we continue this on Squid-dev? IMO, if you are going to discuss the problem and possible functionality-level solutions, then squid-users may be the best place for that. If you are going to discuss code changes and similar developer-level issues, use squid-dev. Alex. > -----Original Message----- > From: Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> > Sent: Wednesday, January 6, 2021 10:42 PM > To: squid-users@xxxxxxxxxxxxxxxxxxxxx > Cc: Eliezer Croitoru <ngtech1ltd@xxxxxxxxx> > Subject: Re: 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. > > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
