Re: How to Save The World (was: Antivirus vendor conspiracy theories)

[Devdas Bhagat <devdas () dvb homelinux org>]

On 08/12/04 17:47 +0100, Ben Nagy wrote:
> > -----Original Message-----
> > From: firewall-wizards-admin () honor icsalabs com 
> > [mailto:firewall-wizards-admin () honor icsalabs com] On Behalf 
> > Of Devdas Bhagat
> [...]
> > We need to publish a book of rants ;).
>
> In all seriousness, I have often thought it would be cool to have a
> 'best-of' compilation from the archives. It would just be a freaking
> nightmare for someone to read it all and pick 'em, sadly.
 
Well, that sounds like a call for volunteers. Editorial nominations
please? Or maybe the ex and current moderators get nominated as editors
(if they are willing) and we can send the best threads, rants and quotes
of our choice to them for filtering and compiling.

This should give some interesting results, given the level of clue on
this list.

> > > I blame the protocols more than the
> > > proxies, but that's still how I see it.
> >
> > Some protocols are easier to proxy than others.
>
> I'm sure that's what HTTP people were smugly thinking, before SOAP. ;)

In context, is http easy to proxy securely? AFAIK, HTTP is a major
offender because the protocol does not specify limits for a lot of
operations but leaves them implementation and configuration dependent.

SMTP has well defined limits, ESMTP is slightly better. DNS has
limitations as well.

> > > [...]
> > We don't disagree on everything. Only on the best way to slaughter the
> > malicious.
>
> Hmm. Evocative phrasing. Personally I am against capital punishment -
> whipping, indentured servitude and the Dixie Chix should be severe enough.

Personally, whipping, rubbing salt on the wound, and then tossing them
for a short while into a fire ant nest, and repeating in a loop while
charging the guilty a price for getting them out of the ant nest is more
my style. They can always opt out of getting bitten for the small small
price of $bignum ;).

> > > [...]
> > > > Wouldn't it be far easier for the A/V vendors to just ship an
> > > > alternative browser
> > >
> > > No. That would be the commercial equivalent of stuffing hundreds of
> > > marshmellows up their nostrils and hoping to burp cotton candy.
> >
> > Not really. An alternative browser would work as a better solution.
> > Given that most of the exploits are IE specific, using 
> > Firefox, or Opera
> > would be a much nicer solution.
>
> There is a strong possibility that the only reason there are less Firefox
> vulnerabilities is because attackers can't be bothered attacking it. You may
> notice that there have been several nasty bugs since it started becoming
> more popular. 

I have also found the firefox community to be a lot more responsive
about fixing those issues. And about changing the defaults to better
ones (IIRC, the Mozilla XPI bug was fixed by not allowing automatic
installation of modules).

> That hypothesis won't be provable either way for a while yet, although I
> acknowledge that it's an emotive issue. Everyone wants so badly to believe
> that IE is 3vil and Firefox r0cks. Well, I'll agree with the first half and
> reserve judgement on the second until it has been under hostile fire a
> little longer.

I wouldn't say it rocks. It just sucks less. To paraphrase the Mutt
author "All software sucks. Some just sucks less".

> In any case, changing away from IE is simply not going to happen for many
> environments, and Desktop Support aren't liable to consider their AV vendor
> to be the world authority on what browser they should be running.

In an environment where desktop support exists, we can assume the
presence of a semi competent (at least) administrative team who knows
what ACLs to use and where.
In a SOHO/home user environment, the AV vendor is much more likely to be
listened to, and the friendly neighbourhood geek as well.

> [...]
> > > the "firewIDS"[...]
> >
> > I think of it as proxies done wrong. Instead of trying to allow known
> > good traffic through, they are attempting to filter out known bad
> > traffic. That this approach does not work very well is a well known
> > factoid, but this appears to be ignored. Those who do not learn from
> > history are destined to repeat it and all that...
>
> Well, in theory they should actually be "default deny plus", since you set
> 'em up just like a normal firewall, except that for the 'open' ports you
> have another chance to catch attacks by inspecting the data you're allowing.
>
> In theory.

Right.....
 
> [...]
> > Ok, analogy time. A firewall is like a locked door.[...]
>
> I love this quote. ;)
>
> "If you are using a house analogy, you have stopped saying anything 
> interesting about information security." - Dave Aitel, Sep 01 2004.

I was making a warehouse analogy actually, and in this case, the analogy
is valid :).
 
> [...]
> > > IMO all the guys doing "behaviour blocking", "deep 
> > inspection" blah blah
> > > blah are onto a much better bet. Signatures are basically sucky.
> >
> > Oh hell, if you want to speak about deep inspection, why not 
> > think of it like this:
> > Deep inspection looks at the contents of a packet or group of 
> > packets, and tries to match it to known bad patterns. [...]
> > So what it boils down to is that the deep inspection filters are just
> > proxies done badly.
>
> Yes. Deep inspection is application level smarts applied to network streams,
> but really fast. 
>
> "Any sufficiently advanced application proxy is indistinguishable from any
> sufficiently advanced stateful inspection engine." - Carson Gaspar, 15 Apr
> 2000
>
> Quotes for all occasions. :)

