> On Thu, 4 May 1995 09:28:07 -0400 (EDT) Marcus J. Ranum wrote:
> > From: Marcus J. Ranum <mjr @
> > Date: Thu, 4 May 1995 09:28:07 -0400 (EDT)
> > Subject: Re: Pentagon security professionals
> > To: "Dr. Frederick B. Cohen" <fc @
> > Cc: firewalls @
> > Dr. Frederick B. Cohen writes:
> > > Please feel free to flame away.
> > No, please don't flame away.
> > The list has enough problems with poor signal to noise ratio
> > without someone *encouraging* flaming. I've noticed a tendency for
> > some discussions on the list to continue interminably, in which one
> > or both parties refuse to forgo getting in the last word. In those
> > cases I am trying (and encourage others to do likewise) to cease
> > engaging in a discussion after a reasonable number of mails back
> > and forth.
> > mjr.
> Yes, please, I have been reading this group for 3 years, and I am serously thinking
> of dropping out, signal/noise ratio is way to high. If I get busy for a week, when I
> return, I may have do dump several hundred messages to get up-to-date...
> -- tore
I really have no intentions of "flaming", but I would like to add a discussion.
I just began working on a project to firewall our present network. I have
taken an assignement of detail to work in an area I find interesting as well
as a technical challenge. I have been working in the UNIX OS environemnt for
over 10 years, and networking as well (ungermann-bass, xns, tcp/ip, etc) during
all of this time, we (older bsd 4.2 admins) treated unix as extension's of the
os in the fact that tcp/ip is the mechanism of extending the os to other heter-
geneous host(s) for compatibility among other OS'. Enough of my background,
and on to my topic.
I posted a question on using BSDI with the tis-fwtk as a firewall, which I
find works very well. A few things I am uncomfortable with I am posting here.
One of the first is using proxies for all incoming traffic is a little
cumbersome, but I can not really think of any better way without a huge
access-control-list which I feel would hamper performance because of the
nature of the parsing.
As a NOTE: I think that if the acl is so large that maybe the dbm libraries
could help, but that's not what I am after, maybe later.
What I am after is some feelings or ideas on several issues we find important
before we install the firewall into our present network environment.
here we go....
1. First and formost PERFORMANCE! I can not stress this enough, what
impact will the firewall have on ALL incoming traffic. We use
all the tcp/ip services at present (with the exceptions of the
"r" commands, remote finger, tftp etc). If we use the firewall
and turn on capabilities such as these, what impact is this going
NOTE 1:We are using a 486 running BSDI with 12 Mg of ram, unfortunately the
486 has no level 2 cache right now, it is on order (256K), and I know
this will tremendously improve the OS' throughput. Also the cpu is
only a DX33.
Does anyone have any real hard figures to support throughputs?
We have the neal-nelson (sp) benchmark suite and hope to have
some figures by the end of the week on mixes of ftp/telnet/Xclients
as well as other services. We can post results when we have them.
Please understand the configuration of our firewall hardware, once
upgraded we will re-run the benchmarks and post it here.
NOTE 2:We understand the shortcomings of the hardware, but to make this
solution possible we (the GOVT) must have access to contracts with
standard systems on them, so we used what contracts are available for
the solutions we are looking at.
2. What impact does the firewall have on possible applications that
already exist. (I understand that no-one knows our applications)
but is ORACLE a problem ie oracle's sqlnet? Is it possible to
use a proxy with the sqlnet, or is it required to write an
application gateway, if so, are there "strawmans" available? I would
like to hear if anyone else has run across the same.
3. KERBEROS, we want to use kerberos as our authentication means for
access to the firewall administrator. We have clients available to
use on several GOVT. contracts. We would like to know is/will
kerberos operate as a proxy through the fwtk? I suspect so, however
I do not yet have it working. I have re-compiled the rlogin-gw to
use kerberos but have as yet not tested it. Has someone else
already done this? if so have you tested it? Could/may we have
ideas, or even if possible source?
We are lokking at using kerberos with kerberized server's ie (all
"r" commands, ftp, etc).
NOTE 3: We are also looking at S-key as a possible alternative, and we would
like to support them bost for flexibility. Does anyone in the group
have a feeling for this? Is it a good idea? if not what would the
drawbacks be? (other than supporting 2 authentication services).
4. Mail. Our biggest way of doing business is be elocronic mail. We
have exterior mail sending to us now, but this will be stopped and
handled by the firewall. I am comfortable enough with the mail
setup on the firewall. Does anyone have any horror stories or some
helpful/constructive criticism on the setup of smtp?
That's about all the questions I can think of right now, I do have others, but
those require a little more thought on implementation of them (httpd for one).
I do not wish to start a flame, I have been reading this group for about 3
weeks and I do not agree with what was previously said about the signal to
noise ratio. I feel there is quite a bit of knowledge in this group, as well
as a lot of peaple with other implementations which may not be the same as
someone elses. The word here is diversity. I believe I have gotten quite a
lot of info from this group and even if it doesn't pertain to what I am doing
right this minute it has merit for future references. I hope this forum grows
because there are a lot of topics/issues someone else may have knowledge on and
I would like an opportunity to draw on that. (a lot of stuff about re-inventing
the wheel here kindly deleted).
If anyone of you have info or ideas on what I expressed here, please feel free
to let me know what may be the best approach, drawbacks, better ideas, etc.