Thanks for pointing out that important distinction.
My preferred method would be to run, say, http-gw on the firewall
(small, securable), and run a cache on the inside which can cache both
local and remote server accesses. But I wonder what is the liklihood of
being able to cause mischief via the cache/proxy from a remote server
(vs. client)? I have seen Squid (1.0.9) die on a URL that was too long
(printed a message and seg. faulted). A simple auto-restart script
takes care of the inconvenience, but you wonder about the danger, what
with a growing list of programs reported vulnerable to various buffer
overrun attacks.
I guess the safest would be to use a plug-gw to an external cache
that's not allowed to access the inside. and run a second cache for
the inside only.
- KH
Bob Beck <beck @
obtuse .
com> wrote:
> It doesn't appear to me that you can configure which
>interfaces you want it to listen on. It looks like you can configure
>what ip addresses you want it to listen on. There is a difference. If
>you rely soly on the fact that you've told Squid to listen only on
>your internal address, you are still vulnerable to the usual ip
>spoofing techniques unless you have otherwise protected yourself from
>them. (I.E. you have a packet filter blocking it off, or you're doing
>somthing else beyond Squid.) You'll need something (either on the
>machine or in front of it) to prevent my being able to fire a packet
>with your internal addess on it at your external interface and having your
>machine accept it as it's own.
>
> Sure, most of the time you're going to have such a packet
>filter, or you're running a firewall product that does indeed allow
>you to distingush stuff truly by what interface it comes in on
>irregardless of address. But if you need to do that anyway, the fact
>tat Squid has IP based access lists doesn't really matter, unless you're
>not concerned about holes in Squid.
Follow-Ups:
|
|
