RE: [squid-users] mIRC

> -----Original Message-----
> From: Joe Cooper [mailto:joe@swelltech.com]

> 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...

Very true. I don't consider pushing tcp sessions sideways thru a CONNECT tunnel 'proxying' them. I wasn't meaning to support the goal of 'proxy'ing mIRC via squid, but rather the argument that proxies do not significantly enhance the security of a network.

> 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).

IMO you need *both* a proxy per prtotocol and a stateful firewall to be able to say with any confidence that a segment of your network is temporarily secure.

> 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?

Much. Install an IRC server (aka IRC proxy :}) on a bastion host, and point ALL the local mIRC clients at that. Have it stateful firewalled, allowing only the appropriate reflexive rules that IRC DDE requires, and have the server set with paranoid settings, also set to only allow client connections from with the network. Then limit the verbs the server will relay in either direction, audit the server code (mIRC code is not available) or see if someone has audited the code to ensure that buffer overflows etc will not get passed onto the client, and set IRC flood protection etc at that point as well.

Pushing mIRC through squid however, has zip protection over a stateful firewall.

> I'm not sure how familiar you are with modern packet
> filters
I hope I'm familiar with such beasts, as I am responsible for IT Domain's network security.
> --forgive me
Done.
> 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,

Absolutely. However the stateful firewall cannot react to a flood within a mIRC session, as it doesn't (by definition) understand the application protocol.

> 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,

Except with application level encryption, which proxies oftimes insert MITM behaviour into (by design).

> 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).

*cough* content filtering :}.

> I'll take a well configured stateful firewall
> any day for
> securing anything else, though.

And I'll take both - firewall + application specific proxy.

Rob
Received on Wed Feb 27 2002 - 06:29:02 MST