Marcus,
Using firewalls does provide value, even when you need to do something
like opening up DCOM. Here are a few issues for your consideration:
1. Using a firewall, you add a layer of security, even if it's not
perfect. For example, you can specify what addresses are allowed to use
the protocol, and also the direction of communication (I believe the
original poster wanted to be able to use DCOM outgoing, not incoming).
While this isn't perfect, I hope you'll agree that it's far better than
having no firewall at all.
2. You are not limited to using a single firewall, nor are you limited
to having only two interfaces in a firewall. If you need to open holes
for protocols you are really uncertain about, there's no reason you need
to open that hole for *everyone* on your corporate network. For
example, if your company has an ASP service, you can create a separate
network for that with its own firewall; the main corporate firewall can
treat the other network just as if it was out on the Internet.
3. A firewall is not the ultimate answer to security. It only needs to
be good enough that it's more difficult than other avenues of attack.
You are generally far more vulnerable to employee sabotage, human
engineering, and physical intrusion than you are problems in your
firewall.
4. People have different security needs. If you're a bank, you're going
to have different security needs than if you are a consultant who needs
to test various protocols on non-critical test servers. Intruders will
have different motives for attacking you. If there is little to be
gained from attacking you, then it's reasonable to say that you
shouldn't be building a fortress when all you need is a bicycle lock.
Jen
"Marcus J. Ranum" wrote:
>
> <[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.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
