Re: dual-use http_port

On 25.10.2012 13:00, Alex Rousskov wrote:
> Hello,
>
> I am facing a deployment case where a single http_port address is
> used for both direct and intercepted traffic.

Do you have details on why it has to stay that way?

Note that port for intercepted traffic ONLY exists between the Squid
process and the box firewall process. It can be on any IP:port of the
box, up to and including 127.255.255.254:65535 and SHOULD be covered by
a firewall rule to prevent external connections opening to it.

> It appears to work in
> Squid v3.0, possibly using some small custom hacks (I do not know the
> details). The deployment scenario requires such dual use to continue,
> unfortunately.

"appears" is the operative word there. 3.1 and older Squid did not
display much in the way of warnings or errors when NAT lookups went
wrong, and relied blindly (and solely) on the Host: header being correct
to generate outbound connections.
  Neither of which is true any longer.

Certain end-user network security scanners (Trend was the one I saw)
contain penetration tests which will detect 3.1 and older in this
configuration. One variation of the test request used will DoS a
production squid-3.0 proxy with ~100 bytes of input.

>
> I believe I have heard that such "dual use" ports are a bad idea and
> will not be officially supported. I cannot find specific references
> to
> that though, so perhaps I misunderstood. Can somebody confirm?

Yes. I "deprecated" those in 3.2 . Mainly by telling people not to do
it. If they want to do it and face the consequences then go right ahead.

It does "kind of" work with DNAT received traffic, so long as the NAT
is performed on the local box. At least - we can locate the NAT'ed IPs
when they exist and detect syscall failure when they don't.
*** but was that failure because:
  the traffic was DIRECT input (Okay),
  NAT was overloaded (Vulnerability: SYN flood on NAT table results in
attacker IP-hiding and gaining open-proxy access via "allow localhost"
or "allow localnet" when Squid box primary IP matches localnet or
localhost) (Vulnerability: DoS on proxy via forwarding loops in very
common "via off" config),
  or NAT was on a different box? (Vulnerability: clients bypass browser
security protection. CVE-2009-0801).

However that "working" is just one case out of several NAT
configurations. The rest of which visibly fail in a variety of strange
OS-dependent ways;

  * DNAT on a remote box screws up with identifying the traffic as
forward-proxy traffic when depending on the NAT lookup [the old 3.0-3.1
problem resurfaces] (Vulnerability: Host header spoofing bypasses
network firewall policy via "allow localnet" when NAT box IP matches
localnet)

  * Linux "REDIRECT" NAT screws up the local inbound IP address silently
such that is *appears* to work. But is either one of the local boxes IPs
or has a different port to the real TCP traffic.
  (Vulnerablility: logs contains Squid boxes IP address, not the client
or any attacker details)

  * TPROXY intercept the source and destination IPs are received
inverted with no OS lookup available to identify whether the traffic is
TPROXY'ed or not. So that we cannot be sure what IP is src and what is
dst when mixed traffic is received.

Also;

  * The Host: header validation is enabled/disabled based on the port
mode flags. Performing it on non-intercepted traffic creates an enormous
amount of false positives simply because the TCP destination IP address
is the proxy and not the Host: domain.

  * ORIGINAL_DST outbound traffic is enabled instead of DIRECT on
outbound intercepted traffic, again based on the traffic/port mode type.
Non-intercepted traffic using that output connection type will result in
forwarding loops and/or client visible error pages.

So; convenience for a few admin not having to add one firewall rule or
configure one squid.conf line, versus 5 security vulnerabilities and a
lot of pain to everyone using the proxy (clients AND admin alike). The
choice was easy.

There is no such laundry list of problems with forward/reverse-proxy
modes and reverse-proxy port can still receive forward-proxy traffic,
although for simplicity my byline is different port for each mode and
leaving that exception unstated.
  The default "never_direct allow all" implicit in reverse-proxy traffic
handling still causes major problems to forward proxy traffic unless one
configures around it and opens DIRECT to all traffic on the port
regardless of mode. Slightly dangerous but up to the admin still.

>
> While I personally very much prefer clean setups where each port is
> doing its own thing, is dual use really such a terrible thing that it
> must be banned even in environments where it can be made to work and
> is
> required by forces outside our control?

If it can be made to work then it can be made to work. We do not have
any code specifically banning it. The natural consequences (system call
failures, packet loops, hanging connections) appear to be sufficiently
problematic to make it clear that "made to work" is the extreme minority
of situations.

>
> I am speculating that we could officially support it (where possible)
> in
> a reasonably clean way using the following configuration sketch:
>
> http_port ip:port direct ... options for direct port ...
> http_port ip:port intercept ... options for intercept port ...
>
> plus some piece of smart code that determines whether it is dealing
> with
> direct or intercepted connection and switches to the right http_port
> option ASAP. Note that the "ip:port" parameters are the same for both
> http_port lines, indicating admin intent to enable dual use.
>
> This way, there is a clear separation of options and internal state
> except for the "short moment" when some "smart code" determines which
> port it must use. That code might assume/use direct port by default
> (or
> even have a dedicated "http_port ip:port dual" line with the same
> ip:port address, if really needed!).
>
> If we are worried about folks accidentally configuring dual ports
> where
> none are really required, then the support for this messy setup can
> require a special "shared" http_port option or even a ./configure
> parameter.
>
> What do you think?

How does one identify which SYN packets from the network were for
"http_port ip:port direct" and which were for "http_port ip:port
intercept" (NAT on gateway router) ?

How do we auto-detect boxes which have been installed where NAT is
performed remotely by some gateway?

Amos
Received on Thu Oct 25 2012 - 01:14:32 MDT