NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/protocol/tcpip/3865

Internet Message Format | 1992-07-28 | 3.2 KB

Path: sparky!uunet!darwin.sura.net!mips!sdd.hp.com!hplabs!ucbvax!ulysses!ulysses.att.com!smb
From: [e-mail] (Steven Bellovin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)
Message-ID: <[e-mail]>
Date: 28 Jul 92 15:36:14 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Lines: 48

In article <[e-mail]>, [e-mail] (Dale R. Worley) writes:
> As far as I've seen, much of the problem with firewalls is not that
> they exist, but that they are badly configured.  For instance, I've
> seen firewalls that would allow "inside" users to telnet out, but they
> couldn't rlogin out.  A good firewall should allow everything that is
> permitted and nothing that is forbidden, and so improves security
> without adding any additional burden to proper usage.

There are a number of problems with that notion.  For one thing, what
you suggest is often impractical.  To use your example, how can I
characterize, at the router level, a legal rlogin packet?  About all I
can say is that the outside port number in one direction is 513, and
the inside port number is something less than 1024.  But when such a
packet floats by, the router has no way of knowing that that's really
rlogin.  The *real* definition is that the connection was initiated
from the inside.  Otherwise, the packet could be from a connection
initiated *from* port 513 on a dedicated attacker's machine, and to
some service on an inside machine.  But routers don't keep track of
connections, they look at individual packets.

Higher-level gateways, such as the one we run, can do what you say.
We've consciously decided not to support rlogin for two reasons.
First, in general we don't think that address-based or name-based
authentication is secure, and -- as a matter of principle -- we won't
ask people to trust us when we won't trust them in that regard.  The
second problem is the nature of our gateways.  All outbound connections
from AT&T come one of a very few machines (at the moment, exactly two,
I believe).  We can't vouch for the uniqueness of userids -- there
might be another smb, somewhere within the company, who would have the
same privileges as I would when doing an rlogin through the gateway.
That isn't acceptable.  For that matter, we don't keep track of the
trust level of every internal machine; if you saw an rlogin attempt
from us claiming a userid of ``root'', you'd have no way of knowing if
that was root on a great gronking huge UTS machine in one of our comp
centers, or root on an MS/DOS laptop.  I suppose we could munge the
username field on the rlogin messages, to include the inside host name;
however, that would demand more knowledge of the application protocol
than our gateway currently has.  (We run a circuit-level gateawy.  A
true application gateway, such as DEC's, could do that more easily, I'd
guess.)

UDP applications are even more problematic.  We'd love to support
``talk'', or have higher-level access to Archie.  And we haven't
given up; we have a number of ideas on how to improve our gateways.
We *don't* want gateways -- but we're very certain we need to have them.


        --Steve Bellovin