Re: [squid-users] mIRC

Robert Collins wrote:

>
>>-----Original Message-----
>>From: Joe Cooper [mailto:joe@swelltech.com]
>>
>
>>As you
>>may know, though, many folks mistakenly believe that sending
>>everything
>>through a 'proxy' (no matter what kind of proxy) is somehow
>>inherently
>>more secure than a correctly firewalled and segmented
>>network...
>>
>
> Given the quality of apps that I see on a day to day basis, and a definition of firewall that limits the changes to layer3, maybe 4, then I'm willing to argue this one anytime.
>
> The security point of a proxy is that it can
> A) Remove/prevent known compromises of applications
> B) Enforce the rules of the protocol
>
> Both of which can greatly aid security. For example: squid can filter nimda attacks before they get near IIS servers (in acceleration mode).

Oops... Left out the bit about "except for HTTP protocols for which
Squid provides the possibility of vastly improved security, particularly
when sitting in front of webservers with security holes big enough to
navigate a naval fleet through".

When allowing CONNECT to a wide range of ports, you open up the proxy to
other types of security problems, potentially worse than a single client
security hole...I contend that it is six of one and half a dozen of the
other--particularly on a client network (rather than a network of
servers, where insulating the known insecure software with historically
pretty secure software is often a good idea). To bring it back to the
mIRC issue--what security benefit is there to proxying IRC in this
context, as opposed to firewalling with a well implemented stateful
packet filter? I'm not sure how familiar you are with modern packet
filters--forgive me if I'm stating the obvious...But it is entirely
possible to limit most types of floods at the firewall and react to them
dynamically, which Squid can't do because that isn't what it is meant to
do. It is also possible to force the inside client to open the
connection to the outside host before allowing the outside host to even
speak to the inside, which is part of the only benefit of Squid I am
aware of in this context. With advanced tools like snort/hogwash/etc.
it is possible to prevent attacks that even Squid can't deal with via a
signature database and more in-depth packet analysis, again because
Squid isn't designed to 'secure' a network, though that is a side effect
in many circumstances.

So, to clarify my statement...Squid is great for securing HTTP servers.
  It is perfect for the task. It is probably also good for securing
client HTTP networks (though most client-side security problems are in
the content and so Squid is no hindrence to the payload reaching its
destination). I'll take a well configured stateful firewall any day for
securing anything else, though.

-- 
Joe Cooper <joe@swelltech.com>
http://www.swelltech.com
Web Caching Appliances and Support