Re: [squid-users] Conflicts with squid in transparent to Apache proxy and OpenVPN

Le mardi 13 septembre 2011 à 21:09 +1200, Amos Jeffries a écrit :
> On 13/09/11 20:15, David Touzeau wrote:
> > Dear bests
> >
> > I have this network configuration
> >
> > OpenVPN client -> Squid Proxy in transparent mode -> Internet -> APACHE
> > Proxy 80 -> OpenVPN 127.0.0.1:1194
> >
> > When the OpenVPN client try to send a CONNECT 127.0.0.1:1194 to the
> > Apache Proxy the Squid Proxy in the LAN (in Transparent mode) trap the
> > command and kill the connection.
> >
> > Which kind of acl i can set in order to force squid allowing this
> > connection ?
>
> You can add a relatively complex workaround (reverse-proxy for CONNECT
> to dstdomain 127.0.0.1 to that Apache as the peer) which will work for
> this one particular Squid. Or you can fix the Apache setup so it works
> across all transparent proxies.
>
>
> CONNECT - is a request for the receiving proxy (*any* proxy) to open a
> TCP connection to the specified IP:port. Squid is obeying that command.
>
> 127.0.0.1 is an IP address referring to the machine on which the
> application using it is operating (aka client machine sees it as itself,
> Squid sees it as itself, apache sees it as itself, routers and firewalls
> between see it as themselves...). It is not safe to be sent over the
> Internet. Due to exactly this type of problem. Deep packet inspectors
> will cause other problems as well.
>
> There is a giant security vulnerability of allowing requests to
> 127.0.0.1 through the Apache front gateway. I hope you have at least
> placed strict access controls to ensure that traffic accepted by Apache
> is not going to other localhost ports.
>
> The secondary problem which is making this visible is that Apache is
> operating a proxy on the native/non-proxy HTTP port 80. You will
> therefore have this exact same problem whenever the VPN link crosses
> anybody elses intercepting proxy. So a Squid workaround is not
> realistically going to be a full fix.
>
> To properly fix this the Apache end needs to be setup as a proper
> reverse-proxy. The setup concept is the same as what we do in Squid, but
> different config syntax. ie Clients use a public domain name which
> points them to the Apache at some port. Only Apache itself needs to know
> its relaying to 127.0.0.1. Sharing the 1194 port on the public domain is
> useful for simplicity and ease of administration.
>
> <snip>
> >
> > Squid.conf
> >
> > acl localhost src 127.0.0.1/32
> > acl to_localhost dst 127.0.0.1/32
>
> NP: to_localhost should be defined as "127.0.0.1/8 0.0.0.0/32" (maybe
> ::1 as well) to catch all the potential attacks it is meant to.
> <snip>
> >
> > # --------- RULES DEFINITIONS
> > url_rewrite_access deny localhost
> > url_rewrite_access deny whitelisted_mac_computers
> > url_rewrite_access allow all
> > http_access allow whitelisted_mac_computers
> > http_access allow AIM_methods AIM_ports AIM_nets
> > http_access allow AIM_methods AIM_ports AIM_hosts
> > http_access allow IRC_methods IRC_ports IRC_hosts
> > http_access allow IRC_methods IRC_ports IRC_domains
> > http_access allow YIM_methods YIM_ports YIM_hosts
> > http_access allow YIM_methods YIM_ports YIM_domains
> > http_access allow GTALK_ports GTALK_hosts GTALK_methods
> >
> > http_access allow GTALK_methods GTALK_ports GTALK_domains
> > http_access allow MSN_ports MSN_domains MSN_methods
> >
>
> NP: all of those special application ports are included in Safe_ports
> 1024-65535 range. You could bump "deny !Safe_ports" up the top for a bit
> faster processing on unsafe port attacks.
>
> > http_access deny !Safe_ports
> > http_access deny CONNECT !SSL_ports
> > http_access allow localhost
> > http_access allow manager localhost
> > http_access allow purge localhost
> > http_access deny purge
> > http_access deny blockedsites
> > http_access allow office_network
> > http_access deny to_localhost
>
> Deny to_localhost is only useful when its up above some allow rules.
> Usually up near the very top with Safe_ports and CONNECT is recommended.
> In this case it is probably best at the very top with Safe_ports.
>
> It's purpose is to short-circuit and quickly reject broken requests such
> as these CONNECT 127.0.0.1:1194 ones you are dealing with. So they do
> not lag or consume too much CPU resources doing more complex ACL tests.
>
>
> > http_access deny all
> > # --------- ICAP Services.(1 service(s))
> >
> <snip>
> > refresh_pattern . 0 100% 43200 reload-into-ims override-lastmod
> > refresh_pattern . 0 20% 4320
> > refresh_pattern -i (/cg-bin/|\?) 0 0% 0
>
> This cgi rule should be up one higher, above the "." rule.
>
> The "." rule itself captures every possible URL. So there is no point in
> having anything after the first "." pattern. They will never be used.
>
> HTH
>
> Amos

Thanks Amos

But browsing trough internet just allowing to set these Apache
directive :
        ProxyRequests On
        ProxyVia On
        AllowCONNECT 1194
        KeepAlive On

In order to make it works with OpenVPN

I did not see other directive allowing Apache to redirect
"transparently" connexion to the OpenVPN port in order to make squid
blind about the CONNECT protocol..
Received on Tue Sep 13 2011 - 14:26:31 MDT