So, are there any good stateful inspection engines which can analyse
data streams, and stop attacks? Including the capability to decode
encoded (as opposed to encrypted) traffic on the fly? Can I poke at an
email stream and figure out that this HTMLised base64 encoded mail with
inline attachment is spam/a virus, but this other thing is not? And then
break the communication without having it time out or get interrupted
(which is responded to by resending the mail again)? And what happens
with UTF8 data streams?

> There are two reasons why I like "Deep Inspectotron Application Fireweasels
> (DIAF)" better than true proxies.
>
> 1. You don't have to implement the whole damn thing, which leaves you more
> time to get to grips with filtering out badstuff. This is the key reason
> DIAF != "Proxy But Different"

IMHO, it is better to filter out the good stuff and pass it through.
Defaulting to a state of denial is a good thing.

> 2. You can do it way, way faster with little effort. It's very amenable to
> turning into circuits.
>
> Lots of people probably see 1. above as a negative, not a positive, and I
> used to think that way as well. However, I do not believe that it is
> possible to implement the same kind of strict proxy that we used to be able
> to do with, say, SMTP or FTP. Given that vendors don't/won't/can't do that,
> they make cop-out proxies for the tricky protocols, which basically just
> take attack traffic and add 150ms latency. Like Gauntlet. (I can tease them
> now they're dead ;) Rather than do that, why _not_ pull out known bad stuff
> based on generic "you probably don't want that much data in this header", or
> "I doubt this mail address is meant to contain a 300K uuencoded attack
> payload" type rules.

I think that it is much more about the default stance that is associated
with each product. A proxy firewall implies a default deny stance
(plug-gw excepted). A DIAF tends to make me think of a default allow
stance. If a strict proxy is not available, perhaps those protocols
should not be used on the open internet? There are tunneling
technologies available which can make the use of those protocols
reasonably safe.

> Now I don't use DIAFs, we don't sell 'em, I have no vested interest, I just
> think it's slighter nicer to have a DIAF than a plain ol' boring FW,
> PROVIDED that it doesn't use IDS style signatures. I do not, however, think
> that a DIAF goes any significant way to obviating the need for defence in
> depth and host protection, as some marketeers will try to claim. It's more
> like version upgrading your firewall than implementing a 'new' technology.
Right. And at that point, I will raise the question of what a DIAF is
worth if it takes a significant effort to maintain but gives low
returns.

> [me]
> > > There are other flaws too, but I risk setting myself off on a rant.
>
> Oops, I slipped.
>
> > Oh come on, rants are fun.
> > use rant;
>
> You talked me into it.
>
> [...]
> > > > As MJR argued trying to fix a broken
> > > > system is a waste of time and not worth the effort.
> > >
> > > Well, as _I_ said in that thread, it is possible to do a 
> > pretty damn good
> > > job of bolt-on protection for both Windows and Linux (the 
> > systems that need
> > > it the most), without designing it into the kernel in the 
> > first place.
> >
> > You mean, on a filesystem like FAT32?
>
> Ouch. Ok, you got me. FAT32 is bad, m'kay?
>
> But, to be fair, I was thinking about 'real' operating systems.
>
> [...]
> > > "Dumb" systems like stackguard, linux / windows kernel 
> > modules that do some
> > > simple function hooking, detecting system calls made from 
> > writeable memory
> > > and the like are NOT rocket science.
> >
> > Kernel modules are in kernel space, by definition.
>
> Yeah, but they're not designed in. They can be easily implemented as a
> band-aid, which is my whole point.
>
> > Microsoft Windows has really bad defaults.
>
> Pet Peeve. Yes, OK, but they're getting better. I don't wail on Linux for
> how crappy its security was back in 1999-2000 (well not much). XPSP2 is
> actually moderately cool, from memory management up. Win2K3 likewise.
Unhappily, with reality being as it is, Windows is the dominant OS and
has been for a long time. Linux distribution security has improved as it 
has started getting popular. Windows security is improving as Linux is
threating to make a dent in its market.

In 1999-2001, Linux was still mostly technical geek oriented and those
people were usually willing to put in some effort to make the OS secure.
Also, custom installs let the user choose not to install packages, and
packages which were not installed could not be exploited.

With MS stuff, OTOH, a secure host needs far more effort than a secure
Linux/Unix host. I see absolutely no reason for a mail client to default
to parsing HTML or being able to actually run code in the HTML.
The MS trust model is broken in that it relies on CAs signing ActiveX
controls because it assumes that the CA will not sign malicious code.

Oh well, we get the security that the cheapest of us pays for.

> > All that is being 
> > asked of them 
> > is that they set better defaults, and not require users to run as 
> > administrators all the time. Oh, and do not start up all 
> > those services 
> > at boot time.
>
> Users have been able to not run as administrators since 'runas'. Kinda.
>
> OK, I'm probably lying, I admit. *sigh*
>
> > Of course, hitting users over the head with iron bars is 
> > likely to work better in the long run.
>
> [southern twang] "Ahhh lews mo' yewwwwsers that way!"
>
> > > Hell, the Windows ICF, 
> > "High Security"
> > > browser setting and a copy of Spybot is adequate for home 
> > users. It's just
> >
> > "High security browser setting" results in sites throwing up 
> > warnings or
> > simply not working. This is just not going to work in /that/ market.
>
> Meh, OK, XPSP2 then. ;)

And there are $BIGNUM users in the home segment still using Windows 9x,
or ME.
 
Devdas Bhagat
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards