RE: [squid-users] Transparent Squid on FreeBSD with PF

On 2014-01-17 02:38, G VM wrote:
> ----------------------------------------
>> Date: Thu, 16 Jan 2014 23:39:43 +1300
>> From: squid3
>>
>>
>> Either auto-configuration (WPAD/PAC) or traffic interception / MITM:
>>
>>> No client side configuration.
>>
>> It sounds like you chose MITM over auto-configuration.
>>
>>
>>> This is how the network
>>> looks:
>>>
>>> Code: Select all
>>> client --- --- router/firewall --- internet
>>>            |
>>>       squid proxy
>>>
>>
>> Your diagram illustrates the client intercepting themselves. When
>> actually it is the firewall doing the interception then the router
>> handling the packet to/from the proxy.
>>
>> See the nice picture at
>> http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxDnat.
>>
>
> I believe I didn't explained this clearly. The "image" might have been
> messed up in the mail client which made it less clear.
>
> The proxy is actually in a star topology with the client and the
> router/firewall.
> The | and "squid proxy" should be more to the right. The proxy,
> router/firewall and client are on the same physical network(Layer 2).
>
> The client has it's gateway to the squid proxy(gateway configured
> through DHCP; autoconfig with DHCP didn't work as most browsers don't
> support it). The squid proxy is the machine with the rdr rules.
> The squid proxy has the router/firewall as gateway.
>
> So the router/firewall doesn't intercept the connections first.
>

Okay good.

