* Subject: Multi-Protocol Firewalls
* From: "Scott R. Corzine" <src @
rigel .
nemc .
org>
*
* We have several projects being planned as separate WANs
* interconnecting lots (>20 near-term) of different insitutions and
* practices (with hundreds of sites planned long-term). These are
* being independently developed and are calling for a bunch of
* different protocol suites, OS's, and WAN technologies connecting
* through our planned (strong) firewall perimeter and into our core
* network. All of this data is for health care and pretty
* confidential.
For starters, you have my sincere sympathy. Particularly on the part
about each of these projects being independently developed.
Here's my $0.02 :
The number one problem I personally face, in a not-exactly-but-pretty
similar situation, is getting a good description of just what kind of
functionality the given project requires from its link. I don't think
you can begin to do security management until the requirements are
defined, and I think you (or your capable staffmembers) want to be
involved at the very earliest planning stages of the project. You can
explore alternatives, do reality-checking, and get a head start on
equipment requisitions this way. There's nothing more dangerous to
your network than a net-clueless project manager with a desire to win
a potential client.
Not only that, but by being informed of the requirements in advance you
avoid being paged at 4:00 AM because the PM arranged a major demo of the
app your company is building for a client in Europe -- and everybody's
screaming because Europe can't reach your development application server
via Internet :). (Please pardon the US-centricity of the example.)
Next, I think a great deal depends on how those WAN links are coming
in to your site. If you've got several data lines running in to
your site, and your LAN is well segmented, then multi-protocol routers
can be easily configured to create vnets that are limited to a particular
segment. Protocol-specific access lists then put a barrier to packet
penetration into the outside-facing interface.
I'm not above being Draconian, either: two of six WAN links coming into
my employer's site terminate at stand-alone machines with no local LAN
access. Two other links terminate into stub networks that're also not
physically connected to the local LAN. My personal experience is that
the folks running projects couldn't care less how it's wired as long as
the requirements are being met. So, my security problem is essentially
reduced to two lines.
Multi-protocol b-hosts:
Perhaps I'm just cranked at Solaris 2, but I am more or less resigned
to having to beat Windows NT/AS into a multi-protocol bastion host OS.
Unix vendors just aren't moving fast or reliably enough, IMHO. The
design problems faced in using WinNT/AS this way are far from resolved,
but I really don't see a better alternative on the horizon.
This, of course, is a personal opinion: flames/comments to e-mail, please.
* We will be running IP through the firewall, Banyan Vines is planned,
* SNA and Novell and NetBIOS have been requested, and I wouldn't be
* surprised if someone wants AppleTalk and whatever Microsoft is
* backing for Windows for Workgroups (and NT). Since we can't route
* everything we'll be bridging too. Also Vines, Novell, and AppleTalk
* do/can have both IP and SNA traffic tunnelled through them.
My suggestion here would be to make at least one good multi-protocol router
an important part of your firewall -- in *addition* to whatever you're
currently using to secure your Internet link. It will probably be a pain
in the rear to configure this router to do what you want; may as well
focus your administrative discomfort on one device.
* Questions:
Most addressed above...
* -Can bridged traffic meaningfully be secured through a firewall?
I personally don't see how, but I welcome enlightenment ;).
* -Are these proprietary protocols secure and/or well documented?
They do not seem to be documented in the same sense that SNA or IP is.
* -How do I refute vendor claims that their proprietary protocols are
* so secure they don't need a firewall (or are they right)?
I captured, diddled, and played back the essentials from a Vines session
for a client who'd heard that from Banyan representatives; I was able
to successfully gain server access without any significant trouble at all.
I haven't completely figured out the Vines protocol, but what made it
easy was that the spoof was conducted from a "Vines serverless" segment.
There may be other, greater, weaknesses in Vines that are inherent to
the protocol. I wish I knew.
Novell reps can usually be silenced by a reference to HACK.EXE... There's
probably an IPX/SAP whiz lurking here that can speak to this one.
AppleTalk seems about as secure as Vines, from what very little I've
seen of it.
* -What are the risks of doing all of this when some of the protocols
* aren't completely understood by the staff who has to run this?
To paraphrase Marcus Ranum, the way to trouble is marked by using tools
that you don't understand very well.
* -Does it make sense to spend a lot of effort building a solid
* IP-only firewall if there are these other backdoor protocols?
I think so. How much of your traffic, and from what source, is IP-based?
If the answer is "most of it, from Internet" then attacks are more likely
going to reach you via IP.
* -Scott R. Corzine-
* New England Medical Center
* <scott @
nemc .
org>
Richard
|
|
