FOR OFFICIAL DEPARTMENT OF ENERGY USE ONLY
        _____________________________________________________
             The Computer Incident Advisory Capability
                         ___  __ __    _     ___
                        /       |     / \   /
                        \___  __|__  /___\  \___
        _____________________________________________________
                         Information Bulletin

           Network Intrusions through TCP/IP and DECnet Gateways

February 28, 1991, 1600 PST                              Number B-15
________________________________________________________________________
PROBLEM:   The use of multiple network protocol  computers (gateways)
can allow an intruder to gain unauthorized access to critical system
files.  
PLATFORM: Multiple platforms, including  DEC, VMS, ULTRIX, and
Sun computers.  Attacks involve X.25 networks as well as networks
supporting TCP/IP and DECnet protocols.  
DAMAGE:   Possible compromise of user accounts and other system files
SOLUTIONS:  Varied (depending on system configuration and required
functionality).  See appendix  for details.  
________________________________________________________________________
                   Critical Network Intrusion Facts

CIAC has learned of a new series of attacks on computers connected to a
variety of networks.  The common element in these attacks is the use of
computers supporting multiple network protocols, especially TCP/IP and
DECnet protocols.  These multi-protocol (gateway) computers can enable
intruders on TCP/IP networks to obtain unauthorized access to files
using DECnetUs default FAL1 account. Some attacks have resulted in
attackers obtaining unauthorized copies of the UNIX password file and
the VMS RIGHTSLIST.DAT2 file.

CIAC recommends that during this time of increased threat you pay
special attention to VAX/VMS computers offering ANONYMOUS  FTP service
and ULTRIX computers offering the DECnet-Internet Gateway services.
These services have been exploited by intruders on TCP/IP networks to
gain unauthorized access to remote files via DECnet. Some DECnet
networks have been configured to a lower level of DECnet security in
order to provide increased network functionality and ease of use.  This
configuration often used under the assumption that access to DECnet is
limited to local users on the local DECnet network. However, the
existence of TCP/IP-DECnet gateway computers connected to both the
Internet and the local DECnet results in an increased risk of external,
unauthorized access to computers on the DECnet network. This includes
systems running VMS DECnet, ULTRIX DECnet, and Sunlink DNI DECnet.

CIAC recommends that you follow appropriate procedures to secure your
system(s)  against this current threat.  Possible actions are described
in the appendix to this notice.  The actions you should take depend on
the type of system (VMS or UNIX) and tradeoffs between your security
needs and your functionality requirements.

For additional information or assistance, please contact CIAC   
 
  Hal R. Brand
  (415) 422-6312 or (FTS) 532-6312

  Call CIAC at (415) 422-8193 or (FTS) 532-8193.

  send FAX messages to:  (415) 423-0913 or (FTS) 543-0913
 
Neither the United States Government nor the University of California
nor any of their employees, makes any warranty,  expressed or implied,
or assumes any legal liability or responsibility for the accuracy,
completeness, or usefulness of any information, product, or process
disclosed, or represents that its use would not infringe privately
owned rights.  Reference herein to any specific commercial products,
process, or service by trade name, trademark manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation, or favoring by the United States Government or the
University of California.  The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government nor the University of California, and shall not be used for
advertising or product endorsement purposes.  Appendix

I. SECURING ANONYMOUS FTP ON VAX/VMS COMPUTERS

Procedure:
  (login as SYSTEM)
  $ set def sys$system
  $ run authorize
  UAF> mod anonymous/defpriv=nonetmbx/priv=nonetmbx
  UAF> show anonymous
  (Inspect the anonymous account to be sure that: )
  (  * The only privilege is TMPMBX )
  (  * Only NETWORK access is allowed )
  UAF> exit
  $ logout

Positive Impacts:
DECNet network security is greatly improved by preventing FTP users of
the ANONYMOUS account from accessing files via DECNET. Security of the
VAX/VMS computer is also improved by preventing DECNET access to the
ANONYMOUS account.

Negative Impacts:
Anonymous FTP users will no longer be able to access remote files via
DECNET.

