As you requested in your opening statement....your forgiven!
-----Original Message-----
From: Marcus J. Ranum [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 26, 1999 2:26 PM
To: Jen
Cc: [EMAIL PROTECTED]
Subject: Re: DCOM on Gauntlet
>Using firewalls does provide value, even when you need to do something
>like opening up DCOM. Here are a few issues for your consideration:
I guess it depends on the firewall. I'm kinda rusty on the topic
of firewalls so forgive me if I'm saying something dumb. ;)
>1. Using a firewall, you add a layer of security, even if it's not
>perfect.
This is, what, proof by vigorous assertion?? If the firewall
lets an insecure protocol back and forth without altering it
or applying any security-related processing to it, can you explain
how that constitutes a "layer of security"?
>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.
It's definitely better. But how much? The question is whether
it's better enough to make the firewall worthwhile. If all it's
doing is address based filtering, then you may as well just use
a router (which also won't do any security-related processing).
If you have a firewall that "understands" outgoing versus incoming
for a protocol like DCOM, I suppose that's also a marginal
improvement. But the "incoming/outgoing" filtering in most
"stateful" firewalls amounts to little more than simple window
control on filtering. Those are not exactly compelling security
properties!
That's my concern: people insist on running broken/lame protocols
through their firewalls, and they convince themselves that the
firewall is doing something for them. In fact, the firewall is
doing next to nothing. Nothing a router can't do, anyhow.
>2. You are not limited to using a single firewall, nor are you limited
>to having only two interfaces in a firewall.
If one layer of toilet paper protecting your network is not
sufficient, are two?
>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.
Sure. That's a reasonable approach; I've been known to recommend
things like it in the past. Identify protocols you don't fully
trust and let them in only to systems that are not connected
to trusted networks. Which begs the question, "if you don't trust
the protocol, why are you using it for something important?"
I'm not just messin' with you here -- these are fundamental
problems with the concept of firewall, and they are problems I've
been wrestling for, oh, a while. In fact, I've finally concluded
as a result of these issues that firewalls are no longer useful
technologies. There are too many "business critical" applications
being deployed through firewalls which the firewalls cannot usefully
operate on (indeed, the vast majority of firewalls on the market
do _no_ security processing _at_ _all_ other than adaptively
creating and destroying what amount to router filters).
>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.
I don't think a firewall is an answer to _any_ question, anymore.
I used to think they were useful because they encoded a programmable
form of security knowledge, so that unsophisticated administrators
could implement basic security without having to research the
network behaviours of various application protocols. Well, that
was true. So what happened is that everyone felt safe, stopped
thinking and questioning, and simply began pointing and clicking
and picking which services they wanted to allow in and out of
their networks. Bad move. I believe that the vast majority
of firewalls let more traffic through than makes any kind of
sense. But there is no present viable alternative. Oops. :(
>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.
Yup.
What you're talking about there is risk assesment. It's a very
important process! You need to make estimates on the Important
Four Security Questions:
1) What am I trying to protect?
2) How hard will someone try to get at it?
3) How much will it hurt me if they succeed?
4) How much effort/cash am I willing to spend to protect it?
Everyone's networks are different. I believe that a lot of the
networks out there that are presently connected to the internet
shouldn't be. Look at the kind of criminal negligence and
incompetence that has been revealed at Los Alamos' network.
What happens is that many organizations start from their requirements
first and then back into their security policies based on that.
Unfortunately, that's backwards. In order to avoid massive
cognitive dissonance when taking that approach, people have to
convince themselves that their firewalls are actually _good_
and actually _do_ something that makes it "ok" to run these
massively insecure protocols into and out of the network.
As Ryan pointed out, even the 4 protocols I "think" I know how
to do somewhat safely are riddled with problems. Web wasn't
even on that list. Nor pointcast, real audio, ICQ, ICQ's cool-o
instant home page server thingamajig, oil change, and the
zillion new applications coming out that will tunnel over
HTTP. :( So far we've been spared a virus/trojan horse that
knows how to tunnel out through firewalls via HTTP. How many
sites will not be vulnerable to such an attack? How many sites
restrict outgoing HTTP at their firewalls? We need a couple
more layers of toilet paper around our networks, people...
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.]
