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
