Search squid archive

Re: range_offset_limit not working as expected

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/09/2016 9:14 p.m., Omid Kosari wrote:
> It is tproxy cache . Is there a way to force caching them .

No, and trying to do so is a VERY bad idea. I cannot stress enough how
bad it is.  Allowing remote attackers to completely (and invisibly)
bypass almost all other security measures you might have in your
network, just for starters.

I fully realise that not being able to cache a fairly large chunk of CDN
hosted traffic is extremely annoying and also can be costly. But the
risks of this particular vulnerability outweight that price tag.


> current configs:
> host_verify_strict off
> client_dst_passthru on
> 
> dns_nameservers x.y.160.172
> dns_nameservers 217.218.155.155
> dns_nameservers 217.218.127.127
> dns_nameservers 8.8.8.8
> dns_nameservers 8.8.4.4
> dns_nameservers 208.67.222.222
> dns_nameservers 208.67.220.220
> dns_nameservers 208.67.222.220
> dns_nameservers 208.67.220.222
> 
> The first dns server is our caching dns server and its parents dns servers
> are the others which appears in this config . Users dns traffic intercepted
> to x.y.160.172 .
> 
> So the problem seems the cdn dns round-robin . Is there a way to solve that
> ?

Use only that first DNS server in your squid.conf. Using it as an
aggregation point reduces the impact, but only if it is also the sole
point of resolving for Squid.
 NP: this is not a fix, just a workaround to reduce impact until Squid
DNS system can be updated to do things better.

Amos

_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux