On 27/07/2012 7:28 a.m., Abhishek Chanda wrote:
> Hi Amos,
>
> I do not have a "intercept" with http_port. Here is my config:
>
> maximum_object_size 10240 KB
> http_port 80 accel defaultsite=cona-server vhost
> cache_peer 192.168.122.11 parent 80 0 no-query originserver name=myAccel
> acl our_sites dstdomain cona-server
> http_access allow our_sites
> cache_peer_access myAccel allow our_sites
> cache_peer_access myAccel deny all
> acl manager proto cache_object
> acl localhost src 127.0.0.1/32 ::1
> acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
> acl SSL_ports port 443
> acl Safe_ports port 80 # http
> acl Safe_ports port 21 # ftp
> acl Safe_ports port 443 # https
> acl Safe_ports port 70 # gopher
> acl Safe_ports port 210 # wais
> acl Safe_ports port 1025-65535 # unregistered ports
> acl Safe_ports port 280 # http-mgmt
> acl Safe_ports port 488 # gss-http
> acl Safe_ports port 591 # filemaker
> acl Safe_ports port 777 # multiling http
> acl CONNECT method CONNECT
> http_access allow manager localhost
> http_access deny manager
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> http_access allow localhost
> http_access deny all
> http_port 3128
> coredump_dir /var/spool/squid3
> refresh_pattern ^ftp: 1440 20% 10080
> refresh_pattern ^gopher: 1440 0% 1440
> refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
> refresh_pattern (Release|Packages(.gz)*)$ 0 20% 2880
> refresh_pattern .
>
> I am still not sure why Squid needs the original source.
CVE-2009-0801, accurate security controls based on destination, logging,
etc.
> Here is what
> I understand: given a topology like this, (Squid is in transparent
> mode)
Ah. NO.
Your Squid is in reverse-proxy mode (port with "accel" option) and also
in forward-proxy mode (port with no options)
Your firewall is performing DNAT on the packets, but there is no
transparent mode handling enabled in Squid.
> Client ------- Squid --------- Server
> there will be an iptable rule at Client to do a DNAT and change
> destination address to that of Squid. When Squid receives the packets,
> it can do its lookups and send the packets back to Client (it can get
> Client's address from the packets).
Here you hit what is called triangular routing:
client A contacts server B but packets gets NAT'd from (A->B) to
proxy (A->C). The response from proxy is a packet C->A
client A was talking to B, so its firewalls and systems are prepared
to accept responses from B->A. But what actually arrives is C->A which
are not valid and gets dropped.
The connection hangs.
You need to ensure your NAT operation is symmetrical. Packets C->A get
converted back to B->A on the response flow. This is what the mandatory
MASQUERADE or SNAT rules do in iptables examples.
When you fix this I think you will see a lot of invalid-request
responses from Squid to the client ... because port-80 origin server
traffic has an entirely different syntax than port-3128 proxy traffic.
> If a lookup fails, it will get the
> server's address from config and get content from the server. So, I
> expected, if I have a OpenFlow flow to re-write IP addresses (and not
> use iptable rule) it will work in the same way. The controller cannot
> change NAT table at the Squid box.
Correct. When performed outside the Squid box you effectively have two
networks connected by a NAT relay. The only thing that matters there is
that the triangular routing does not occur.
>
> When the client tries to contact the server, the traffic is
> re-directed to Squid using a flow. At this point nothing happens at
> the client. Once the flow times out and is deleted, the client gets
> the content from the server. I am not sure why would Squid relay the
> request to itself and loop (though, that seems to be the case here!).
> Can you please explain?
With the above config there is no transparent, so Squid will not be
connecting directly to itself unless its own IP/hostname is in the
packet headers (CVE-2009-0801).
But, the same behaviour appears when Squid contacts a server and some
external machine (OpenFlow controller) DNATs those requests back to
Squid. You must have some form of bypass/skip configured on the DNAT to
prevent that from happening.
Amos
Received on Fri Jul 27 2012 - 05:10:34 MDT
This archive was generated by hypermail 2.2.0 : Fri Jul 27 2012 - 12:00:02 MDT