brian@ukma.UUCP (03/11/87)
We will soon be attached to the internet, and I have some concerns about
how our systems should be connected. We are running 4.3BSD+NFS
on several vaxes communicating over ethernet. As the ethernet
contains only machines which are "trusted" most of the hosts are
equivalent to each other. My question is what happens when one of these
hosts is connected to the outside world. I assume that it would be
a good idea to bring the outside in through a seperate device,but even
so how do I prevent soemone on the outside from passing packets
which make him appear to be one of our "equivalent" hosts?
An example may clarify what I mean. Lets say that our local net is
100 and the "outside" net is 101. Since I want all of the machines on
net 100 to be able to talk outside I setup the machine attached
to both as a gateway by telling my machines to send all unroutable packets
to 101 (right?). Now what keeps Nasty person X on on net 201 (attached
to 101) from claiming to be on net 100 and thus enjoying the
equivalent privledges? Is there some way to configure 4.3 to do this for me that
I do not see? How do big sites handle this?
--
Brian Sturgill System Manager
University of Kentucky Departments of Mathematical Sciences
cbosgd!ukma!brian, brian@UKMA.BITNET, brian@ms.uky.csnethedrick@topaz.UUCP (03/14/87)
brian@ukma.ms.uky.csnet (Brian Sturgill) asked what is to prevent users from outside his university from pretending to be one of his own computers, and thus taking advantage of .rhosts or hosts.equiv notions of "trustedness". Ethernets and TCP/IP as usually used in universities are far from secure. But this particular danger is not one of its problems. Most uses of TCP/IP involve a bidirectional conversation. In many protocols, there is an exchange of information. But even if the actual data passes in only one direction, opening the connection and maintaining it require packets to pass both ways. There are a few protocols for which this is not the case, but as far as I can recall, none of them use hosts.equiv. Anyway, the point is that any reasonable gateway will protect you against people from the outside pretending to be one of your hosts. Suppose somebody sends a packet to your gateway, with a source address pretending to be one of your own machines. The gateway will probably pass it on to the destination, and the destination will be deceived. But when the destination tries to reply, it will reply to the purported address. That will be an address on your own campus. This packet will be delivered to your own machine. Should this reply get to your gateway, your gateway will not send it off-campus, since the reply is addressed to one of your own machines. Thus no conversation will be established with the intrudeer. Of course this is *not* true of other machines on your campus. A machine on the same Ethernet can pretend to be some other machine, though in many cases error messages will start showing up on the console of the machine being imitated. All of this assumes that the connection between your campus and the outside will be a real IP gateway, e.g. a synchronous line between one of your VAXes and a similar machine on another campus, using the normal Unix gateway software. Or even better, you might use a commercial IP gateway such as those produced by Cisco or Proteon. However if your connection uses a bridge such as the DEC LANbridge, or the Translan, then logically your Ethernet and the other guy's Ethernet are the same. This raises both security and reliability issues. In my opinion, you have to be crazy to use a bridge (as opposed to an IP gateway) between networks for which different groups are responsible. As far as I know, all services that use hosts.equiv