<[EMAIL PROTECTED]> writes:
> A secure firewall that doesn't let you do what you need to do
>to support your business doesn't do anyone any good.
Well, more precisely, it doesn't let you do what you need to do
to support your business. :) It _may_ be the case that what you
need to do is insane, risky, and unsafe regardless of whether
or not there's a firewall there. In that case, a firewall that
doesn't let you do it is undesirable, but better (in a security
sense) than one that lets you do whatever you want.
>When we were looking into firewalls, one of the things we wanted support
>on was ICA. I see that NAI still hasn't added ICA support, even though
>many people use ICA. Many Application Service Providers (ASPs) are
>going to be using this or a similar product -- and they're going to want
>to use firewalls to protect their servers.
I think, from how you present this issue, that you may not
understand that putting a firewall in front of an insecure
protocol does not make it a secure protocol. I don't know
enough about DCOM security but, considering its source, I
can imagine that it's a cess-pool. Someone please tell me
I'm wrong, because I know lots of otherwise intelligent
people who want to let it in and out of their firewalls.
There's this problem that I like to refer to as "The Incoming
Traffic Problem" -- it's basically the Achilles' heel of
firewalls. Firewalls typically do _not_ perform any security
checks on data they let back and forth; they simple let it
back and forth, once they are told to. Even proxy firewalls
fail very badly in this regard. Stateful inspection/network
layer/whatever marketing buzzword you prefer firewalls are
even worse since all they do is open and close holes based on the
appearance of traffic in one direction or another. For a
user who wants "transparency" and "quick support of new
protocols" that's terrific -- but don't lose sight of the
main issue: simply letting a service back and forth does
not make it _SAFE_.
>Any Gauntlet users care to defend the product? I guess if all you use
>are the supported protocols, then it's a wonder. But if you need
>something different, you've got troubles.
I guess you might call me biassed 'cuz I wrote the bloody thing. :)
But I believe my perspective is as vendor-neutral as is possible
in this industry. I genuinely no longer give a !*!#@&! about
firewalls. :)
One of the design goals of my first few firewalls was to
build a secure gateway. I always believed (and still do)
that a well-designed firewall should always err on the side
of being more secure than not. So, the first firewalls I
built didn't support services that I (and other smart people)
couldn't think of ways to safely gateway into the networks
the firewalls were trying to protect. I remember when the
first Web browsers exploded on the scene, and a few of us
at TIS decided that before we'd attack a proxy, we had to
do a code review of the the browser (there was only one
browser back then!) We found a few absolute howlers -- holes
that would let an attacker delete files and run arbitrary
attacks on the client machine, through the browser. Of course
they got fixed. Meanwhile, the sites that were using more
"flexible" and "user friendly" firewalls were exposed to
attack. With today's mishmosh mix of services that run
through firewalls, it's impossible for anyone to even
_think_ about what kind of security holes are in the application
protocols folks so innocently let into and out of their
perimeters. I have bad news for you: most of those undocumented
proprietary protocols aren't even well-understood by their
authors, never mind the vendors.
The first firewall I built only supported a handful of
services: Telnet, FTP, DNS, and NNTP. Those were the only
ones I knew how to do securely at the time. Those are _STILL_
the only ones I think anyone realistically knows how to
secure; though people and vendors who want your money
will tell you otherwise.
A firewall that lets DCOM through is like a seatbelt
that is designed to let your face reach the dashboard. ;)
mjr.
--
Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
work - http://www.nfr.net
home - http://www.clark.net/pub/mjr
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
