Casey, since you have chosen to wideband my response, which contained
specific examples and information about a particular firewall
implementation, and in addition have hinted that the system
administrators involved and I are incompetent (again), I have chosen to
follow up with a copy of the result of the LAST time you did that (I
was working at S1 at the time). Specific replies to your points to
follow after that. I would appreciate the courtesy of keeping the
site specific information OUT of public mailing lists, rather than
use the lists as a forum for your own agenda.
--------8<-----clip-n'-save-----8<--------clip-n'-save--------8<-----------
>From casey @
gauss .
llnl .
gov Tue Feb 11 13:02:17 1992
Received: from pearl.s1.gov by terminus.s1.gov (4.1/TMD1.3)
id AA02913; Tue, 11 Feb 92 13:02:15 PST
Received: from pierce.llnl.gov by pearl.s1.gov (4.1/TMD1.2)
id AA26090; Tue, 11 Feb 92 13:01:34 PST
Received: by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-01.92)
id AA17483; Tue, 11 Feb 92 13:01:47 PST
Received: from nixon.llnl.gov by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-01.92)
id AA17463; Tue, 11 Feb 92 13:01:42 PST
Received: by nixon.llnl.gov (5.57/1.15)
id AA20725; Tue, 11 Feb 92 13:05:56 -0800
Received: by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-01.92)
id AA17455; Tue, 11 Feb 92 13:01:37 PST
Return-Path: <casey @
gauss .
llnl .
gov>
Received: from gauss.llnl.gov by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-01.92)
id AA17450; Tue, 11 Feb 92 13:01:35 PST
Received: from localhost.ARPA by gauss.llnl.gov (4.0/LLNL-1.17)
id AA00682; Tue, 11 Feb 92 13:01:16 PST
Message-Id: <9202112101 .
AA00682 @
gauss .
llnl .
gov>
From: casey @
gauss .
llnl .
gov (Casey Leedom)
To: longstaf @
cheetah .
llnl .
gov (Tom Longstaff)
Cc: frey @
lll-crg .
llnl .
gov (Charlene Frey), net-tech @
llnl .
gov
Subject: Re: tftp probe from colby
Date: Tue, 11 Feb 92 13:01:15 -0800
Sender: casey @
gauss .
llnl .
gov
Status: RO
(sigh) Open mouth, insert foot. Usual comment regarding the need for a
mouth wash that fights athlete's foot apply.
In my rush to attack fire walls I impugned the people at S1 who have
been mandated to create them. It isn't their decision to have or not
have fire walls. They are merely given the difficult task of trying to
implement them as best they can and deal with a constant barrage of
complaints from demanding users like me. I'm really sorry to have
insulted them. As always I should take a nap between writing something
and sending it out.
My comments regarding the badness of firewalls remain. They are not
the right way to go in the general case. Designing a better security
paradigm (like Kerberos or something similar) and providing software
security guidelines is what we want to do in the InterNet. The whole
point of the InterNet is interoperability and resource sharing. If you
take that away there just isn't much point any more. We may all as well
get FAX boards in our work stations and send email that way because we'd
get better service than hoping for multi-routed email to make it through
all the fire walls.
I understand that CCSG is interested in trying to put up a fire wall
around their machines. They're not the general case. I think that they
have very good reason for setting up a fire wall given their need for more
security now. But I don't think that even they would need a fire wall if
we had a better security model.
Again, my apologies to the S1 support and administrative people.
They're doing the best job they can given the constraints that they've
been put under. This is the second time I've insulted them and the
second time I've had to apologize. You'd think I'd learn. I guess I
just care too much about the issue and am not measuring my words. And in
the end, inflammatory prose only serves to discredit any arguments I
make. Please forgive my indiscretion. But please also try to read
through it to the message underneath.
Casey
--------8<-----clip-n'-save-----8<--------clip-n'-save--------8<-----------
And before I begin with my rebuttal, I would like to point out that
my personal opinion of firewalls is that as long as standard
networking services rely on wimpy authentication methods, firewalls
are a necessary evil. But as long as I *have* to support one, I'm
going to do a damn good job. I suppose I should put in a disclaimer
here: I don't speak for S1, LLNL, DCSP, or any other acronym.
Casey Leedom writes:
> |
> | I assume you're referring to s1.gov... it's getting a little better there.
> | Please understand that I don't run the systems there, but I work for
> | DCSP. I used to work at O-div for a couple of months.
>
> Yes, I'm talking about S1.GOV.
>
> | There is PH passthru now (I wrote it) and a Gopher passthru is in the
> | works, I think. They've been working on passthru X forever it seems (I
> | don't know if it can be done, considering their security requirements).
> | I missed a good deal of this thread... what other services DO you want?
>
> So I get those services if I'm running on a Sun. What if I'm on a
> Macintosh? What about an RS/6000? How about an HP? Etc.
First off, the PH passthru looks/tastes/smells exactly like a real PH
server, so it will work from any machine that understands PH at all.
A Mac running Eudora, for example. Making it transparent to the user
was a design goal. (A note for passthru designers: try to make this
a design goal. Your users will be glad you did, because they'll use
all sorts of wierd clients to talk to it.)
Secondly, in the case of the telnet/ftp passthrus, you do not NEED to
have the customized client programs. As long as your telnet/ftp
client can connect to an alternate port number, you can use the
passthru services. I will detail the method to you in a private
message.
I admit that this situation is not optimal. In the best of all
worlds a user would never have to know he was behind a firewall at
all, in the course of ordinary work. If "private" network services
(login and file transfer, for example) used strong authentication
(and thus provided good access control) methods then I believe there
would be no need for firewalls at all.
> Not only are the passthrough clients not available on any of the
> platforms I mentioned, but even if they were, getting them installed on
> everything in the universe and maintaining all that local software would
> be a bitch and three halves. But trying to secure those same N machines
> would be worse.
They could be available, there is source code for them. The system
staff is not allowed to touch certain machines within the firewall,
so those machines obviously do not have the passthru clients. If you
have a problem with a particular machine there, talk to the person
who controls it. Maintaining and installing local software happens
all the time... X11R5 doesn't get shipped with Suns, or hadn't you
heard? There aren't that many architectures involved here. This is
not a firewall problem, but a political problem.
> I really think that a transparent packet filter would be a better
> approach. But I have to admit that I've just joined the firewalls
> mailing list and I'm only now coming up to speed on what technologies
> exist for firewall protection.
Packet filtering is in place already. I doubt now that you know
enough about the design of this firewall to criticize it
intelligently. I guess that explains the above message from you.
Make that THREE times, Casey.
> But even a packet filter wouldn't address some of the very real needs
> for services that the outside world needs from S1.GOV. In particluar,
> there's no finger or whois service offered by S1.GOV, so it's impossible
> to find out email addresses or get current information on users. Finger
> is especially nice that way because many users leave personal calendars
> in their .plan files. (And yes, I know the reigning paranoia about how
> bad finger is because it lets outsiders know login IDs in use. It's very
> simple to modify the finger daemon not to respond to an empty query.)
If you know the user's name, then there is only one mail address that is
valid for that user... username @
domain .
Look at the MX discussion,
below.
Finger paranoia isn't the problem. No one to date, other than you,
has complained about the lack of finger service for this domain,
since there is an institution-wide server for finger, whois, and ph
data that is well-known. It is true that a remote correspondent may
not know what that server is... but I could have a passthru (actually
redirection) service installed on the gateways in less than ten
minutes, if I had the authorization. Please remember that the system
administrators require written authorization from management to
change ANYTHING on the gateways. Submit an official request for
this, rather than complain to the firewalls list. I assume you know
how the request(1) system works?
> | > The only incoming connection arrangement is via a separate machine which
> | > only allows telnet connections.
> |
> | The reason behind this is 1). Since I believe they'd lose their Internet
> | access if they were broken into, they must keep security a high priority,
> | but security consumes the resources of the administration staff, which
> | isn't much to begin with. I myself maintain tight security on my machine
> | which is out on Labnet, but it takes up a measurable fraction of my time
> | every day. Multiply that by dozens of workstations. If an intruder
> | breaks root on a machine, it's just too easy for him to use software to
> | sniff out plaintext passwords going by on ethernet... so each workstation
> | is the weakest link in the chain.
>
> So? Things happen. If you insist on living in a perfect world, you'd
> better just turn the computers off. The fact of the matter is that there
> is no such thing as perfect security. Only better and better and at
> exponentially increasing costs -- both in terms of administration and
> user costs. You have to decide how much security you need and want, and
> how much you're willing to pay.
>
> But I know you know all of that already. (Seriously, I'm not being
> snide.) From my point of view, as a user, the firewall at S1.GOV is just
> too expensive. I'm constantly aware of it and constantly having to fight
> it. Now, to some extent, that may be because I spend so much of my time
> dealing with the outside world. Other users who just work on local
> machines and interact with the outside world via email probably don't
> notice anything and feel at ease knowing that their machines are ``safe''
> from breakins.
It's a well-known maxim that ANY kind of security is a race- between
those who build it, and those who remove it. The race between locks
and burglars is very old indeed. A level of security was chosen by
management and that's how it is. It stopped a bit short of isolating
the network completely from the Internet. SOME network access
exists, at least... this particular network could have isolated
itself even further by making all mail and news go thru UUCP or
something, and not have any outside network connection at all. The
system staff there has worked as best they can within time, money,
and political constraints. Honestly, there is an ongoing effort to
make things as unobtrusive as possible for the users WITHIN the
firewall. I can roughly break down typical remote network traffic
where I work for you very easily: 80% mail, 10% news, 5% ftp, 5%
other. 'Other' is mostly telnet, gopher, and ph. Since S1 has ALL
of these except gopher, I expect it is a rare user who cannot get his
work done.
> | > Mail is MX'ed up the wazoo.
> |
> | This is bad? I'd think this is more a convenience issue than a firewall
> | issue ... For example, TIS uses MX's and hidden hosts so that all
> | incoming mail is forwarded to the correct machine for each user. We have
> | a lot less problems with "follow the bouncing .forwards" than most.
>
> Actually, it turns out that mail isn't MX'ed at all as far as I can
> see. I just got a bounced mail message when I tried to send a message to
> david @
guardian .
s1 .
gov .
The name servers advertise the IP addresses of
> the machines under S1.GOV, but don't advertise any MX records for them.
> Very strange. Exactly the opposite from what you'd see at other sites
> that have errected firewalls.
Gee, make up your mind. :-) For the listeners in the audience
I will clarify the situation: There is no wildcard MX in place, but
there are a couple of domain MX records (redundancy is built-in to
every service as a matter of policy among the system staff).
The machine names inside are never advertised to the outside world
(except, as you discovered, by DNS- but since the routers will not
allow incoming/outgoing packets from anything other than the gateways
it doesn't matter). All outgoing mail headers are
re-written to say user @
s1 .
gov .
.
.
it is the name "s1.gov" which is
MXed. Outgoing news only has the domain name in it, too. The
hostname "guardian", in theory, should never be used by anyone
outside the firewall... and need not be. You use the mail hub
address, which always does the "right thing", even if guardian
undergoes a name change or a user moves his mailbox to a different
machine. Thus, the mail address an outside user may have for you
will be correct, no mattter how accounts or machines are shuffled.
This is all well-covered ground. Since you are the person who
originally wrote the default sendmail.cf used by many machines at the
site, I am surprised I should have to explain common uses for MX
records. Go read up on something called "mail hubs." This is not
directly a firewall issue, but a mail issue.
> As for ``following the bouncing forwards,'' how do MX records solve
> that problem (not that I ever found it to be much of a problem when I was
> running a bunch of machines)? All you've don't is make it so that you
> now have to be involved in every single mail home change that users go
> through because they now have to ask you to change your central
> forwarding database. (Unless of course you've duplicated the stuff they
> have for LLNL.GOV that let's users change their own information.)
It is true that a system staff person has to be involved in a mail
home change (not that I ever found it to be much of a problem to edit
a file and type 'newaliases' when I run a bunch of machines), the
advantage to users is very simple: One email address. Guess what!
It won't change if a machine name changes, or if it is moved to a DNS
subdomain, or the user switches projects. No one outside of your
organization needs to care if you switch from a Sun with one name to
an SGI with another. The users won't have to put in a .forward on
their 'old' account to the new machine, and eventually get mixed up
or wonder why their mail takes another two hours in various machine
mail queues before arriving. I've seen it happen, even in small
networks. That's one reason why there is a site-wide Central Email
Project, too.
> | > I maintain my home on GAUSS.LLNL.GOV and do all my outside communication
> | > from here because I can avoid the firewall and it's hassles.)
> |
> | I have my home out on labnet, too. I prefer investing the time to secure
> | it rather than utilize the firewall because I like to tinker; I'm
> | currently running network protocol experiments for DCSP on my workstation.
>
> This is also going to be a problem for me. I'm planning on getting
> involved with InterNet experiments with multicast protocols and I'm going
> to need transparent access -- both in and out -- via multicast to the
> outside world. I've put a bug in Lee and Tina's ears about this, but
> haven't followed it up yet. I have a lot of reading to do before I can
> get started on the project.
Now this is completely different. You are right, you'll need to have
a machine on an open network for this. But I don't see how such
experimentation would be paid for and supported by the division
behind the firewall; if you would like to do experiments on your own
time you should arrange for your own machinery and Internet
connection, and not expect to get a free ride from anyone. If it IS
sponsored by that division, just arrange for that machine to be
outside the firewall. That's easy enough.
> | > One of my biggest gripes is that we only have itelnet and iftp clients
> | > for Suns. This leads to seemingly endless multi-hop store and forward
> | > ftp acts guaranteed to try your patience.
> |
> | I agree trying to move something in or out without sitting at a machine
> | inside is trying, at best. Sometimes it's painful. The goal was to
> | severely reduce the chances of intrusion while still providing necessary
> | network services. If you can think of a better method then by all means
> | share it; I'll pass it on.
> |
> | My opinion is that as long as remote login protocols rely on such wimpy
> | authentication mechanisms, firewalling will become more popular.
> | Kerberos doesn't scale well enough to use on an Internet-wide or even
> | Lab-wide level yet, but perhaps soon.
>
> Well I wish we [the InterNet community] would get on with finding
> solutions so we can get back to doing work instead of spending all our
> time putting up barriers that get in the way of doing work. But I'm just
> a bitter old hacker who remembers ``The Good Old Days'' when the range
> wasn't fenced in by sheep ranchers.
I expect most of your "seemingly endless multi-hop store and forward
ftp acts" problems are from machines that the system staff are not
allowed to modify (read as: install any software). I suspect you
also did not know how to use the passthru services without having
those clients. All you had to do was ask. Again, I am sending those
instructions are in a private mail message to you.
To bring down the walls, you need to increase trust. Anyone today
who trusts the integrity of every network their data traverses (when
one or more of those networks are not under their direct control) is
living in a fantasy world. It is a simple matter to write a program
to listen on a NIT device and copy passwords as they fly by; if you
can't trust the physical media it's even easier to hook up a PC with
an ethernet card and run freely-available packages. An intruder,
therefore, need only get ONE machine, and more on that network will
fall quickly.
I do strongly support the idea of a information-resource-sharing
Internet. I am promoting Gopher (and looking at WWW) at the lab for
just that reason. I do not believe in putting proprietary or
otherwise restricted data at risk, however, and a firewall is
sometimes an appropriate tool to protect that data. The future, I
feel, is not quite so gloomy: I predict as Kerberos V5 blooms and
becomes widely available, many networks that require firewalls now
will Kerberize their local services to provide secure networking.
Only networks with a need for strong security and a user base that
MUST install their own custom (possibly buggy) network services will
continue to require firewalls.
--
Shawn Instenes, shawni @
tis .
llnl .
gov, shawni @
s1 .
gov
Distributed Computing Support Program, LLNL
|
|
