Conference azur::mcc

> Today I find out, that you can reboot a translan without specifying the
> reconfiguration password of the translan. In addition to that you can
> modify the configuration parameters on disk without password.
> ...
> This means that anyone who install the TransLAN AM can modify my X-LAN
> configuration and reboot the TransLANs.

You can do the same thing with LANBridge 100's and the Bridge AM.  That's
why we did most of our testing during development on a private network 
(except for that one time that L... well, you get the idea :-) 
Newer bridges have added password protection, however.

						Wayne

set the ACLs on the translan executable so that only the appropriate 
people have the necessary execute privileges. It might not be the
best solution but it will mean that unauthorized use of the AM is
not happening from your node...

Wayne and Jill,

Thank you for your replies.

> You can do the same thing with LANBridge 100's and the Bridge AM.  That's
> why we did most of our testing during development on a private network 
> (except for that one time that L... well, you get the idea :-) 
> Newer bridges have added password protection, however.

Wayne,

you are right with the LANBridge 100 and the Bridge AM, but this is not
my point. You can set a RECONIFUGURATION PASSWORD on a TransLAN Bridge 
like the password on a LANBridge 150 or LANBridge 200. With the password
set on a LANBridge 150 and 200 these bridges are protected against reboot 
without specifying the right password. This works for the DECmcc Bridge AM.

But the TransLAN AM doesn't take care of a set reconfiguration password. 
The problem is not with the bridges. The problem is with the TransLAN AM.


> set the ACLs on the translan executable .....

Jill,

setting ACLs solves the problem for a single DECmcc Director Station. 
But there is still the problem that anyone who installs DECmcc and the
TransLAN AM on another station can reboot translan bridges and modify 
the X-LAN configuration without any password protection.

This problem happens not only on private networks and test networks, this is 
also a problem on EASYnet !

Regards from Hamburg .... Karsten.

RE: .-1

> you are right with the LANBridge 100 and the Bridge AM, but this is not
> my point. You can set a RECONIFUGURATION PASSWORD on a TransLAN Bridge 
> like the password on a LANBridge 150 or LANBridge 200. With the password
> set on a LANBridge 150 and 200 these bridges are protected against reboot 
> without specifying the right password. This works for the DECmcc Bridge AM.
>
> But the TransLAN AM doesn't take care of a set reconfiguration password. 
> The problem is not with the bridges. The problem is with the TransLAN AM.

I'm a little confused about how the problem described is the fault
of the TransLAN AM.

For instance: with the Bridge AM talking to LAN Bridge 150s or LAN Bridge
200s, setting/saving of the password is done IN THE TARGET BRIDGE. If the 
user wishes to issue a RESET BRIDGE command without specifying a password,
and the target bridge is stupid enough to allow the RESET to occur (accepts
the RESET request without checking password), it's no fault of the Bridge AM.
In other words, the password protection that you have with LB150|LB200 is
enforced by the RBMS Agent, not by the Bridge AM.

You seem to be saying that the TransLAN AM should be implementing/enforcing
some scheme to prevent users of DECmcc from doing a RESET TRANSLAN without
specifying a correct password, since the bridge doesn't seem to be protecting
itself.

Is this what you're asking, or am I reading too much into your comments?

						Chris  

    Chris,
    
    I think there is a mis-understanding here.  The Vitalinks do have an on
    board, changeable password just like the LANbridge 150 and 200.  The 
    complaint here seem to be that the TRANSlan AM by-passes this password.
    
    Just a point of wonderment,  what if the TRANSLAN_AM used the default 
    reconfigure password and if it worked that was all it took.  What would 
    happen if the REC password were changed.
    
    Steve

> You seem to be saying that the TransLAN AM should be implementing/enforcing
> some scheme to prevent users of DECmcc from doing a RESET TRANSLAN without
> specifying a correct password, since the bridge doesn't seem to be protecting
> itself.

Chris ,

I think it is necessary to talk about the management of a TransLAN bridge
more than to talk about DIGITAL LANbridges.

