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..