<snip>
>>
>>> The Squid proxy server will then set up its
>>> own connection to the webserver with its own IP.
>>
>> That describes only the "intercept" option behaviour.
>
> Ok. What about the TPROXY behavior. It spoofs the IP of the client.
> Does that mean that the client just has a connection with the
> proxy(while it thinks it's connected to the webserver) and the proxy a
> connection to the website (while the website think it's the client)?
> And that this creates some sort of "tunnel" between client and website?
>

No tunnels.

>>
>>> Therefor
>>
>> No "therefore". You have now changed topic from packet interception to
>> TLS/SSL interception. Different beasties.
>>
>>> this won't work with HTTPS as it can't see the packet contents unless
>>> you use SslBump. SslBump creates a secure connection with the proxy
>>> server, which in his turn creates an SSL connection to the webserver.
>>
>>
>>> So
>>> this is a man-in-the-middle.
>>
>> NAT Interception is a MITM, so is TPROXY Interception and so is
>> Ssl-bump
>> interception. All three different interception/MITM mechanisms.
>>
>
> Ok. What I was actually wondering is if I need SSLbump in all cases
> for HTTPS(if I want to filter on domainname in an acl and what if I
> leave this domain name filter out).
>
>>> Because of this reason and you need to
>>> install a root certificate in the client browser I would like to have
>>> another method.
>>
>> That is only relevant to port 443 and ssl-bump mechanism.
>
> Well I don't want only access to half of the internet ;)
> So it's still relevant in my case.
>

Sure, but keep them separate in your thinking because they are different
layers in the network.

Maybe the OSI layering model would help here
(http://www.escotal.com/osilayer.html).

In this diagram NAT ("intercept" / rdr) operates solely at layer (3),
changing the packet IPs to one that will get delivered to the Squid
process.

TPROXY operates a little bit at each layer 2-4, taking the packet out of
layer-3 based on layer-2 details and passing it to a layer-4 socket
which will reach Squid.

HTTP/1.x contains a mix of all layer 5-7 operations.

SSL/TLS is more like a sub-layer between 4 and 5 on port 443 traffic. It
is performed by Squid on top of whatever layer 1-4 mechanisms are in use
but separate and underneath HTTP mechanisms.

>>
>>>
>>> From
>>> what I understand TPROXY can accomplish this(however not sure how
>>> squid
>>> will check then which domain name is accessed).
>>
>> Domain details are in the HTTP message. Which is processed the same to
>> locate it regardless of mechanism.
>>
>>
>>> If I understand it
>>> correctly TPROXY acts as the client (sending IP packets to the
>>> webserver
>>> with the client's IP).
>>
>> Nope. Squid acts as a client. Always.
>>
>> TPROXY *spoofs* the client IP for outgoing TCP connections.
>
> Ok. Clear. So if I get this right TPROXY won't give me(in my setup)
> any advantage over intercept(the router/firewall to the internet does
> masquerading; otherwise TPROXY would give the advantage that IP based
> authentication would work).

Essentially. It comes down to whether you want to get rid of that NAT or
not.

>
>>
>>> It's not clear if the client will still have an
>>> SSL connection to the proxy server or not (I would think it still
>>> has,
>>> as otherwise the client should be aware that it has to sent requests
>>> with https:// just in cleartext to the proxy, which is not secure,
>>> and
>>> this doesn't seem very "transparent" anymore).
>>
>>
>>> Does TPROXY still need
>>> SslBump configured?
>>
>> TPROXY and ssl-bump are not related other than both being ways to
>> intercept traffic.
>
> But sslbump is necessary for making HTTPS work anyway(as you say Squid
> always acts as the client so squid actually sends the request to the
> webserver), right?

Yes.

>
>>
>>> As there is no man-in-the-middle here I would think
>>> domain names in requests can't be seen and squid can't react
>>> accordlingy
>>> to it.
>>
>> MITM is the category of operation being performed. It covers all
>> operations where the client and/or server is being deceived as to the
>> proxies existence.
>>
>>> If the latter is the case, what are the pros for using TPROXY? In the
>> end the packets still have to go through your Squid server where they
>> can be intercepted.
>>>
>>
>> TPROXY avoids the need for NAT packet mangling and all the security
>> problems which come with it. At the beginning TPROXY was also the only
>> way to cleanly do interception for IPv6 traffic, that has now changed.
>>
>
> Not sure what you mean by "NAT packet mangling". And with security
> problems you mean eavesdropping in the packet?

No I mean:
* external parties being able to do "NAT busting" to penetrate through
the firewall rules by detecting an existing NAT'ed connection.
* obfuscation of connection details for tracking down any bad behaviour
after the fact.
* and upper-layer protocol issues in HTTP, FTP and SIP (such as
demonstrated by CVE-2009-0801).

> Is there any article or reference you have where these problems are
> explained and how TPROXY fixes this?

TPROXY does not alter the packets, so there are no NAT records to be
"busted" and all packet information is available for tracking and record
keeping. Whatever security you apply to the client will work regardless
of whether the proxy and TPROXY rules are present or not with no special
cases for pre/post NAT IP addressing. Simpler security rules are more
manageable and usually safer.

>
>>
>>> Anyway
>>> I configured PF. I read that I need ipdivert.ko which is available in
>>> my kernel and need divert-to rules for using TPROXY.
>>>
>>> I got squid running with Intercept using the rdr rules:
>>>
>>> rdr pass on $lan_if inet proto tcp from 192.168.1.32 to any port 443
>>> -> 127.0.0.1 port 3129
>>> rdr pass on $lan_if inet proto tcp from 192.168.1.32 to any port 80
>>> -> 127.0.0.1 port 3128
>>>
>>> However for TPROXY I should use divert-to right?
>>>
>>> pass in quick log on em0 proto tcp from 192.168.1.32 to any port 80
>>> divert-to localhost port 3128
>>> pass in quick log on em0 proto tcp from 192.168.1.32 to any port 443
>>> divert-to localhost port 3129
>>>
>
> The Squid site actually has an article about squid with PF and
> TPROXY(however specific for OpenBSD).
> When using the rules provided there I get an error that divert-reply
> isn't valid on freebsd.
> I'm not sure if letting this divert-reply rule out (which removes the
> warning of course) doesn't need another rule to replace that
> functionality.
>

Okay. As you said that was for OpenBSD, which has a quite different
version of PF.

There is one for FreeBSD
(http://wiki.squid-cache.org/ConfigExamples/Intercept/FreeBsdPf).
It is a bit old now so you may still have a bit of trouble, any updates
you can make to ensure it works on current FreeBSD are welcome.

>>
>>> Please
>>> correct me if I'm wrong at any point. It would greatly increase my
>>> understanding of the matter and probably help in solving issues. What
>>> way should I go here to get the explained goal?
>>>
>>
>> Get it going with just port-80 for starters. Once that is done add
>> identical PF and routing rules for port-443 before you start with
>> ssl-bump pieces in squid.conf for the SSL/TLS protocol layer.
>
> Ok. I got it working with intercept for both HTTP and HTTPS and the
> rdr rules in Freebsd PF.
> I'll try to do the same for HTTP with TPROXY first.
>
>
> From all what I've read here, it seems that anyway I configure squid,
> something has to be done on the client.
> Either
> - auto-configuring (which should still be picked up by the client)
> - configuring the browser to use a proxy
> - configuring the browser to add a root certificate
>

Yeah. No magic bullet sorry.

Amos
Received on Thu Jan 16 2014 - 22:25:14 MST