Without DECmcc and the TransLAN AM the TransLANs are configured via 
a terminal connected to the V.24 console port of the bridge.
Automatically you enter the user interface of the Vitalink network
products. This user interface is called Vitalink Management Services (VMS)
and has nothing to do with DIGITAL VMS or RBMS etc.

You manage the TransLAN with some special VMS Commands and a 
reconfiguration utility. Rebooting or reconfiguring the system using
the VMS utility requires a password which is stored on the disk
of the TransLAN. Via the VMS utility the TransLAN is protected by 
itself.

If you use the TransLAN AM for managing on configuration, you enter the
TransLAN via the ethernet port of the bridge. And now the password is NOT 
required for DECmcc, but for Vitalink's VMS utility the password is still
required.

It seems to me that the TransLAN AM does not take care of the
TransLAN's password protection.

This is the fact I want to describe.

    It sounds like the remote agent ON the Translan Bridge is not enforcing
    remote password protection. This is (if it turns out to be the case) a
    Vitalink problem for them to address since both the agent on the bridge
    and the Access Module are the property of Vitalink.
    
    I hope the folk from the SVP group have followed this and will take
    this information back to Vitalink so the issue gets resolved (assuming
    it is really a bug and not that we missed some setup somewhere...).
    
    s/rob

    Sounds to me like you need security at the "box" level, not the
    software level.  Yes, the TransLan AM developers could enforce a
    password, but what if some ambitious. destructive, intelligent person
    wrote some software which was almost exactly like the Translan AM
    except it was missing one little piece.  User-mode software is not
    very secure.  You really need to push security down to the lowest level
    possible.  In this case, the bridge itself.  Now, if we had a security
    architecture...
    
    -Matt.

re: .5
> ... the TRANSlan AM by-passes this password.

Steve, you got the problem. Thank you.

> Just a point of wonderment,  what if the TRANSLAN_AM used the default 
> reconfigure password and if it worked that was all it took.  What would 
> happen if the REC password were changed.

I did some tests:
- set REC password to default .............. reboot without password is possible
- set REC password different to default .... reboot without password is possible

==> the TransLAN AM completely by-passes the REC password set on the TransLAN
    bridge itself.

If anyone else has an idea or proposal like Steve to qualify that problem 
more deep , he is welcome. I will do this tests as well as I can.

re: .7
> I hope the folk from the SVP group have followed this and will take
> this information back to Vitalink so the issue gets resolved.

I think Rob's recommendation is the best in the moment.
Could anyone of the SVP group confirm the contact to Vitalink ?

Prophylactically I set the write protection on all my TransLAN floppies.

Karsten from Hamburg.

Just curious,

Assuming that reboot is mapped into RBMS Reset (Doug, If you're reading
this, please reply)

Has anyone tried any of the other bridge related products (including
Bridge AM) to see if they also "bypass" the TransLAN password...

    Boy, go out of town for a couple of days and look what happens!  

    First of all, the Vitalink Translan AM implements *all* of the RBMS
    agent functions available in the Translan family.     Let me be clear
    about this point:  The RBMS agent on the Translan bridge enforces no
    password protection whatsoever.  Period.   There is nothing that can be
    done in the AM to enforce a password if the agent doesn't implement
    one.   Having said that, the problem lies with getting the RBMS agent
    in the Translan Bridge modified to require password protection. Then,
    the AM would have to be modified as well to use it.   For various
    reasons, I don't believe that this is in the cards (at least not right
    now).   However, I do not speak for Vitalink, so if this is a major hot
    button for you, then please contact the Translan AM product manager at
    Vitalink and voice your concerns.   Her name is Doreen Pizarro and she
    may be reached at (415) 795-6252.

    Also,  I just finished looking over the source code and it appears that
    Vitalink Translans use the same RBMS reset code as do DEC Bridges
    (9F-87-01).   If that is so , then it appears that the possibility of
    "unauthorized resetting" of Translan bridges has *always* existed,
    assuming of course that said unauthorized person wanted to go to the
    trouble of installing and learning how to use RBMS (the product) or
    DECelms and then *finding* the bridge address.

    /doug