[squid-users] squid "internal?" loop - with no firewall nat going on..?
Klavs Klavsen
kl at vsen.dk
Thu Mar 12 09:11:39 UTC 2015
As i Understand intercept - that will only work (as you said) when NAT
is performed on the box that is to intercept (when I remove haproxy -
that means the squid box itself).
and I'm going to move the squid box to the same network as the
webservers - to be able to do it the routing way.
It seems this config should then be applicable "When Squid is in a DMZ
between the router and Internet" from
http://wiki.squid-cache.org/ConfigExamples/Intercept/IptablesPolicyRoute
But do I need to enable net.ipv4.ip_forward = 1 ?
But perhaps that is needed, for iptables/linux kernel to even evaluate
PREROUTING rules (which then dnat's the package into squid port 3129)?
I'd like to only allow packages out of the box, when coming from squid
(in case of some config issue - I'd like the squid-server NOT to route
stuff, which didn't go through squid program).
and then I figured I'd could ensure that from happening, by adding:
iptables -t nat -A OUTPUT --match owner --uid-owner squid -p tcp --dport
80 -j ACCEPT
iptables -t nat -A OUTPUT --match owner --uid-owner squid -p tcp --dport
80 -j ACCEPT
and then ofcourse allow "state RELATED,ESTABLISHED" and traffic I
actually "want" and have default policy DROP.
Klavs Klavsen wrote on 03/12/2015 09:13 AM:
> Hi Amos,
>
> Thank you for the walkthrough..
>
> Instead of having to play with tproxy on haproxy currently, I figured
> i'd try a simpler route..
>
> The purpose of this setup, is to "jump around" a firewall issue with a
> sh#! firewall, which in order to filter http and https traffic
> appearently drops 5-15%.. and in 6 months noone has seem willing/able to
> fix it :(
>
> I've put squid directly on the 10.43.18.181 (previously haproxy) ip -
> and changed to: http_port 80 intercept
>
> I tried this on the client (being on other subnet):
> iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination
> 10.43.18.181:80
>
> and the traffic looped in exactly the same way :(
>
>
> Amos Jeffries wrote on 03/10/2015 05:45 PM:
>> On 11/03/2015 4:08 a.m., Klavs Klavsen wrote:
>>> hmm..
>>>
>>> I've read the config examples..
>>>
>>> I would very much like to understand how/why it works, if I've setup a
>>> client to route package to squid (instead of trying to send directly)..
>>
>> I suggest diagramming your network traffic flow, writing down the TCP
>> packet src/dst IP:port values on each connection.
>>
>> "Normal" interception operation showing your loop:
>>
>> 1) curl thinks its talking to Internet server
>> src ip-of-curl:*
>> dst ip-of-bt.dk:80
>>
>> 2) NAT diverts the packet to haproxy
>> src ip-of-curl:*
>> dst ip-of-haproxy-machine:*
>>
>> 3) haproxy knows its talking to Squid
>> src ip-of-haproxy-machine:*
>> dst 10.43.18.165:3129
>>
>> 4) Squid machine reports un-mangled NAT is ...
>> src ip-of-haproxy-machine:*
>> dst 10.43.18.165:3129
>>
>> 5) Squid contacts dst-IP to fetch the HTTP request
>> src 10.43.18.165:*
>> dst 10.43.18.165:3129
>>
>> 6) repeat from 4 (but with src now 10.43.18.165:*) until
>> a) machine runs out of memory,
>> b) machine runs out of TCP sockets,
>> c) machine runs out of disk space logging errors, or
>> d) Squid notices Via header loop and rejects request.
>>
>>
>> A "Normal" connection directly to squid port:
>>
>>
>> 1) curl thinks its talking to Internet server on 10.43.18.165:3129
>> src ip-of-curl:*
>> dst 10.43.18.165:3129
>>
>> 2) Squid machine reports un-mangled NAT is ...
>> src ip-of-curl:*
>> dst 10.43.18.165:3129
>>
>> 3) Squid contacts dst-IP to fetch the HTTP request
>> src 10.43.18.165:*
>> dst 10.43.18.165:3129
>>
>> 4) repeat from 2 (but with src now 10.43.18.165:*) until
>> a) machine runs out of memory,
>> b) machine runs out of TCP sockets,
>> c) machine runs out of disk space logging errors, or
>> d) Squid notices Via header loop and rejects request.
>>
>>
>>
>> Confirm it against wireshark packet traces of what is coming *in* to the
>> Squid machine.
>>
>> Squid undoes the NAT mangling done on the machine its running. Any NAT
>> changes prior to that is unknowable. NAT un-mangling can sometimes
>> appear to work in Squid if haproxy runs on the same machine BUT, some
>> NAT lookup requires correct TCP socket and some require particular
>> IP:port ordering so its unrelible.
>>
>>
>> The Squid access.log lines with ORIGINAL_DST show what client src-IP and
>> dst-IP Squid received after NAT un-mangling. Though you have to take
>> care to subtract the duration value from the line timestamp to get the
>> order right for loops.
>>
>>
>>>
>>> I'm trying to follow this on a test client (haven't gotten it working
>>> yet):
>>> http://wiki.squid-cache.org/ConfigExamples/Intercept/IptablesPolicyRoute
>>> (where squid is amongst the internal clients - actually on it's own vlan
>>> - but it's not the default route)
>>
>> If its on its own VLAN then its not "among the clients".
>>
>> "among the clients" means a bunch of machines all on the same LAN
>> subnet, one of which is the Squid proxy. They can talk directly to each
>> other without involving the router so you can hit the triangular routing
>> problem and have to account for it in your forwarding and/or NAT rules.
>>
>> If you have Squid on a separate subnet or VLAN with all packets going
>> via the router, that is a DMZ subnet. The router sees all packets and
>> can adjusts them right, so triangular routing problem is avoided.
>>
>>
>>>
>>> meanwhile I tried pointing to the haproxy - which then forwards requests
>>> in tcp mode, to squid server port 3129.
>>>
>>> If I just send to haproxy directly, I get the loop and this in the
>>> accesslog:
>>> 1425998994.271 0 10.43.18.165 TCP_MISS_ABORTED/000 0 GET
>>> http://www.bt.dk/ - ORIGINAL_DST/10.43.18.165 -
>>>
>>> when doing:
>>> curl -H "Host: www.bt.dk" http://proxy-haproxy-ip/
>>>
>>> 10.43.18.165 is the ip of squid server behind haproxy.
>>
>>
>> Methinks that haproxy is still sending to the Squid port configured with
>> "intercept" option.
>>
>> A connection between two proxies is explicitly configured. Thus a normal
>> forward-proxy connection, no special port flags required.
>>
>>
>> The log line is also showing haproxy to be vulnerable to CVE-2009-0801.
>>
>> If your Squid and haproxy are recent enough they could use the PROXY
>> protocol to exchange the original client connections TCP/IP details.
>> I've not tested it for this myself but that may also allow Squid with an
>> intercept port to both handle the traffic okay (PROXY protocol override
>> the NAT lookups), and protect against the CVE-2009-0801 vulnerability in
>> haproxy ('intercept' flags existence makes Squid do the security checks).
>>
>>
>> Amos
>> _______________________________________________
>> squid-users mailing list
>> squid-users at lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
>>
>
>
--
Regards,
Klavs Klavsen, GSEC - kl at vsen.dk - http://www.vsen.dk - Tlf. 61281200
"Those who do not understand Unix are condemned to reinvent it, poorly."
--Henry Spencer
More information about the squid-users
mailing list