RE: [squid-users] WCCP, Squid, and that darn PIX

I think the one case you missed it what is occuring in this case. Which
would be where the proxy is on an inside interface of the firewall (but not
the same inside as the client who is behind a different inside interface.)
So essentially the firewall sees the same network session (web server ->
client) originate both from the outside interface (real web server to squid)
and from the dmz interface (squid to client) which triggers the antispoofing
rules.

Thanks,

--Tim

===============================================
Timothy M. Wolfe CCSE/NSA/CCNA
Sr. Security Engineer tim@ignw.com
InfoGroup Northwest 541.485.0957 x108
===============================================
 

-----Original Message-----
From: Henrik Nordstrom [mailto:hno@hem.passagen.se]
Sent: Thursday, June 14, 2001 11:25 PM
To: Joe Cooper
Cc: Adam Lang; Squid-Users
Subject: Re: [squid-users] WCCP, Squid, and that darn PIX

Joe Cooper wrote:
>
> Oh, I thought his proxy was on the inside of the firewall...
>
> And I thought he mentioned that the outgoing requests were "spoofed"
> with the client's IP, but now looking back over the post, I see that the
> explanation does put the proxy outside the firewall...

I only commented on the statement that Squid does not do IP spoofing in
transparent proxy mode. It does of the origin server IP. You are however
entirely correct in that Squid does not spoof the client IP.

Exactly what triggers the spoofing detection rule in this case is not
very obvious. WCCP redirection should not unless the firewall has
support for inspecting WCCP GRE packets, and acts on the WCCP GRE
payload and not the WCCP GRE packet themselves.

However, sending WCCP GRE redirected packets from a router on the
outside to a proxy on the inside should not be allowed by the firewall
ruleset unless you first explicitly enable it somehow by opening a big
fat hole in the firewall, and if done the other way around (redirection
on the inside to a proxy on the outside) the firewall should not allow
client return traffic in because there is no TCP session established
yet.. so it is best to run the proxy on the same side of the firewall as
you do the redirection. From a security point of view prefarably on the
inside of the firewall as you may want to have some protection of your
proxy server from external attacks.

The origin server spoofing of a transparent proxy should normally not
trigger spoofing detection either, as this is usually done without
knowledge of the firewall:

- If the proxy is outside the firewall then it is no different than an
asymetric route (different uplink and downlink routes).

- If the proxy is inside then the firewall should not be able to even
smell that there is spoofing going on. But it might if you by some
strange reason route client return traffic via the firewall.

If it is detected when the proxy is outside the firewall it might be the
case that the firewall has a rule verifying MAC level routing in a weak
attempt in broadening the spoofing detection to detect attacks on the
same ethernet segment spoofing as some external service (i.e. verifying
that the source MAC matches the MAC where return packets would be
routed). However, this is a quite weak check as the spoofer may just as
well spoof the MAC, and it also is incompatible with asymetric routing.

--
Henrik Nordstrom
Squid Hacker