On 18/02/2014 11:33 p.m., Nikolai Gorchilov wrote: > On Tue, Feb 18, 2014 at 10:30 AM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: >> On 18/02/2014 1:16 p.m., Nikolai Gorchilov wrote: >>> Hi Spyros, >>> >>> Seems you're experiencing request loops, that are unrelated to your ACLs >>> >>> Looking at the logs, we can clearly see pairs of requests for same >>> url. Like this: >>> 1392590890.301 0 192.168.1.20 TCP_MISS/403 4158 GET >>> http://www.tvxs.gr/ - HIER_NONE/- text/html >>> 1392590890.302 1 192.168.1.1 TCP_MISS/403 4263 GET >>> http://www.tvxs.gr/ - HIER_DIRECT/192.168.1.20 text/html >>> >>> As the logging happens at the end of transaction, records are ordered >>> by finish time, not start. They actually started in reverse order: >>> 1. First came the request from 192.168.1.1 for http://www.tvxs.gr/. >>> 2. As it was considered a MISS, your Squid decided to go directly to >>> the destination server (thus hierarchy code HIER_DIRECT) >>> 3. PROBLEM! PROBLEM! Surprisingly, Squid resolves www.tvxs.gr as >>> 192.168.1.20 and fires the request towards this IP! >> >> Sadly, NOT surprising: >> >> A) kernel NAT records on the Squid box indicate that no NAT alterations >> to the TCP packet took place there. >> >> B) TCP packet indicates that destination server is 192.168.1.20. >> >> ==> forward DIRECTly to original destination server (192.168.1.20). > > If Squid is running in intercept mode, I don't see a reason it cares > about dst ip. IMHO it has to resolve the host name and forward the > request there. Which hostname? TCP header dst IP 114.15.67.89 " GET http://google.com/ HTTP/1.1 Host: example.com ... " - Hint: neither google.com nor example.com is being sent this request. Get the wrong one and you just poisoned the cache and screwed over *all* users of the proxy :-( Overall gains: * better security * better transparency (some types of broken apps start working) * less trouble debugging broken routing from the client end * the "NAT" part can be reduced to just NPT instead of full NAPT > >>> 4. Boom! This is how the same request arrives again, this time from >>> source IP 192.168.1.20 (Squid itself). We have a loop! >>> 5. Squid detects the loop (something like "WARNING: Forwarding loop >>> detected" in cache.log) and generates internal error response like >>> HTTP/403 Forbidden, using ERR_ACCESS_DENIED or alike. Thus hierarchy >>> code is HIER_NONE. >> >> >> "SECURITY ALERT: Host header forgery detected" should also be showing up >> on the initial request processing. Since Squid validates whether >> (192.168.1.20 == www.tvxs.gr) => FAIL. > > Isn't this message only available when running TPROXY? No. Host: header validation is done with all of the TCP/IP traffic interception methods. Your possibly thinking of IP spoofing. Which is the client/src IP, not the dst IP. > >> http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery >> Amos
