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

Sun Jun 12 18:59:34 UTC 2016

Hey,

There are couple options to do that.
Since you are using Debian 8 the most used are:
-	Bind
-	Unbound
They both have a very simple installation and configuration.
The first step would be to let squid access the caching service.
If you can point your clients to this specific DNS host it would be good but if not and you are able to Intercept DNS traffic,
you can try to see how Interception of all 8.8.8.8 and other dns services works.
You can use the iptables REDIRECT which is similar to what you might use in\for squid.
The next tutorial is for CentOS but have the needed configuration snippets that would work with any Unbound installation:
http://www.tecmint.com/setup-dns-cache-server-in-centos-7/
And another one which looks a bit different
https://calomel.org/unbound_dns.html

And another guide for ubnutu on using Bind as a caching dns service:
https://www.digitalocean.com/community/tutorials/how-to-configure-bind-as-a-caching-or-forwarding-dns-server-on-ubuntu-14-04

Which should work almost the same for Debian.

If you need more details let me know.

Eliezer

----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: eliezer at ngtech.co.il

-----Original Message-----
From: squid-users [mailto:squid-users-bounces at lists.squid-cache.org] On Behalf Of Eng Hooda
Sent: Saturday, June 11, 2016 7:44 PM
To: squid-users at lists.squid-cache.org; Amos Jeffries
Subject: [squid-users] Response Blocked from sites with multiple IPs (Host Header Forgery)

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
_______________________________________________
squid-users mailing list
squid-users at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160612/7da989f7/attachment-0001.html>