Re: [squid-users] mIRC

Robert Collins wrote:

>
>> -----Original Message----- From: Joe Cooper

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

This was the crux of my statement: "many folks mistakenly believe that
sending everything through a 'proxy' (no matter what kind of proxy)".
In this case, we've got no added security. It comes up a lot on this
list, as you know, folks who want to send everything through their Squid
("why can't I get my pop mail through Squid", etc.) because it is more
'secure'. It just isn't.

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

Ok, I'll concede that proper application level proxying for /every/
protocol in use alongside a firewall is better than a firewall alone.

Our opinions on this are all that different--My argument is primarily
that it is silly to assume that a 'proxy' has magical properties that
makes all connections more secure. Squid gets tasked with performing
quite a ludicrous amount of magic, because it is the most popular 'proxy'.

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

Yep. ;-)

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

Good. I figured you were well versed (you know more than I about a lot
of things, why should this be different? ;-) but just wanted to make
sure everyone was on the same page.

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

True. It can force a back-off, however, under some
circumstances--relieving the problem somewhat.

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

Hmmm...I think I'm missing what you're getting at here. What can be
done, in a proxy or otherwise, about an encrypted data stream?

Ordinary app level data streams /are/ subject to Snort and Hogwash.

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

You mean you've already finished content filtering in Squid? Gee, that
was quick. Nice job. ;-)

Seriously, though, you're right...Squid could, at some future time
provide protection even from this sort of issue. If it can process data
inline, it would be easy enough to create a database of known viral
ActiveX/Javascript/etc. signatures to watch for.

>> I'll take a well configured stateful firewall any day for securing
>> anything else, though.
>>
>
> And I'll take both - firewall + application specific proxy.

I won't argue with that. it's too much work for me and my laziness,
though...maybe I'll change my tune when we're on a fixed net block next
month with a couple of publically accessible servers in-house. I guess
I'm spoiled by having a firewall on all of our boxes in addition to the
gateway box (we're all Linux boxes and one FreeBSD box here, only an
intermittently connected laptop runs Win2k--and she gets MASQed and
strictly firewalled).

Anyway, we've got a lot of preaching to the choir (and the choir
preaching back) going on here. And tomorrow we'll see a new post about
proxying 'protocol X' through Squid...and so it goes.

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