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:
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@xxxxxxxxxxxx
-----Original Message-----
From: squid-users [mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Eng Hooda
Sent: Saturday, June 11, 2016 7:44 PM
To: squid-users@xxxxxxxxxxxxxxxxxxxxx; Amos Jeffries
Subject: 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@xxxxxxxxxxxxx> wrote:
Subject: Re: Response Blocked from sites with multiple IPs (Host Header Forgery)
To: squid-users@xxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
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