Mitigation of Negative Impacts:
FTP users requiring access to remote files via DECNET can be given
accounts on the VAX/VMS system. If necessary, these accounts can be
configured to permit only NETWORK access with only TMPMBX and NETMBX
privileges.

Alternate Strategies:
Some TCP/IP implementations (notably MultiNet) provide a mechanism to
lock ANONYMOUS users into a directory tree. CIAC strongly recommends use
of this feature where possible.


II. SECURING ULTRIX COMPUTERS RUNNING THE DECNET-INTERNET GATEWAY SOFTWARE

Procedure:
  (login as root)
  # cd /etc
  # cp inetd.conf inetd.conf-saved
  (edit the file inetd.conf)
  ( place the "#" character in from of the line: )
  (  ftp  stream  tcp  nowait  /usr/etc/ftpd.gw ftpd.gw )
  ( add this line just after the line just modified: )
  (  ftp  stream  tcp  nowait  /usr/etc/ftpd ftpd )
  ( save the file and exit the editor )
  (Restart the inetd daemon. For example: )
  (   # ps -ax | grep inetd )
  (   Look at the output and find the process number of /etc/inetd )
  (   # kill -9 <process-number> )
  (   # /etc/inetd )
  # exit

Positive Impacts:
DECNet network security is greatly improved by preventing FTP access to
remote files via DECNET through the ULTRIX computer.

Negative Impacts:
Loss of access to remote files via DECNet to FTP users.

Mitigation of Negative Impacts:
FTP users requiring access to remote files via DECNET can be given
accounts on the ULTRIX computer from which they can copy the remote
files via DECNet, and then FTP those files to/from the ULTRIX
computer.

III. SECURING DEFAULT FAL ACCESS

Procedure (On VAX/VMS computers):
  (login as SYSTEM)
  $ mcr ncp set object fal username illegal
  $ mcr ncp define object fal username illegal
  (Make sure you don't have an account named "illegal".)
  $ logout

Procedure (On ULTRIX computers):
  (login as root)
  # /etc/ncp set object fal default user illegal
  # /etc/ncp define object fal default user illegal
  (Make sure you don't have an account named "illegal".)
  # exit

Procedure (On Sun computers):
  (login as root)
  # cd /etc
  (edit /etc/passwd to remove (or comment-out) the "dni" account)
  ( A typical dni account entry line looks like:)
  (   dni:*:376:376:default DNI account:/tmp: )
  ( and should be deleted or modified to: )
  (   #dni:*:376:376:default DNI account:/tmp: )
  # exit

Positive Impacts:
Local security is greatly improved by preventing DECNet access to local
files without specific authorization in the form of a local account or
DECNet proxy login. Note that DECNet proxy logins are not supported by
Sun's Sunlink DNI product.

Negative Impacts:
Loss of legitimate DECNet access to remote files by users not
possessing an account on the local computer. Under Sunlink DNI, default
access to the NML (Network Management Layer) server will also be lost.

Mitigation of Negative Impacts:
The use of DECNet proxy logins can provide access to legitimate users.
Alternatively, legitimate users cna be given accounts. Under VAX/VMS,
these accounts can be restricted to only NETWORK access and only NETMBX
and TMPMBX privileges. Note that DECNet proxy logins are not supported
by Sun's Sunlink DNI product.

Alternate Strategies:
For VAX/VMS computers, default FAL access to RIGHTSLIST.DAT can be
disabled with an ACL (Access Control List) entry. To do this:
  (Login as SYSTEM) $ mcr ncp show object fal char (Locate the
  "User id" from the output of the previous command ) ( and
  substitute appropriately below for <userid>) $ set acl
  sys$system:rightslist.dat/acl=(id=<userid>,access=none) ( for
  example: ) (  $ set acl
  sys$system:rightslist.dat/acl=(id=fal$server,access=none)) $
  dir/full sys$system:rightslist.dat ( Verify that the ACL is
  properly set. ) (CIAC strongly suggests you also add this ACL
  setting command to ) ( sys$manager:systartup_v5.com so that it
  will not be lost in case ) ( a new RIGHTSLIST.DAT file is
  created. )