[squid-users] Response Blocked from sites with multiple IPs (Host Header Forgery)

Eng Hooda eenghooda at yahoo.com
Sat Jun 11 16:44:20 UTC 2016


Thank You for your response.
What is the best way to setup recursive resolver ?

Best Regards,
Eng Hooda

--------------------------------------------
On Fri, 6/10/16, Amos Jeffries <squid3 at treenet.co.nz> wrote:

 Subject: Re: [squid-users] Response Blocked from sites with multiple IPs (Host Header Forgery)
 To: squid-users at lists.squid-cache.org
 Date: Friday, June 10, 2016, 12:54 AM
 
 On 10/06/2016 6:09 a.m.,
 Eng Hooda wrote:
 > Hello Squid Users,
 > I have just started using squid less than
 a week ago .
 > My setup is a transparent
 proxy with sslbump , I peek for media streaming sites then
 terminate their connections then I splice all.
 > I noticed that some https sites (not all
 of the time) , does not respond , when Investigated I found
 the following in cache.log :
 > 
 > 3105 2016/06/09 12:45:40.630 kid1|
 SECURITY ALERT: on URL: mail.live.com:443
 > 3106 2016/06/09 12:45:40.631 kid1|
 SECURITY ALERT: Host header forgery detected on
 local=157.55.43.16:443 remote=10.3.1.80:58328 FD 94 flags=33
 (local IP does not match any domain IP)
 >
 3330 2016/06/09 13:26:26.676 kid1| SECURITY ALERT: on URL:
 mail.live.com:443
 > 3331 2016/06/09
 13:26:26.676 kid1| SECURITY ALERT: Host header forgery
 detected on local=157.56.122.210:443 remote=10.3.1.80:58414
 FD 141 flags=33 (local IP does not match any domain IP)
 > 3530 2016/06/09 13:49:49.481 kid1|
 SECURITY ALERT: on URL: mail.live.com:443
 > 3531 2016/06/09 13:49:49.481 kid1|
 SECURITY ALERT: Host header forgery detected on
 local=157.55.43.17:443 remote=10.3.1.80:58616 FD 119
 flags=33 (local IP does not match any domain IP)
 > 
 > I searched for a
 solution which lead me to (1st result)  :  
 > http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery
 > 
 > I read it and it
 seems to be a dead end .
 > 
 > What I understood that client requested
 page from a certain IP , reply came from another IP then
 it's blocked for security reasons.
 >
 
 > 
 > Well I tried to
 nslookup the mentioned IPs , and all of them are sub domains
 of mail.live.com
 
 No, all of
 them claim to be in their reverse-DNS responses. That is
 just
 the IP address owners view of things.
 In the case of an attack its the
 attackers
 opinion about what you should believe. Not safe.
 
 Forward-DNS results which
 provide the domain owners authoritative list
 of what IPs they are using. Say a different
 message contradicting those
 reverse-DNS
 results ...
 
 
 > also tried to nslookup mail.live.com , and
 every time I get different IPs
 > 
 
 Exactly. So do Squid and the
 client. Which means Squid is almost always
 unable to see the IP the client is contacting
 as being a valid one for
 that domain.
 
 
 > nslookup mail.live.com
 > Server: 
 google-public-dns-a.google.com
 >
 Address:  8.8.8.8
 > 
 
 It is a problem caused by
 Google DNS.
 
 The best way to
 get around it is to setup a recursive resolver on your
 network that is used by both Squid and clients.
 Diverting the client
 port 53 traffic to it
 if necessary.
 
 If you wish
 to use Google DNS after having that available, then
 8.8.8.8
 should be setup as a parent of that
 local resolver. Not as something
 Squid or
 client contact separately.
 
 That setup makes the google DNS results more
 often be cached in the
 shared resolver for
 long enough that Squid can see it when it does the
 validation steps.
 
 NP: there are other causes of this known,
 related to connection
 persistence, and
 SSL-Bump SNI being validated. They are bugs in Squid
 and still being worked on fixing. So dont
 expect the above to solve all
 instances of
 it.
 
 Amos
 
 _______________________________________________
 squid-users mailing list
 squid-users at lists.squid-cache.org
 http://lists.squid-cache.org/listinfo/squid-users


More information about the squid-users mailing list