Hi Jeff,
At 14:52 01/09/00 -0500, [EMAIL PROTECTED] wrote:
> Ahhh, but it doesn't necessarily have to be another firewall.
>[snip]
you're right concerning the "money" cost, but there are other costs.
The first is administrative cost, but your solution is ok here, since
you are chosing one of the lines based on your knowledge and your taste,
and people do not feel tired to work on products they "chosed" without
executive pressure. so let's ignore this one.
the second is the performance cost. one is always faced with the
"robustness-performance"
trade-off. To maximize security, you'll somewhat reduce the perfs. hence,
there is
some tuning to do: where is the limit? if I put 2 gateways, and eah one is
doing extensive
search, then performance is less than if one of the boxes is doing light
filtering, and the second
is doing the rest. but in the latter, this is not 2 lines defense, this is
just of form making the
two boxes collaborative (what is said about 2 boxes can be said about 2
filters or proxies).
so there is something in the middle of these situations that should be a
good choice, but where
exactly.
In other words, if the filters collaborate in such a way that at least one
given control task is
only performed by one of them, then for this task, there is only one line
of defense. but
this may be acceptable for some defined tasks, depending on the policy. we
thus end with
the need to design the choice of "number of lines" in the policy, depending
on some criteria.
> You should have to penetrate the first line of defense before you can
>penetrate the second line of defense.
>[snip]
I haven't been clear. let's assume you configure your firewall to allow
incoming telnet
if the user is "foo" and the destination is "bar.domain". then, someone can
connect to this
host without penetrating the firewall. It's a consequece of the
configuration and is fully legitimate.
suppose that this is done because the guy knows that "bar.doain" is a
hardened box, and will
not allow any user to do anything except a list of authorized tasks. so the
setup is secure according
to the site policy. but suppose now that "bar.domain" is not as hardened as
it is thought, then
the setup is no more secure. My point is that this is independent of the
firewall.
In other words, it is not necessary to penetrate the external FW, because
the connection is
permitted by the policy. You might say but this is bad configuration, but
here I say no, not
necessarily. here is an example using 2 FWs:
- an external solid rock FW, a supposedly perfect fw.
- an internal FW, which has the following bug:
if a user connects to the web, and downloads the url: /get/me/now, it
connects to some internal server,
and does bad things on (the kind of things that the external FW would have
blocked if they were done
from the outside).
then, the external FW ca do nothing about this, as the only thing he sees
is normal http traffic.
one could say, but it suffies to block access to the malicious url, but
this is only valid if you know it,
which just means you know the bug in the internal FW. but this is thekind
of info you know too late.
so, if we analyze this situation, we see that a setup using only he
external FW is secure, and adding
the internal one introduces a vulnerability. That's why I insisted on the
fact that eventhough defense in
dept is a good thing, it is not easy to implement in practice (well, it is
easy, but doubt stays around).
regards,
mouss
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
