djh@cci632.UUCP (Daniel J. Hazekamp) (10/24/87)
We are currently looking into the use of an Ethernet Bridge to link two seperate Ethernets. Any vendor/product information, as well as personal recommendations are welcome. Dan Hazekamp CCI Rochester, NY rochester!cci632!djh
pavlov@hscfvax.UUCP (840033@G.Pavlov) (10/26/87)
In article <2063@cci632.UUCP>, djh@cci632.UUCP (Daniel J. Hazekamp) writes: > We are currently looking into the use of an Ethernet Bridge to link > two seperate Ethernets. Any vendor/product information, as well as > personal recommendations are welcome. > Me too ! Please ! greg pavlov, fstrf, amherst, ny. ....harvard!hscfvax!pavlov
AD@BROWNVM.BITNET (Arif Diwan) (10/27/87)
I am in the process of setting up an IBM RT/PC running AIX 2.1.2 as a "bridge" between 2 ethernets. The setup I have is a local Ethernet with TCL multiport transceivers as hubs. Each hub supports 8 hosts, but these hubs can be cascaded together to increase this number. Also, you can interface a cascade with an existing IEEE 802.3 spec coax hookup with an adapter. We also have Applitek boxes which connect the lans to a campus-wide network via a broadband backbone. These Applitek boxes filter out "directed" packets as opposed to broadcast packets as well as allow a simple interface to a 10Mbit per second broadband channel. We also have Sun and MicroVaxs which are being used as bridges. We are also planning to use PS/2 Model 80 to bridge PCNET and Ethernet lans. We have also bridged one AppleTalk network ethernet using a Kinetics box. Possibilities are endless.
snorthc@NSWC-OAS.ARPA (10/29/87)
You might want to consider the family of products by Bridge Communications Inc. They may not be the price leader in boxes to connect ethernets, but I have never heard anyone malign their products. Their products seem to work, the manuals are readable and they really do give tech support when in trouble. Bridge is not without serious competition. I suspect you will find attractive boxes from Cisco and CMC at a slightly lower price. I think UB might have such a gadget as well. We are interested in such things ourselves, so anyone who has something to contribute should consider themselves welcome. Stephen Northcutt (snorthc@nswc-g.arpa)
david@ukma.UUCP (10/31/87)
We're also looking around for ether gateway boxes ...
One that looks very very very interesting is the LANbridge 100.
But there are security concerns. One of the people in our
group is going to squack over and over about how insecure we
are unless we're behind an IP gateway of some sort.
What do people think about the security issues? Right now, the
concern is someone creating a situation where one of our equiv
hosts is down, the bad-guy boots a machine that says he is
the now-down machine and creates an suid shell on another of
the equiv machines, then goes away. The assumption is that if
we're hiding behind an ip gateway then the gateway can see
that these packets coming in from outside, claiming to be
from inside our net, aren't valid and will toss them.
If we're instead using the LANbridge then we don't have any way
of telling that the bad guy is coming in from elsewhere.
We made an informal survey of gateway techniques at the AT&T
users group meeting last spring in Colorado. (I wasn't there
so don't know the details, but...) I was told that the people
fell into two groups. One group used IP gateways and the other
used ether-level gateways. Not one of the people using IP gateways
used them for purposes of security ...
Does everybody just ignore the security issue? How do you sleep
at night?
Oh, we also realize the huge security hole that NFS is as well.
Somehow we sleep at nights with that one. At least most of
us do, the squacker mentioned above probably doesn't.... :-)
--
<---- David Herron, Local E-Mail Hack, david@ms.uky.edu, david@ms.uky.csnet
<---- {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<---- I thought that time was this neat invention that kept everything
<---- from happening at once. Why doesn't this work in practice?hedrick@ATHOS.RUTGERS.EDU (Charles Hedrick) (11/01/87)
Now that source routing is becoming accepted, IP gateways are no longer guaranteed to provide security. A host can pretend to be a host on a different subnet, but use source-routing in such a way that the other guy is told to route the packet back thru the bad guy's real address. The bad guy of course does not forward the packet. IP gateways are normally used because they provide isolation. This issue has been discussed so many times that I am reluctant to do it once more. In general, a LANbridge is more reasonable the fewer Ethernets you have (making provisions for future growth), the fewer different kinds of systems you have, and the better central control you have over the systems on your network. We have had disasters that made every VMS system on a network connected by level 2 routing unusable. The problem should not get thru an IP gateway. We have had several disasters that were confined to a single Ethernet only because of the use of IP gateways. However if you have good network monitoring and system management, a stable network/software environment, or a small network, a level 2 system can be made to work.
JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") (11/01/87)
If you mean Bridge Communications' IP routing products, there is at least one flavor and vintage of them out there which fragments all IP packets longer than 540 bytes. 4bsd and relatives send TCP segments of 512 (552 bytes IP length) bytes by default, and TFTP packets are just large enough to get caught, too. I don't know about the big-machine people, but it has a fairly horrendous effect on the older PC Ethernet cards, which aren't nearly fast enough to catch both fragments reliably. It is even worse when attempting to use one of the public domain software packages that doesn't support IP reassembly. jbvb
schoff@NIC.NYSER.NET ("Marty Schoffstall") (11/02/87)
Now that source routing is becoming accepted, IP gateways are no
longer guaranteed to provide security. A host can pretend to be
a host on a different subnet, but use source-routing in such a
way that the other guy is told to route the packet back thru the
bad guy's real address. The bad guy of course does not forward
the packet.
Chuck,
I don't need source routing to do that. I can do that right now.
Martysnorthc@NSWC-OAS.ARPA (11/02/87)
OK, I'll bite. We have been looking at NFS as a UNIX/VMS server solution for PCs. From the begining of the investigation we were looking for things like the 'huge security holes'. Somehow I must have missed it. I certainly have heard Netters alluding to such a thing. Would you be willing to spell out the problem, perhaps even complete with recommended solutions or workarounds? I may just be a hopeless case. I had never considered using an IP gateway for security purposes either. When I read you message a tiny light went on in my head for just a second... then I started thinking about name/domain serving, additional levels of indirection, and so forth and the light went out. Do you encrypt your secure side? Stephen Northcutt (snorthc@nswc-g.arpa) (703) 663-7796 office, (703) 663-7191 lab
snorthc@NSWC-OAS.ARPA (11/02/87)
James, You have my complete attention. We have a growing investment in Bridge Communications' IP routing products. We also have a sizable, but static investment in older PC ethernet cards (3C500/1, NI5010 ). One such Bridge box that has served us well in the past is the GS-3. A box that may have a place in our future is the IB-1. You can probably guess which PCIP we are using. Most of our hosts are 4bsd. Are we in danger, I suspect we are running either the latest, or next to latest rev. of software for all products? We certainly haven't noticed a problem. The cable is monitered for problems with a lanalyser from time to time. Perhaps this fragmentation problem is limited to an older rev of Bridge s/w, at least I hope so. In the two years I have been here there has been a steady parade of s/w & ROM upgrades from Bridge. The only time we have ever noticed a problem was with a DEC DEMPER of all things. It got connected to the cable with an improperly-labeled- but-suspected-ver1-xceiver. The 3c500s connected by thin net started losing about every other packet. The 3c505s were fine. Changing the xceiver fixed things. In any case whose routing box do you recommend? Stephen Northcutt (snorthc@nswc-g.arpa) Disclaimer: I haven't had my coffee yet! Only relationship I have with companies explicitly/implicitly mentioned is as a happy customer. Bridge is asked to forgive me for mangling their part #'s (GS/3).
geoffb@ALE.TRW.COM (G. Geoffrey Baehr) (11/02/87)
Concerning Charles Hedrick's note about level 2 bridges, it is precisely the quality of bridge management software that allows one to depend on a level 2 solution. What information does exist from these bridges currently seems to be non-uniform and of questionable value. Is there some bridge out there which does have a specified reporting mechanism,or one which may be queried in some manner. I have in mind the RBMS (Remote Bridge Management Software) from DEC, but alas, this spec is not released by DEC to we common folk. Without a diagnostic/reporting mechanism, level 2 bridges appear to offer more potential for net-wide disaster. Geoffrey Baehr I would be interested in knowing whether any vendor intends to implement portions of the HEMS work in their current or future products.
david@E.MS.UKY.EDU (David Herron E-Mail Hack) (11/03/87)
Well ... the only hole which I know by heart is the following
situation. You have someone with a workstation and he has the root
password for his workstation. He also has some local disk storage. He
makes a setuid shell on his local disk. Then he goes over to another
system and executes his shell, thus giving him root on that system. In
our case we use equiv hosts to simplify a lot of things, but don't use
fully transitive equivalancies in a lot of cases. The reason this is a
hole has to do with Unix using a simple integer to encode the user id
... If there were some sort of indication of the host that the user id
pertained to ...
Oh, in the particular situation, the user MUST have root access to his
own workstation so that he can properly do his research. Fortunately
he's a nice guy ... :-)
For a good time read section 2.2.2. of Suns NFS Protocol Specification.
It talks about the above bug and others.
As for using an IP gateway for security ... Well, consider me something
of a beginner in TCP/IP issues. But I still have to manage the local
end of our net, and give advice to the people around me. I understand
enough that the idea of a gateway knowing that a certain class of IP
numbers can only come from one side of the gateway makes sense. But
this source routing stuff which someone mentioned is unfamiliar
territory to me. I've been reading the discussion about source routing
and know that it apparently only applies to token ring. However, it
seems that if there is to be support for source routing in the kernal,
then you could use it from any sort of network hardware. Is the idea
with source routing to encapsulate an IP packet inside another one
which is addressed to a gateway machine, and the encapsulating packet
says where to send the encapsulated packet?
The use of IP gateways to wall off sections of the net to contain IP storms
makes sense ... We may set things up that way ... does anyone have any
recommendations on a good IP gateway?
--
<---- David Herron, Local E-Mail Hack, david@ms.uky.edu, david@ms.uky.csnet
<---- {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<---- "The market doesn't drop hundreds of points on a normal day..." --
<---- Fidelity Investments Co73D
X473DJBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") (11/03/87)
I checked, and the specific model which does the fragmentation is the Bridge GS/3. The guy who has this problem told me that his gateway gurus had done all they could to try to get this fixed, but that it hadn't been, at least the last time he checked (~60 days ago). He says they tell him the GS/7 fixes these problems, and his site is apparently converting. If your network monitoring doesn't reveal any fragmentation of 552-byte IP length datagrams (512 byte TCP segment + headers), then you must have gotten a fix, or else your configuration is enough different that it doesn't happen. Our code did not handle IP reassembly before version 1.16. James B. VanBokkelen FTP Software Inc.
snorthc@NSWC-OAS.ARPA (11/03/87)
James, Thank you for the follow up on the Bridge GS/3. It does seem that the GS/3 might be one of the weaker links in Bridge's Product suite. If FTP software did not support reassembly of packets before 1.16 that helps to explain why we could not discern any difference between its performance* and PCIPs (assuming any packets ever got fragmented). I do seem to remember FTP v. 1.11 or 1.12's SMTP used to make the GS/3s complain, 1.14 fixed that. While GS/3s on the whole (and at a time there were far less alternatives available) seemed to work quite well, I do have one war story. We had a T1 link connecting two remote geographic sites with a GS/3 at each end. Whenever the T1 link went down (often in the boonies) the GS/3s would go off into space and someone would have to press a black button on the front of each GS/3. However Bridge has long since delivered a s/w upgrade and the morning ritual of resetting the GS-3 has been retired. I wonder who makes the best gateway-in-a-box (this week). Stephen Northcutt (snorthc@nswc-g.arpa) * we have never benchmarked TFTP and rarely use it, another reason we may not have suffered too much. Disclaimer: Only relationship between Bridge, FTP s/w and me is I try to buy what they try to sell.
ejnorman@uwmacc.UUCP (Eric Norman) (11/04/87)
In article <7603@g.ms.uky.edu> david@ms.uky.edu (David Herron) asks: > > What do people think about the security issues? Right now, the > concern is someone creating a situation where one of our equiv > hosts is down, the bad-guy boots a machine that says he is > the now-down machine and creates an suid shell on another of Well let's see. Suppose I have hosts Bossie and Elsie here that trust each other and Bossie goes down and you're going to try to make Elsie think you're Bossie from the other side of a LAN-100. Now, what I'm gonna do is put a permanent entry in Elsie's ARP cache with Bossie's IP number and ethernet address. Well, I reckon you can get a packet to Elsie that she'll think came from Bossie, but I'd like to know how you're going to see the packets coming from Elsie destined for Bossie. Eric Norman Internet: ejnorman@unix2.macc.wisc.edu UUCP: ...{allegra,ihnp4,seismo}!uwvax!ejnorman Life: Detroit!Alexandria!Omaha!Indianapolis!Madison!Hyde "Tis far easier for a peacock to show his true colors than it is for a lion to swallow his pride." -- Arte Johnson --
phil@amdcad.AMD.COM (Phil Ngai) (11/05/87)
In article <8711040945.AA17936@ucbvax.Berkeley.EDU> snorthc@NSWC-OAS.ARPA writes: >We have a growing investment in >Bridge Communications' IP routing products. >One such Bridge box that has served us well in the past is the GS-3. Now that Bridge Communications has been purchased by 3Com, I look forward to the day when we can refer to BCI's GS/3 IP routers as 3Com boxes instead of "bridge boxes". -- I speak for myself, not the company. Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or amdcad!phil@decwrl.dec.com
BILLW@MATHOM.CISCO.COM (William Westfield) (11/06/87)
Now, what I'm gonna do is put a permanent entry in Elsie's
ARP cache with Bossie's IP number and ethernet address.
Well, first of all, the idea of loading up your host with
permanent ARP entries is pretty gross, and defeats the the
purpose of ARP anyway.
Second, and more important is that hardware ethernet addresses
aren't any more imutable that IP addresses anyway - I can easilly
change my hardware adrress to anything I want. DECNet does this
sort of thing as a matter of course - setting the decnet host
numbers into the hardware address. Thus having a permanant
ARP entry doesn't buy you much additional security anyway.
Bill Westfield
cisco Systems.
-------wesommer@athena.mit.edu (William Sommerfeld) (11/07/87)
In article <8711062349.AA04106@ucbvax.Berkeley.EDU> snorthc@NSWC-OAS.ARPA writes: >OK, I'll bite. We have been looking at NFS as a UNIX/VMS server solution >for PCs. From the begining of the investigation we were looking for >things like the 'huge security holes'. Huge security holes is correct. [I won't even talk about vulnerability to malformed packets] At least in the implementations that I have seen (the "portable NFS release"), the NFS server daemon does not look at the client's IP address at all; thus, it will permit access to anyone who can send you UDP packets on port 2049. There is a minor complication, which is that to do anything meaningful, you need to know a "file handle" for a directory on one filesystem. Once you have the file handle, you can do anything you want to the file system, because you can claim an arbitrary user-id in the packet, and the server will trust you. The idea that you have to be "root" on the client to do this is incorrect. It is possible to write a user-level program, using the Sun RPC library, which talks directly to the NFS server of your choice (I know.. it took me about a day to do this, working from the NFS protocol spec). Anyway, back to the weak spot. You can get a file handle from the mount daemon (/usr/etc/rpc.mountd). It reads /etc/exports to find out which hosts it can give out file handles to. Unfortunately, in some versions, it trusts the client to name itself (there is a hostname in the request packet, filled in by the client). In addition, it is possible to make up a valid file handle from whole cloth. In the current implementations, the file handle is the tuple of {device_id, inode_number, generation_number}. The device_id is the UNIX major and minor device number of the device the partition is on. The inode number is just a simple index into the inode table of the filesystem (inode number 2 is the root of the partition, for historical reasons), and the generation number is there to ensure that if an inode is reused for a new file, the new file doesn't get confused with the old. These are initialized to all zero by the standard (non-NFS) newfs. There is a program, called "fsirand", which randomizes the generation numbers of all the inodes on a partition. It is important to run this for _all_ partitions mounted on the server, not just the ones which you want exported, because otherwise someone will be able to use the {device_id, 2, 0} file handle, and get at the root of one of your other filesystems. Thus, the generation numbers become almost as critical as the root password to the server. Is any effort exerted to keep them secret? No. They fly around on the ethernet in the clear. They can also be extracted if you have access to read kernel memory (/dev/kmem or /dev/mem) on the server (typically allowed on pre-4.3 BSD unix systems). There is light at the end of this tunnel, fortunately. Here at Athena, we implemented a very small patch to NFS which gets around this chain of security holes. We modified the NFS server to maintain a hash table which maps {client IP address, user_id} to {local uid, group set}. Map entries are controlled by a modified rpc.mountd which uses the Kerberos authentication system to verify the authenticity of the client. Rather than trusting the client machine to give the user id and group set of the user, the server instead looks for a mapping in the hash table. If no mapping is found, the request is either remapped to uid -2, or rejected immediately, depending on how the server is configured. This has been in use for about five or six months (and in heavy use since September), with very few problems. This is not as secure as Sun's experimental secure NFS system, which includes an authenticator on each request, but our approach involves a minimal performance overhead (when you use VAX 11/750's as servers, you need all the help you can get...), and requires no modifications to the client kernel, and also doesn't require any protocol changes to NFS itself. Bill Sommerfeld wesommer@athena.mit.edu
slevy@UMN-REI-UC.ARPA.UUCP (11/08/87)
On IP & Ethernet address spoofing -- If there's no LAN bridge between you and the target, it's easy. If there is, you may still be able to fool the bridge into passing stuff onto your side. If you want to look like host X (of IP address X.IP and MAC-level address X.MAC), it may suffice to send out some packets with MAC source address X.MAC. When the bridge sees those, it may well get confused about where X.MAC really is, and start routing X.MAC-destined packets onto your part of the wire. Presumably this depends on the bridge's design, and I've never actually tried it, but it does sound plausible. Another trick, not dependent on the bridge behavior, would be to send an ICMP host redirect to the target, telling it to route traffic to X via your own IP address (or some bogus one which you were willing to ARP for). That should work even when X is up. We're considering making our own hosts ignore ICMP redirects for this reason, despite the loss of functionality. We're also considering fixing our gateways in an unorthodox way -- to look at the IP -source- address of arriving packets. If a packet arrives from host Y, on an interface to which that gateway would never route packets to Y, the gateway discards the packet. If all the gateways in a system[*] act this way, a spoofer can pretend to be someone else on the same net, but not someone on another net. So IP gateways can be made to be firewalls in a way that MAC-layer bridges can't (unless the bridges get their routing tables from the net administrator rather than learning by listening). In this case the gateways, too, need to be careful about what ICMP redirects they believe... perhaps by having an administrator-supplied list of GW's, where redirects are believed only if they point to (not just come from!) a legitimate GW. [*]Well... the above sort of works. I think it only really is reliable if the structure of the "system" is a special one -- where all the gateways and all the paths between them are trustworthy, and all the untrusted nets are one GW away from the trusted backbone. Redundancy is still possible, and the backbone can have any structure, but rigid separation of trusted from untrusted hosts & wires still is a pretty severe restriction. Maybe this amounts to an argument for higher-level, end-to-end authentication. While I'm at this, how about NFS security. I think the fake setuid hole can be plugged: SUN's NFS at least has a "nosuid" mount option, and you can just arrange to mount all non-system file systems with it. Then only the server of system files needs to be secure. However, a local superuser can get access to any non-root user's files simply by setting his uid to the right thing. So can any Joe with a PC who goes to the trouble to write an NFS client, which can claim to be any IP address, Ethernet address, and uid it wishes. And as far as I know, NFS (unlike TCP) won't even turn a hair if multiple clients on a net claim to be the same machine -- each ignores responses to the others' requests. SUN's RPC authentication scheme, which derives keys from user passwords, distributes them with a public-key scheme, and uses DES to authenticate transactions after the keys are established, seems promising in this regard. (It was written up in a paper in Summer '86 Usenix, and was supposed to be released with Sun 4.0 the last I heard, along with an NFS that optionally uses it.) One thing I worry about, though. It appears secure enough that people might be willing to allow root access across NFS. But, if anyone finds a hole allowing them to be root -without rebooting the machine- they'll easily gain root access to everything sharing filesystems with them -- a hole bigger than the present one. Stuart Levy, Minn. Supercomputer Center slevy@uf.msc.umn.edu, 612-626-0211
david@elroy.Jpl.Nasa.Gov (David Robinson) (11/08/87)
In article <1761@bloom-beacon.MIT.EDU>, wesommer@athena.mit.edu (William Sommerfeld) writes: > In article <8711062349.AA04106@ucbvax.Berkeley.EDU> snorthc@NSWC-OAS.ARPA writes: > >OK, I'll bite. We have been looking at NFS as a UNIX/VMS server solution > >for PCs. From the begining of the investigation we were looking for > >things like the 'huge security holes'. > > Huge security holes is correct. [I won't even talk about vulnerability > to malformed packets] > ... > There is a minor complication, which is that to do anything > meaningful, you need to know a "file handle" for a directory on one > filesystem. Once you have the file handle, you can do anything you > want to the file system, because you can claim an arbitrary user-id in > the packet, and the server will trust you. > ... [More discussion of the file handle contents] It is very true that NFS is not very secure and it is doubtful that it ever will be VERY secure. As with most network protocols, someone with a little patience and a packet monitor can figure out the protocol. The best way to fight this is to have packet data that is not easy to spoof or even figure out. Using various encryption methods such as public/private key or DES etc helps. Your point about the file handle points out a current weak spot that does not have to exist. The file handle is created on the server and only it is required to know the contents. The client just blindly passes it back whenever it wants that file. You have described quite well the portable NFS file handle for Unix, but on machines such as VMS this doesn't hold, it's file handle is completely different and possibly somewhat strange. The server does not have to use a simple method such as placing the inode in the in the file handle, it could encrypt the inode number with DES first for example. In general to make a protocol such as NFS truly portable and easy to use you must make some sacrifices in security. It is possible to spoof RFS or DECNET but it is more difficult because the protocol is much tighter. But NFS has a lot of room to grow and I do forsee improvement. -David Robinson -- David Robinson elroy!david@csvax.caltech.edu ARPA david@elroy.jpl.nasa.gov ames!elroy!david UUCP Disclaimer: No one listens to me anyway!
JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") (11/09/87)
...
Now, what I'm gonna do is put a permanent entry in Elsie's ARP
cache with Bossie's IP number and ethernet address. Well, I
reckon you can get a packet to Elsie that she'll think came from
Bossie, but I'd like to know how you're going to see the packets
coming from Elsie destined for Bossie.
Eric Norman
I haven't yet encountered an Ethernet interface that didn't allow you to
program its hardware address at initialization time. DECnet relies on
this to get by without ARP. With some software (ours, for instance), you
must patch (or use a PROM burner) to change the Ether address, but a lot of
other packages offer it as a configuration option, so don't count on a
pre-loaded ARP cache to protect security where hosts are "equivalent".
I'm not a big-time NFS hacker, but I've been told that in an environment
where users can re-boot (or power cycle) their workstations and bring them
up single-user, any file that is accessible by anyone over the network
should be assumed to be accessible by everyone.
James B. VanBokkelen
FTP Software Inc.slevy@UC.MSC.UMN.EDU (Stuart Levy) (11/09/87)
We have GS/3's, and I've never seen them exhibit this problem. I just ran an Ethernet trace to make sure. A pair of GS/3s running software version 11000 (connected by a 56Kb line, though that shouldn't matter) just passed a 1064-byte IP packet without fragmenting (or if it was fragmented over the line, the receiver reasssembled it before sending it on the Ethernet). The older software, version 10000, did have a different problem with IP fragmentation. It didn't -cause- any packets to be fragmented. However, if the original sender had already fragmented an IP message, the GS/3 would only -transmit- the first fragment. They made us a patched version of the software (called 10019, I think) to evade this problem. I don't think the current 11000 release does anything wrong in this regard. Stuart Levy, slevy@uf.msc.umn.edu Minn. Supercomputer Center, 612 626 0211
ron@TOPAZ.RUTGERS.EDU (Ron Natalie) (11/09/87)
OK, since you've never heard anybody malign Bridge, I'll volunteer. Bridge makes nice reliable boxes, but they don't always get the protocls right. Their terminal servers are classic examples. They don't answer pings, they botch the Telnet options, etc. _Ron