Search squid archive

Re: Conflicts with squid in transparent to Apache proxy and OpenVPN

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 







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





[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux