Re: [squid-users] Re: Squid transparent proxy with one nic access denied problem.

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Wed, 19 Feb 2014 04:04:49 +1300

On 18/02/2014 11:33 p.m., Nikolai Gorchilov wrote:
> On Tue, Feb 18, 2014 at 10:30 AM, Amos Jeffries <squid3_at_treenet.co.nz> 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
Received on Tue Feb 18 2014 - 15:04:58 MST

This archive was generated by hypermail 2.2.0 : Tue Feb 18 2014 - 12:00:06 MST