Yes, using a multiple port router as Screening Router #1 and homing each
bastion hosts on a different port would provide the same effect. However,
this would significantly (perhaps exponetially) increase the complexity of
the filtering table for that router. Also, in many cases, the additional
ports come with a hefty price tag, especially compared to *used* bridges.
Another advantage for individual bridges is to reduce single point failures
(e.g. failed hardware or hung software). It is not uncommon for a router
or hub device (e.g. 10BaseT) to suffer from a software failure, but I've
never experienced such a failure with a bridge. Replacing a failed bridge
is generally easier than replacing a router port card (and has less impact
on the other bastion hosts). Keeping a spare used bridge on hand would be
cheaper than a spare router port card (especially considering the costs of
h/w and s/w maintenance.
Bob
- - - - - - - - - - - O R I G I N A L M E S S A G E - - - - - - - - - - -
On Wed, 31 Aug 94 16:01:13 EST, sirrianj @
cc .
ims .
disa .
mil wrote:
Could homing the bastion hosts on a separate interface port
on Screening Router #1 provide the isolation that you are
looking for without having to using the bridges or router
#3?
______________________________ Reply Separator _________________________________
Subject: Re: Proposed Firewall Configuration
Author: RAS @
cacdvax .
cacd .
rockwell .
com at smtp
Date: 8/31/94 2:33 PM
>> Also, a firewall expert suggested the configuration below, which evolved
>> to the configuration presented above. A vendor has also seconded the
>> configuration below. Personnally I don't see the advantage of this second
>> configuration over the one presented above, but perhaps someone out there
>> does and can explain it to me.
>
>> The purpose of Screening Router #3 is the same as that of the bridges in the
>> previous illustration - limit sniffer software installed on a compromised
>> Bastion Host from seeing any traffic besides what is directed to the
>> compromised Bastion Host.
>>
>I *think* the idea is that a router is more flexible and some may say
>more "powerful" than a bridge, what with access lists, routing tables etc.,
>as opposed to a bridge which simply allows or disallows traffic. Hence you
>have more control over what traffic crosses/does not cross that third
>security point before your bastion hosts.
It is true that a router will provide more control of what reaches the
bastion hosts, but is that extra control necessary? The thought was that
router #1 (connected to outside) and router #2 (connected to inside) provide
all the control necessary to create a perimeter network. However, if the
assumption is made that one or more bastion hosts will be compromised at
some point in time, then we were concerned about the traffic that could
could be sniffed on the perimeter network.
We thought that connecting each bastion host to the perimeter network via
a bridge would limit the traffic that could be sniffed to just the traffic
exchanged by the bastion host. For example, if an intruder captured the
anonymous ftp bastion host and installed a sniffer, the intruder would not
be able to capture any SMTP traffic (which is handled by a different bastion
host). We believe the bridges to be sufficient for this purpose and do not
understand how adding an additional router on the perimeter network would
achieve the same affect.
>Wed Aug 31 06:13:16 EDT 1994
>===========================================================================
>Larry Chin {larry @
cchtor .
ca .
cch .
com} System/Network Administrator
>CCH Canadian Ltd. (416) 441-4001 ext. 349
>===========================================================================
>
>Everything you've learned in school as "obvious" becomes less and less
>obvious as you begin to study the universe. For example, there are no
>solids in the universe. There's not even a suggestion of a solid.
>There are no absolute continuums. There are no surfaces. There are no
>straight lines.
> -- R. Buckminster Fuller
Bob Schneider
Enterprise Core Network Team ras @
cacd1 .
cacd .
rockwell .
com
Design Support Engineering ras @
131 .
198 .
128 .
108
Rockwell International ras%27746 .
decnet @
consort .
rockwell .
com
400 Collins Road NE M/S 106-103
Cedar Rapids, IA 52498
Voice: 319/395-3863 Comments expressed are strictly my own and are not to
FAX: 319/395-5999 be construed as statements endorsed by my employer.
|
|
